Bad render results on PDF export

[Vosje]

Hello, there's something strange with the PDF that I just made using Designer... In Designer, all lines are very sharp and crisp. But when I export my file to PDF, the line belonging to the SAME vector object is sharp and crisp in one place, but kinda blurry in the other one... It's a straight vertical line and when the PDF is viewed at a certain zoom it even seems that it's not even straight but has a "break" point.

I suppose it shows this way because the part where it gets blurry sits under a shadow effect of a different object (orange stars). I guess the line is blurry where shadow overlays it... But, I am not quite sure how to "fix" this. Is this a bug or just the way Affinity export works?

Below are attachments (zoomed in greatly) so you can see the difference.

[Old Bruce]

I am going to wager that that will be from the Drop Shadow(s) on the Star(s). You could try and rasterize them first. Do so on a duplicate and hide the originals.

[Vosje]

26 minutes ago, Old Bruce said:

I am going to wager that that will be from the Drop Shadow(s) on the Star(s). You could try and rasterize them first. Do so on a duplicate and hide the originals.

Thanks for your reply! You're right in the fact that rasterizing the whole image makes the line exactly the same for the whole object. However, rasterizing it makes it pretty burry at the zoom level that I've used to produce the screenshots. 😆 I guess the difference won't be noticeable if you print it anyway...

[loukash]

7 hours ago, Vosje said:

I am not quite sure how to "fix" this

If your print shop accepts it, export based on PDF/X-4 or PDF Press Ready. Those formats support pixel alpha channels, and your vectors under the shadows should remain intact.

[loukash]

In fact, here's my own analysis of Affinity's PDF export problems with transparencies:

As it seems though, this is likely primarily a shortfall of the 3rd party PDFLib that Serif is using. It's rather pathetic compared to Adobe PDF Library even a decade ago.

[lacerto]

8 hours ago, loukash said:

As it seems though, this is likely primarily a shortfall of the 3rd party PDFLib that Serif is using. It's rather pathetic compared to Adobe PDF Library even a decade ago.

It may be that the so called "PDF compatibility rules" that are applied within Affinity apps (and as far as I know them only when we are talking about professional page layout apps), ignoring of which results in rasterization (and typically total ruin of placed PDF content to adhering to those rules, e.g. rasterization of embedded fonts, translation of color values, K100 turning to four-color-blacks, loss of overprint and spot color information), are PDFLib based.

But I see no reason why Affinity apps could not try to preprocess the job and flatten the transparencies by using Boolean operations so that rasterization would not be needed. Or at least develop this feature in the UI so that the user could apply it where needed. One good reason probably is that Affinity apps still struggle, also in version 2, with basic Boolean operations, even if e.g. Division, that is useful in transparency flattening works now much better than in version 1 apps. Having transparency flattening as an app feature, like in Illustrator (or Adobe Acrobat Pro) would be very useful, as it would work around library based limitations and would basically allow you to produce 100% compatible DeviceCMYK PDF 1.3 compatible production PDFs that can be printed anywhere.

I am not an expert in printing but I have understood that live transparencies are still out of reach of many print shops. See this related discussion and what is mentioned by David Milisock on CorelDRAW (which also cannot, even in version 2022, do transparency flattening library based, nor does it have direct/assisted support for it in the app) forums:

https://community.coreldraw.com/talk/coreldraw_graphics_suite_x7/f/coreldraw-graphics-suite-feature-requests/65825/exporting-complex-transparencies-and-gradient-designs-from-coreldraw-2020-to-pdf-and-losing-gradient-colour-definition

But if it is available, it is definitely advisable not to use PDF/X-based production methods because of mentioned internal issues [in situations there is placed content to be passed through]. ALL other export methods support live transparency as they are PDF 1.4+ based. PDF 1.3 [besides PDF/X-1 and PDF/X-3] is the only level that does not allow them, and as this method is not supported by Affinity (PDFLib), this causes issues that many have with PDF/X-1a:2003, as it is based on 1.4 while many preflight apps might check version 1.3 as a sign of guaranteed transparency flattening, and accordingly might discard files that are technically perfectly printable. 

As mentioned, Affinity apps are not alone with this problem. As far as I know only Adobe apps and QuarkXPress can handle this well.

[Vosje]

Thank you very much for your replies! You're right, @loukash, using PDF/X-4 or PDF Press Ready fixed that, the line is now perfect! And @lacerto, thanks for your comment, I did indeed use PDF/X-1a:2003 the first time, because for whatever reason sometimes Affinity fails to export to PDF/X-4 (couldn't figure out why yet) and PDF/X gives more consistent results color-wise compated to PDF Press Ready when you need to keep a certain color profile... So I figured it's easier to just use PDF/X-1a:2003 for most stuff, but now I see that it also has its limitations!

[loukash]

1 hour ago, lacerto said:

live transparencies are still out of reach of many print shops

Pehaps it's just me, but I'd expect a professional print shop to have a license for Acrobat Pro or a professional equivalent. And in all my tests so far, even the old Ac Pro X can convert any PDF/X-4 from Affinity to a correctly flattened PDF/X-3 on a simple click of a button…

But thanks again @lacerto for your competent explanations in all details.   

[lacerto]

25 minutes ago, loukash said:

Pehaps it's just me, but I'd expect a professional print shop to have a license for Acrobat Pro or a professional equivalent.

Certainly. But I find it very surprising hearing those kinds of figures as of availability of live transparency capable RIP. It may actually be that many print shops that say that live transparency is ok actually just use prepress software, even just Adobe Acrobat Pro, for flattening (and keep flattened colors in vector format whenever possible) rather than pass the job directly to RIP.

We practically never use PDF/X-based production methods but we always use PDF 1.4 or later so leave transparencies unflattened. The recommended PDF color space here in Finland is however nearly always DeviceCMYK, no embedded ICCs, targeted to printer-recommended profile, and sometimes a paper-specific profile. Never experienced problems, not with small or big printers. Requiring flattened transparencies is rare, but based on numerous topics on these forums, it seems that this is required by many self-publishing services targeted to general public, including ones like Amazon. 

[lacerto]

1 hour ago, Vosje said:

PDF/X gives more consistent results color-wise compated to PDF Press Ready when you need to keep a certain color profile... So I figured it's easier to just use PDF/X-1a:2003 for most stuff, but now I see that it also has its limitations!

PDF/X-4 is fine also in Affinity apps, just be careful with it if you have any placed PDF content to be passed through that it does not get rasterized. If PDF/X-4 is not supported by the printer, but transparency flattening is not required, the most robust workflow would be using CMYK/8 document color mode with printer-recommended CMYK target profile, then export using the default "PDF (Press ready)", but unchecking "Embed ICC Profile" option, and checking "Convert Image Color Spaces". This makes the file such that all native and placed image color values are resolved, leaves transparencies unflattened. and is compatible with practically all placed PDF content. This would not require premature rasterization at non-optimal resolution but would still give you a PDF that shows colors as predictable as possible before sending the file to the printer.