[SOLVED] Incorrectly Scaled Drop Shadows in Processed Softproof from Printing Company

[zeronop]

Hi,

I noticed a difference in how drop shadow transparencies are interpreted when viewing some PDFs, and importing a PDF that were exported by Scribus back into Scribus and some other applications. 

I'm using Windows 11, Kubutnu 24.04, and Scribus 1.6.1.

Here are the steps that I took to create the problem:
-Create a new document in scribus.
-Add an image to the layout.
-Add a drop shadow effect to the image.
-Export the layout to a PDF.
-Import the exported PDF back into scribus in a new document.

On Windows, after importing the PDF into Scribus, the images for drop shadow effects look as they should.  If I do the same thing in linux (Kubuntu 24.04), the transparencies are not being interpreted correctly and are semi opaque (see the example images).

I noticed this after getting a soft proof of a PDF from a print company and it wasn't rendering correctly in any application in Kubuntu (Okular, Chrome, Firefox, Krita, Gimp), but it looked fine in every application in Windows (Acrobat Reader, Chrome, Firefox, Krita, Gimp).  The original PDF that I exported out of Scribus (Kubuntu) renders fine in viewer applications (Okular, Chrome, Firefox), and even rasterizes the drop shadows correctly when I import it into Krita or Gimp, but has transparency issues when I import it back into Scribus.

Does anyone know why there seems to be a discrepency between Windows and Kubuntu (Linux) when it comes to rendering transparencies in PDF files?

I've included a test project that I used to generate simple side-by-side example image below.  I also included a real world example of my PDF and the softproof sent back from the printer company showing this problem in Okular.

[AdmFubar]

I'm not having this issue. The file you sent imports correctly. How are you importing/opening the pdf into scribus? Is it via the File/Export/Save as PDF ? or are you using the system printer to "print" to a pdf file?

[zeronop]

I'm not having this issue. The file you sent imports correctly. How are you importing/opening the pdf into scribus? Is it via the File/Export/Save as PDF ? or are you using the system printer to "print" to a pdf file?

Using the file>export option in Scribus.  I haven't tried the print to file option through the print dialog yet.

Just to double check, are you trying to import the PDF into Scribus in Linux?  If so, what version of Linux are you using? 

I suspect this is a "backend" issue.  Kubuntu 24.04 might be using some backend libraries/versions that other distros aren't using to process PDFs, and that might be what is causing this issue for me.  Knowing your distro might help me narrow down a potential difference.

I'm going to try the print to PDF to see if the issue is the same or not.

[zeronop]

Sorry, I didn't answer all of your questions.

How are you importing/opening the pdf into scribus?

I'm just dragging and dropping into Scribus for the import.  I haven't checked to see if there is another way of doing this.  I'll look into that now.

[zeronop]

I just tried saving a PDF of the example project through through the print dialog. I then reimported this new PDF by dragging and dropping (Opening the file through the "file" menu looks to be the same as drag and drop).  The results are the same.  bad transparency on the drop shadow effect.

[zeronop]

I should also mention that I'm working with a fresh install of Kubuntu 24.04 (installed yesterday morning).

I just tried importing the example PDF in Kubuntu 22.04, on a different  computer, using both Scribus 1.6.1 and 1.5.7.  The transparencies imported correctly in this case.

This seems to point towards something outside of Scribus that is used to interpret and render the PDF during export.

I'm not very familiar with what libraries Linux uses to display/process PDFs.  The only thing I'm aware of that might have an impact on this is Poppler.  Checking versions between Kubuntu 22.04 and Kubuntu 24.04, 22.04 uses poppler version 0.4.11-1 and  24.04 uses poppler version 04.12-1.

I don't know if I can backup to the version that Kubuntu 22.04 is using.  I'll look into this, but any help or ideas are appreciated.

[AdmFubar]

Per chance do you have color management turned on?

[zeronop]

Per chance do you have color management turned on?

Turning off color management makes the example PDF file appear as it should after importing it (it was exported in a US Web Coated SWOP color space), but the softproof from the printer is still having the transparency issues in Scribus (Linux and Windows) after importing and after turning off color management. Adobe Acrobat reader and muPDF seem to be the only two applications that can render these shadows in the softproof PDF correctly.


Perhaps this an issue cropping up as the colorspace of the images is ignored or changed when it's being imported between back into Scribus, and there is probably a color space change happening with the printer company imports and exports out of Illustrator.

I understand that some PDF viewers handle different color spaces better than others, that explains why Okular, Chrome, and Firefox are having issues.

