Strange PDF transparency effect with PDFs created by v2.2.1

[Lorox]

Hi there,

today I've noticed that PDFs created with Designer or Publisher v.2.2.1 are showing up strangely in PACKZVIEW (which is the app I have been using for some time now to check colour separations and overprinting in my PDFs which I'm going to send to a printing service).

I'm attaching two AD files (v1.9.3 and v2.2.1), the two PDFs created from them (from AD v1.9.3 and v2.2.1 respectively) and a screenshot of PDFs of these 2 test files viewed in PACKZVIEW: on the left there is a PDF created in Designer 1.9.3 and on the right there is a PDF created from the very same file after opening the v1 file in Designer 2.2.1 and then again creating a PDF with the same settings as before.

As confirmed by looking at other PDFs created from real Publisher files it seems pretty obvious that there is a problem with elements having transparency of one kind or another: in PACKZVIEW these elements are not rendered as should be expected but – as you see – are displayed just as light pink rectangles. (This is – e.g. – also true for elements with non-100%-opacity as well as for curves with strokes that use brushes which have transparency)

PDFs with transparencies output from Publisher/Designer v1 are absolutely fine and display correctly in PACKZVIEW and I'm quite sure PDFs have also so far been displayed correctly when created from Publisher/Designer v2.2.0 (although – having updated to v2.2.1 recently – I cannot positively test this like I did with v1.9.3 which I – fortunately – still have on my Mac).

