Hi,
I'm curently transfering my projects, I used to make in Corel, to Inkscape. In one project I have background imported from JPG. After adding some text to this project i wanted to save it as PDF (to send it to printing house). But the results were disappointing. Text that was added in Inkscape is allright but background is in negative collors. Any ideas why? Maybe its some problem with RGB.

One more thing.
When im exporting same project as PNG everything is allright.

If you're on Windows, it sounds like you have run into a known problem with version 0.91, 64-bit. The last item in this list: http://wiki.inkscape.org/wiki/index.php ... own_issues. And for some more info: viewtopic.php?f=5&t=18969#p72293

You could try using the 32 bit version of 0.91.

Unfortunetly, im using Ubuntu 15.04 32 bit

Maybe I have installed Inkscaped 64bit on my 32 bit system? I cant find info about my version. I know its 0.91

wiitold wrote:Unfortunetly, im using Ubuntu 15.04 32 bit

Maybe I have installed Inkscaped 64bit on my 32 bit system? I cant find info about my version. I know its 0.91

The mentioned known problem is specific to Inkscape builds for Windows, and (as far as we know for now) specific to the (more recent) version of the cairo graphics library bundled with the 64bit Inkscape builds for Windows, and only happens when printing (either directly or to PDF via custom PDF printer driver), but not when saving as PDF.

And no, a 64bit build won't run on a 32bit system - neither on Windows nor on Linux.

You might want to consider sharing your files (Inkscape SVG file, PDF file saved with Inkscape) to allow others to take a closer look what might trigger your problem.

Those files are too big so i had to upload them on my Google Drive.
https://drive.google.com/folderview?id= ... sp=sharing

Saving as pdf works well on 0.48.4. -tested-.

What does it mean? I have to downgrade my inkscape? Or maybe wait till next update comes out?

The problem seems to be related to the image format; or rather that the JPEG image for the document background uses the colorspace CMYK (and AFAICT has an embedded ICC color profile).

Problems with such JPEG images seem not limited to Inkscape: Using ImageMagick's display command to view the JPEG image extracted from the SVG file displays with the same color inversion; PDF files created on the command line with rsvg-convert from librsvg produce the same kind of inverted background image in the generated PDF as Inkscape 0.91. For now, I don't really have advice (except maybe to recommend to use raster graphics with colorspace RGB for inclusion in SVG files).

Re Inkscape 0.48 - yes, with the old renderer, and the old PDF exporter which recompressed embedded bitmap images (bug 168708) in the exported PDF file, the exported PDF file seems to render as expected. That does not necessarily mean though that Inkscape 0.91 itself is broken (since the same output reproduces with other software which uses the same shared libraries) - it could be an issue with the original image data, with the embedded version of the original image, with the cairo graphics library (or even with gdk-pixbuf, I don't really know).

Since we don't have the original JPEG image available for further tests (we can't verify the content of the one embedded in the SVG file via gdk-pixbuf) - could you test what happens if you link the bitmap image on import (instead of embedding it into the SVG file)? I doubt that it would make any difference, but one never knows ...

You can try embedding a raster image of a different format, like a png.
(Extracted the raster image and saved as png with gimp, then embedded it again.)

Lazur URH wrote:You can try embedding a raster image of a different format, like a png.
(Extracted the raster image and saved as png with gimp, then embedded it again.)

I'm aware of this - my point was that we cannot tell if any detail of the original image data was changed (or dropped) at the time it was converted to base64-encoded data when embedding the image on import. Thus I do not consider further tests on a bitmap image extracted from the SVG file (which at that point would have undergone two conversion with different software libraries (gdk-pixbuf, python)) as necessarily providing conclusive information.

wiitold - as author of the SVG file - likely has the original, unmodified version of the JPEG image still available - I'd recommend to convert that one to a different image format and color space, if needed.

~suv wrote:I'm aware of this

I know, just thought the original raster image might not be at the hands of the original poster -as it contains text already merged-, and wanted a working file, regardless brute-forcing.

In case anyone with more insight into color space and color conversion issues (e.g. in cairo's output to PDF surface) than me is following this topic, here are some of the technical details I took note of while testing wiitold's files:

• The tests to save the provided SVG file as PDF reproduce inverted colors with Inkscape 0.91 r13725 and Inkscape 0.91+devel r14245 (latest trunk), using current stable cairo (1.14.2) or cairo git master (1.14.3), and with librsvg 2.40.9 (cairo 1.14.2) on OS X 10.7.5
• Based on tests with archived Inkscape trunk builds, this commit introduced the change in Inkscape 0.91 (compared to Inkscape 0.48.x): r12516
• Another JPEG image I happened to find among the test cases from the bug tracker (otherwise unrelated) which also uses colorspace CMYK, and a (different) embedded color profile, produces the same inverted colors when included in an SVG file and exported to PDF, or when viewed with X11-based 'display' command from ImageMagick.
• ImageMagick version tested to display both CMYK JPEG images: 6.7.8-3, 6.9.1-6

Original background is in RGB so its not problem with CMYK. I saved background as PDF and the imported it to final project and everything went smooth. Colors were ok. But just for sake of discussion and for knowledge, why it happened with JPG, but didnt with PDF?

wiitold wrote:Original background is in RGB so its not problem with CMYK.

*shrug* If you say so …

wiitold wrote:I saved background as PDF and the imported it to final project and everything went smooth. Colors were ok. But just for sake of discussion and for knowledge, why it happened with JPG, but didnt with PDF?

Since the data shared earlier (Inkscape SVG file with embedded bitmap image as background which exported incorrectly to PDF) apparently does not match what original files you actually use (CMYK JPEG vs RGB Image (format unknown)), and it is unknown how that other PDF file now used for the drawing background was created and what it contains, I don't know an answer to this question.

Image information of the bitmap image extracted from SVG file shared earlier, as identified by ImageMagick:(verified as identical by two independent extraction methods: Inkscape's Python 2.7 script (Extensions > Images > Extract Image) and Firefox 38.0.5)

PDF info and list of images embedded in the PDF file shared earlier:

wiitold wrote:I saved background as PDF and the imported it to final project and everything went smooth. Colors were ok. But just for sake of discussion and for knowledge, why it happened with JPG, but didnt with PDF?

As far as I can tell, Inkscape's own PDF importer will encode embedded bitmap images from PDF files always as PNG data.

Converting PDF to SVG using 'poppler' directly (either as Inkscape PDF import option, or on the command line with poppler's 'pdftocairo') on the other hand will use the mime data of the embedded bitmap image if applicable (i.e. not in all cases), and otherwise also seems to default to encoding the embedded image as PNG data in the output to the cairo SVG surface.

The observed inverted colors of embedded bitmap images in cairo-based PDF exports seems to be only triggered with certain bitmap images (embedded or linked in the original SVG) which have mime type JPEG and use colorspace CMYK (i.e. not if the image data is PNG).