I did some snooping with the linux commandline tool pdfimages.  My original PDF that I sent to the printer shows that the images have an icc profile attached to them.  This is intentional, as I work with TIF formated CMYK images with a US Web Coated SWOP color profile attached to them.  On the other hand, the softproof PDF from the printer company, running through pdfimages, shows that these images are listed as just cmyk (as opposed to icc).  I imagine that this is causing issues at some level. 

Scribus imports the drop shadows and patterns.  I wish I could extract the images from these patterns in Scribus in order to examine how Scribus is interpreting the color of these drop shadows after it imports them from the PDF.

[AdmFubar]

When exporting the pdf, are you selecting the colorspace model? there is an option for screen/web, printer. or greyscale.

[zeronop]

When exporting the pdf, are you selecting the colorspace model? there is an option for screen/web, printer. or greyscale.

Yes, I select "Printer" and tell it to "Use Color Profile" before I export, and I can confirm that the profile and color space are being properly preserved in my PDF using pdfimages.  I can also confirm that the printing company is doing another conversion of the all the images in the PDF because the images changed form "icc" to "CMYK" when comparing the original PDF and the soft proof PDF.  I imagine whatever conversion Illustrator is doing to the images in  the PDF is what is causing the rendering issues on my end.

During this troubleshooting process I also learned that Scribus doesn't preserve the color space and profile when importing the PDF back into Scribus.  It seems to be brute forcing a CMYK to RGB color space conversion according to whatever default RGB color profile that is selected in preferences. I can see that this is the case when I check the image properties of any of the images from the imported PDF.  It is using and RGB color profile instead of the intended CMYK one that was being used before export and can be verified inside of the PDF using pdfimages.  I assume the transparencies for drop shadows are falling victim to this conversion process as well, but I can't find a way to extract and image from a pattern in Scribus, so I can't verify this specifically for the drop shadows. 

It's a shame I can't tell the Scribus PDF importer to use native color space of the PDF and the embedded profile, or pick one from a drop down menu of install color profiles.  I don't how realistic it would be to add an option to select the desired color space and profile during the PDF import process, but it would be useful if possible.  I have done command line conversions using ghostscript in the past, and this more manual method allows you to define and input color profile and an output color profile when extractions or conversions of PDFs, so I imagine that this would be technically possible to implement in a front end GUI like Scribus.

Now knowing this, I believe that the PDF being imported and exported through various applications, and PDF viewers interpreting and displaying color spaces and profiles differently from application to application, are some of the reasons why this transparency issue with the drop shadows crops up from time to time.  I'm just going to have to deal with it by checking these softproofs in several different applications to see if they are consistent or not.  If there is a lack of consistency, I just have to choose to trust one and go with (most likely Adobe Acrobat because this is what the printer company is most likely using to check their softproof).  It sucks that inconsistency in PDF rendering in the Linux world keeps me tethered to windows.  It seems like a small silly thing to me, but I understand that color spaces and interpreting color is a complicated thing to deal with, and there aren't any perfect solutions, and plenty of opinions about how it ultimately should be dealt with.