Nevertheless, ALL of these PDFs are being displayed correctly in Acrobat Pro ([which I still have on another older Mac] and any other [just] PDF viewers I have available like Acrobat [Reader] or macos's "Preview" app). This being said I do hope the PDFs will actually print correctly after all... but it is certainly more than a bit discomforting when my current and hitherto reliable PDF checking app is having these problems with PDFs from Affinity v2.2.1.

Obviously, I'll also report this strange behaviour to the guys at PACKZVIEW, but as PACKZVIEW's problems with displaying transparency in my PDFs seem to have started just after the update from Affinity v.2.2.0 to 2.2.1 I strongly suspect there must be something different in PDFs with transparencies output from Affinity 2.2.1 than it has been before.

*** PS ***
Looking at my most recent Affinity files for print I may(!) have been wrong that PDFs for print from Publisher 2.2.0 were (or would have been) OK – it looks like the latest Affinity files with transparency (and which were OK) I have actually exported as PDFs for print from v1.9.3 (and not from v2.2.0).
So there is a real chance that the effects regarding my current version 2.2.1. which I've described above would actually already have been the same in v2.2.0 – but I cannot check this as due to updating I do not have that version on my Mac anymore.

 

Untitled_AD1.9.3.afdesign Untitled_from-AD1.9.3.pdf Untitled_AD-2.2.1.-from-original-AD1.9.3.afdesign Untitled_from-AD-2.2.1.pdf

Edited November 15, 2023 by Lorox
PS added

[lacerto]

I think there are issues with latest versions of PackzView:

As you can see, it fails to show the shadow, and the black plate. The files show identical in Adobe Acrobat Pro 2020. Neither file has overprints or transparencies, and both are DeviceCMYK.

EDIT: Something has changed, though, because the file produced by an earlier version still shows correctly. 

EDIT2: I cannot reproduce the issue from macOS version of Designer 2.2.1. Perhaps there is some specific setting that causes this? OR: Hardware (display), OS specific issue: I am running macOS Sonoma 14.1.1 in native Apple Silicon mode, no disabled performance settings.

[Lorox]

As the shadows (inner and outer) are applications of transparency within Designer it seems to be related to transparency to me.

Interestingly just reducing the opacity of an element does not produce the issue. (See attached screenshot)

And yeah, possibly even the PDF from AP v2.2.1 as such is in fact OK and the failure to display it correctly actually lies with PACKZVIEW (I have versions 8.5.3 and 9.0.1 which both show the issue). But still – as you also notice – the PDF created in AP 1.9.3 (or possibly 1.10.x) shows correctly. This strongly suggests that there must be something different in the  the PDFs created in Affinity v2.x as opposed to v1.x

As to system configuration maybe playing a role: here it's an 2019 iMac Intel running Monterey 12.6.7 which is quite different to your setup and yet yields the same results.

[DWright]

This is a  PackzView issue as the PDF displays correctly in Safari and Apple Viewer

[loukash]

3 hours ago, DWright said:

This is a  PackzView issue

It is an Affinity v2 issue because PDFs exported from v1 don't show this symptom:

3 hours ago, DWright said:

the PDF displays correctly in Safari and Apple Viewer

No offense, but Apple's PDF preview or the Preview app have hardly any relevance in a preflight workflow…  

[Lorox]

@loukash I totally agree...

However, as the PDFs from v2 at least appear to display correctly in (different versions of) Acrobat Pro, I'm hoping there will be no adverse effects when used in commercial offset printig. But of course, this does make me feel a bit nervous, nevertheless.

[loukash]

25 minutes ago, Lorox said:

at least appear to display correctly in (different versions of) Acrobat Pro

Yes, I remember checking some affected PDFs in the old Acrobat X recently, and all looked correctly.
Also the trial version of PDF Studio 2023 displays my PDF/X-3 files correctly (aside from all the issues that PDF Studio has on its own…)

PDF/X-4 export is not affected as far as I can tell.

[lacerto]

6 hours ago, Lorox said:

However, as the PDFs from v2 at least appear to display correctly in (different versions of) Acrobat Pro, I'm hoping there will be no adverse effects when used in commercial offset printig. But of course, this does make me feel a bit nervous, nevertheless.

I have a bad habit of editing my earlier posts, but as I mentioned above, I tried to reproduce the issue in 2.1.1 (macOS) Affinity Publisher Designer with the file you provided, but could not produce a similarly crippled version with an issue with the shadows. As for "transparency" and "overprint", I merely quoted Adobe Acrobat Pro information as for lack of these properties in the referred production file showing the issue.

So it might be something system/hw-dependent (but probably not a specific setting) that causes this, but for some reason only shows in PackzView (and might be a trivial view-only issue, as you hoped). I have experienced a couple of other problems with the latest versions of PackzView, and these, too, were such that do not show in Adobe Acrobat Pro. Have to look back my recent posts to check if it might have been something related, and which could help explaining also this anomaly. 

UPDATE: Sorry, I examined poorly your production file, and now that I created a PDF/X-1a:2003 file with defaults from Designer 2.1.1, can also create consistently this issue. I have not been able to pinpoint the difference, yet, but perhaps it is related to compression. Anyway, the file with issues passes without errors Adobe Acrobat Pro v2020 PDF/X-1a:2003 verification test.

[lacerto]

I have tried to compare the internals of the two PDFs that you provided, but not with results that show any obvious difference that could explain the anomaly in PackzView. I was suspecting that there is some difference in use of mask when knocking out the shadow effect, which could explain the strange omission of the shadow and the black plate in PackzView rendering, but the only difference so far I have found is that the name of the intent ICC profile, and its MD5 hash tags, deviate from each other in these versions. -- Which basically IS odd since the profiles are supposed to be exactly same. The size of the transparency flattening (rasterization) is also different: 733px vs. 730px. 

These are screenshots of PDF/X-1a verifications run in Adobe Acrobat Pro 2020, both files passed through without errors.

[Lorox]

AI just made somewhat surprising observation when sending some files to the guys at HYBRID Software (PACKZVIEW) – see attached screenshots:

when single clicking on (selecting) the attached PDFs in Apple Mail the display of the "selected" state differs in the area of the problematic elements. The screenshots have been taken before the email was sent.

However, now when I look at this very message in my sent mail folder and again click on the attached PDFs the blue overlay (marking the "selected" status) covers the whole area with no knockouts whatsoever... Strange!

Or does Apple Mail possibly just create a preview image(!) of PDF attachments while processing the message during the "Send" process? In that case the original data from the PDFs would only be used prior to actually sending the message (which would explain the differing display before and after sending).

Anyway, it seems, though, that even Apple Mail sees something different happening in those PDFs from AP 1.9.3 and AP 2.2.1...

 

Edited November 17, 2023 by Lorox
new screenshot attachment

[thomaso]

Since this thread slightly focusses on PACKZVIEW: Do any of you know a way to get accepted for their app use without working in the packaging industry and without having a corresponding company website or even any own website?

[Lorox]

6 minutes ago, thomaso said:

Since this thread slightly focusses on PACKZVIEW: Do any of you know a way to get accepted for their app use without working in the packaging industry and without having a corresponding company website or even any own website?

Unfortunately I really don't know and cannot say anything about their policy and requirements – as I actually have been doing work for different sorts of packaging over the years (as for other areas of graphic design) I just like to count myself lucky to seemingly fitting the bill for them.

I remember, though, that there used to be a thread on this forum about alternatives to Acrobat Pro quite some time ago where PACKZVIEW got mentioned several times. Maybe there is some more information about this  be found there?

[loukash]

11 hours ago, lacerto said:

the only difference so far I have found is that the name of the intent ICC profile

But that would explain it, as it's a known and documented Affinity bug. Possibly Packzview can't handle it as graciously as Acrobat and others do?

[loukash]

2 hours ago, thomaso said:

Do any of you know a way to get accepted for their app use without working in the packaging industry and without having a corresponding company website or even any own website?

At first I was rejected with "This is an invalid website. The website URL and e-mail address should be from an existing labels/packaging company."
22 months later I tried again, and all of a sudden my puny self was considered "worthy". Halleluja praise the Gawdz of Packz!

[Dazmondo77]

1 hour ago, loukash said:

At first I was rejected with "This is an invalid website. The website URL and e-mail address should be from an existing labels/packaging company."
22 months later I tried again, and all of a sudden my puny self was considered "worthy". Halleluja praise the Gawdz of Packz!

For mac based designers who's work is destined for print, Packzview is pretty much essential for getting a job out the door, and I'm one of the lucky ones who very occasionally have done a spot of packaging design which features somewhere on my web portfolio, but such a shame that self employed / freelancers can't get a Packzview request approved without a back catalog of packaging design - there is a gap in the market waiting for an app suitable for PDF print ready compliance, although I have a mojave MBP that also still runs Affinity 1 and CS5 Acrobat pro 9 if I have any concerns - the only other option that that doesn't have a £1000+ annual subscription is callas pdfToolbox Desktop which is £625.

 Am I right in thinking that PC's running 64bit can still run 32bit apps? If so an old version of Acrobat is still usable.

I can't believe there's nothing else available to check PDF's. I was kinda hoping that serif would step in and some point and maybe add a Print ready checkup persona so you could check separations, Ink density and PDF/X compliance before sending a job off to the printers - I would also be handy to be able to print proper CMYK to postscript devices. 

[lacerto]

4 hours ago, loukash said:

But that would explain it, as it's a known and documented Affinity bug. Possibly Packzview can't handle it as graciously as Acrobat and others do?

It is a possible cause, though I do not understand why it should happen (which is of course just a "common sense" argument, and ultimately based on ignorance). The issue is there also when producing PDF/X-3 based exports (from Affinity apps), so whenever transparency flattening is forced (and within Affinity apps, this only happens when using PDF/X-1 or PDF/X-3, as plain PDF 1.3 that would do that, is not supported). As for PDF/X-3, supporting mixed color spaces (and basically allowing generic ICC-based color processing and multiple embedded ICC color spaces), complex situations can arise, but within PDF/X-1, everything should be resolved already in the source and nothing left for interpretation so basically having a profile intent -- even if an erroneous one, as with recent Affinity apps with strange misspelling and false MD5 hash tags -- this should "in principle" be irrelevant for rendering, because only native color values should matter. 

But I am definitely out of my breath here, so I am reasoning just based on comparison with what works, so as you mentioned, perhaps Adobe software, and more generally RIP software, even if not by Adobe, safely just drops something that does not make sense, like references to non-sensical, misspelled ICC profiles. 

[lacerto]

3 hours ago, Dazmondo77 said:

Am I right in thinking that PC's running 64bit can still run 32bit apps? If so an old version of Acrobat is still usable.

I am not sure if I understood your question -- certainly everything 32-bit still runs on all 64-bit Windows platforms, including Adobe Acrobat X, etc. There might be occasional glitches with activation when running modern CC-based subscription software concurrently with legacy perpetual license based Adobe software on the same computer, but these kinds of complex situations can still be resolved either by cleaner software provided by Adobe, or live, by help of their chat support personnel. The actual issue, and reason for incompatibility, is basically Apple, not Adobe. [EDIT: As for Adobe, I have understood that actual activation support is only available for CS6-based apps; this, however, is not a technical limitation based on Windows, but an Adobe-chosen restriction.]

[lacerto]

8 hours ago, Lorox said:

Unfortunately I really don't know and cannot say anything about their policy and requirements – as I actually have been doing work for different sorts of packaging over the years (as for other areas of graphic design) I just like to count myself lucky to seemingly fitting the bill for them.

I have never done anything directly related to packaging (if custom CD-ROM/DVD covers do not count), but perhaps they scan VAT registers, indicating true professional activity, and public company registers implying involvement in the field of graphic design (e.g., in Finland, there are public codes that indicate this). I do have a nominal company web site, too (even if using national suffix), so that might be something that they check, as well. 

[Dazmondo77]

On 11/17/2023 at 9:39 PM, lacerto said:

certainly everything 32-bit still runs on all 64-bit Windows platforms

That was my guess, as I've not had access to a pc for around 10 years 👍