Outside of just not using the drop shadow feature in Scribus, there doesn't seem to be a clear process to mitigate this transparency issue, and this is fine.  I can create drop shadows manually to ensure there aren't any issues with the soft proof (I actually did manually create drop shadows after seeing this transparency issue with the Scribus drop shadows, and didn't see the same problem in the second soft proof from the printing company after replacing the Scribus drop shadows with manually created ones).  I just wanted to make sure there wasn't some bug with Scribus, or some other Linux library, that might need to be addressed.  It's just a difference in how the color of a PDF from application to application.  Ultimately, what actually comes out of the printer ends up being the only thing that a designer can rely to gauge accuracy.

I'm going to mark this as solved at this point.  Thank you for you help and replies!

[AdmFubar]

When exporting the pdf, are you selecting the colorspace model? there is an option for screen/web, printer. or greyscale.

During this troubleshooting process I also learned that Scribus doesn't preserve the color space and profile when importing the PDF back into Scribus.  It seems to be brute forcing a CMYK to RGB color space conversion according to whatever default RGB color profile that is selected in preferences. I can see that this is the case when I check the image properties of any of the images from the imported PDF.  It is using and RGB color profile instead of the intended CMYK one that was being used before export and can be verified inside of the PDF using pdfimages.  I assume the transparencies for drop shadows are falling victim to this conversion process as well, but I can't find a way to extract and image from a pattern in Scribus, so I can't verify this specifically for the drop shadows. 

I i remeber correctly, scribus uses rgb internally. I do belive that there are plans to use cmyk down the road. Hopefully someone with that knowlege will chime in.

[zeronop]

I i remeber correctly, scribus uses rgb internally. I do belive that there are plans to use cmyk down the road. Hopefully someone with that knowlege will chime in.
[/quote]

Scribus supports both RGB and CMYK as far as I know. I bring in CMYK encoded images all the time, and the color management tools will even show you if your CMYK images aren't within the gamut of the selected CMYK ICC color profile. Also, Scribus can export PDFs that can have CMYK encoded images.  Other layout programs, like Adobe InDesign, do the same thing.  So, if a program like InDesign is a good example of support of CMYK, then Scribus would fall into this same category for importing individual images and exporting PDFs

Where it seems to me to be lacking is importing an entire PDF that has CMYK encouded elements in it.  It just seems that when a PDF is imported it forces any images in the PDF to a RGB color space... For some reason.  I can't find a clear explanation as to why this is unfortunately, but I'm also unfamiliar with how other programs handle this, so maybe this is normal behavior for a page layout program.  Perhaps it's something that designers don't need to do very often.  I've only noticed that Scribus does this because I was see weird behavior with transparencies, and was having trouble finding a program that could help check if something was wrong with a PDF that someone had been toying with previously.

A free and long way around what I think is lackluster import behavior is to extract all the elements of the PDF using a tool like pdfimages in Linux (to preserve the native color spaces of the images in the PDF), and then rebuild the PDF from the ground up in Scribus by importing all the elements in one by one and imitating the layout of the original PDF.  This process isn't ideal, and allot of it could be avoid if during the PDF import process the user could select the color space and ICC profile to interpret images with.

[OSDP]

The issues are the conversion (or not) of images to the desired icc profile (CMYK) in final .pdf and interpretations of shadows and transparencies according to third party reading software (may be temporary if only related to your version/configuration of linux), why not exporting your final work in a .pdf that would contain only a single raster image (CMYK) ? You will see on live the results of shading that you can adjust until satisfation by exporting and testing in .tiff or .jpg. You can export this CMYK image, and insert it in .pdf (which will have only a single raster image, no vector font, no shading software effect (from scribus or inkscape).

My procedure is fine for small formats and simple documents: A4, sometimes A3.
I rarely print (and only in four colors) (posters in general).
Beyond that, the .tiff or .jpg will likely be really heavy/too heavy (depending on the nature and complexity of the work).
And it is true that this requires additional steps (which I have not specified):

For example, if I have to take out a final .pdf in A4 300dpi, with a 5 mm requested bleed, I must think of composing and working my Scribus document in «custom format», so as to export my image .jpg or .tiff with adequate bleed integrated in output ! Very important here. For this example, 10 mm more in width and height. So, my work/document .sla (and my .jpg/tiff output image) "A4" will then have to be 220 x 307 mm (custom format, with a bleed zero for this step) instead of 210 x 297 mm (A4 format).
To «see» the bleed area, you can put a colored shape (A4 format) on a dedicated layer in the background.

And to finalize it in .pdf for printing, I reimport the 100% raster image from this first .sla in another .sla document (this time in A4 format via the Scribus interface, setting a 5 mm bleed), and by shifting the image to "x" and "y" (in this example: -5 mm and -5 mm).

This either wastes time, or actually saves time, depending on the outcome. The first time, it is quite laborious (especially since Scribus does not propose the «pixel» unit; and it will be necessary to convert millimeters into pixels as the reverse to find themselves in the «process»). The next time, it's better. In any case, the potential issues related to effects (shadows) and fonts "no longer exist" with the printer. (You will have to manage them yourself if there are any; until .jpg/tiff comes out as you want). For transparencies, the same will be checked "in output" if everything is "ok".
It may be quite laborious, but in the end, the final .pdf should not pose a problem: it is "like printing a photo".

In some circumstances, it may be useful !

[OSDP]

The icc color profile of an image or document can be RGB or CMYK. You can also export an image or a .pdf without integrating an icc color profile (it does not prevent that it will have been created from an RGB or CMYK icc profile).

Some export of .pdf accept RGB and CMYK images mixed.
Others (dedicated to printing) convert all content into CMYK.
Some pdf exports do not accept transparencies, others do.

https://en.wikipedia.org/wiki/ICC_profile

https://en.wikipedia.org/wiki/PDF

https://pdfa.org/resource/pdf-specification-archive/

https://pdfa.org/pdf-standards/

https://helpx.adobe.com/acrobat/using/pdf-x-pdf-a-pdf.html

https://www.adobe.com/uk/acrobat/resources/document-files/pdf-types.html

[AdmFubar]

The best I could do is using PDF/X-4 for the exported PDF. but this still has a small off white border around the shadow when imported into scribus on linux.