Tranparency in PDF not respected at printers...

[ajpeck123]

Hi guys. I've created a cover for a journal I typeset. It has some words in white text on a transparent background overlaid on a blue background. It looks fine in Designer. It looks fine in the PDF I generate to send to the printer.

BUT the proof I get back from the printer has a white box (background) around the words. The transparency is ignored. I don't know if this is a one-off anomaly or whether I'm missing some setting somewhere. The only way we've got round it is for me to export the cover as an image, not a PDF.

On the same advert is another area (down the bottom) with white text set on a blue background - and that works fine.

The only thing I can think of is the effects on the upper text.

It's not a big deal in this case, but I would like to understand why it isn't working so I don't keep making the same mistake.  If I could see a difference here, I could play with settings until I fix the problem - but all looks fine at this end. It even prints OK on my own printer.

Thanks in advance for any tips/pointers...

Alison

[Dan C]

Hi @ajpeck123,

Sorry to hear you're having trouble!

1 hour ago, ajpeck123 said:

It even prints OK on my own printer.

If this is printing fine on your printer, I suspect I would see similar results testing the file here. This means I can certainly look into a possible cause for you, but it may be harder to confirm without being able to replicate this.

Have you spoken with the printers to ask if they know what may have caused this? As it may be a nuance regarding their printer/software that I'm not aware of and it's unlikely investigating your file without this printer/software would show this.

Can you please confirm for me, what PDF export settings did you use from Affinity? Are you able to attach a copy of this PDF file here for me?

[ajpeck123]

I have rung them this morning about something different and got to talk to them to find out when the problem was occurring... apparently, they put the file into InDesign to do their pre-print process, and that's when it shows the white background. I basically get a white rectangle the size of the text box containing white text and a black surround.

I've saved the PDF settings as a preset as I use them all the time. Sending it as a TIFF enables them to print, but I'd still like to know how to avoid it.

I have access to InDesign through a third-party and I'm going to ask if it would be OK to try it out. 🙂 I think they'll say OK... hope so.

Any tips gratefully received.

Alison

JoinACCU-2.pdf

[Dan C]

Many thanks for the information, screenshots & file provided - this is certainly appreciated

I have placed your PDF file into an InDesign document here, however the 'white box' does not appear in app, nor when I print directly from InDesign:

I'd recommend changing the Compatibility dropdown when exporting to PDF/X-4 as this should hopefully correctly calculate the transparencies in the PDF file.

Please do let me know if this helps!

[lacerto]

Perhaps the file you attached in your post was accidentally produced with some other settings, but it was not a PDF/X-1a-based file, which forces all colors to be converted to the destination CMYK color profile (= a "Device-CMYK" file which does not have ICC profiles embedded because all color values are already resolved and final). In addition, all transparencies should be resolved. Your attached PDF contains images in sRGB color space and additionally has transparencies. Mixed color spaces probably cause the white rectangle when the document is finally flattened and rasterized.

My guess is that what has happened is that you have PDFs in your document and they are placed to be passed through (e.g. to avoid rasterization of embedded fonts). This works badly with Affinity apps in context of PDF/X based methods, and often causes failure of the intended PDF/X features and the placed PDFs to become rasterized (meaning also that embedded fonts will be rasterized, possible CMYK color values recalculated and overprint settings lost). Using "PDF (press ready)" preset would probably let you pass through placed PDFs without causing rasterization but you would not be able to produce a flattened all-CMYK PDF this way, if that was your intention. If those magazine images are really placed PDFs, you might want to rasterize them already on the canvas (which should allow keeping the outlook of the fonts even if they are not installed on the system), and then export using PDF/X-1a:2003. 

EDIT: Similarly as @Dan C, I have no problems when subsequently producing the file you had attached from InDesign, no matter which PDF settings I use, so the transparency around the text frame is flattened without any artifacts. It remains unknown why this happens; trying to create a single color space transparency flattened export file, as you did, is the best way to avoid further problems in production, but this has probably failed because of reasons mentioned above.

[ajpeck123]

OK, thanks everyone.

No PDFs embedded in any way in the file I sent. All text is just that - text. The 4 cover images were jpg. And everything else was drawn in Designer.

I'll try the export option you suggest.

Weird that this is the only one this happens with. 😞

Alison

[lacerto]

58 minutes ago, ajpeck123 said:

No PDFs embedded in any way in the file I sent. All text is just that - text. The 4 cover images were jpg. And everything else was drawn in Designer.

Ok, sounds odd. Normally PDF/X-1a based exports are a safe choice not causing any surprises if there are only native elements and placed RGB images.

[ajpeck123]

I'm just going to treat it as one of life's little mysteries. If it happens again, I'll try to work out what the common factor was. The only different about that particular white text to the white text at the bottom was the text effect. The shadow. I'll look at other files to see if the blend mode is different - that's the only remaining thing I can think of.

[PixelEngineer]

I would highly recommend that you take Dan C's advice and export to PDFX-4 especially for the projects that include transparencies. 

Export to PDFX-4 specification for jobs like this. It is to my understanding, PDF/X-1a is basically an older version of PDF/X (that is still widely used today). PDF/X-1a flattens the transparency to opaque objects that can and often results in artifacts that include stitching lines, which is probably what you saw in your proof. 

PDFX-4 provides superior output in regards to transparency. Apparently for whatever reason there seems to be a lack of education regarding this among certain print operators. 

Also in PDF/X1a you will need to know what CMYK to use or you will get color issues as it is device-dependent, the print shop needs to specify to you what CMYK to use. PDFX-4 handles color management very well for those that know how to incorporate it into their workflow and will give more predictable results on intended output as it is device independent unlike PDF/x1a.

Use PDFX-4. First find out if the printshop handles that format in the first place. If they do ask them specifically how to export it properly.

 

Below are some links that may be related to what you described. If it sounds like a possible workaround, communicate this with your printshop perhaps it will help them help you if you encounter this exact problem again should that exact type of problem appear again. Ultimately they will have to make that decision.

https://www.graphicdesignforums.co.uk/threads/indesign-problem-with-shadows-on-exporting-for-pdf-x-1a-2001.13669/

https://forums.macrumors.com/threads/drop-shadows-in-pdf.331676/

Since your snapshots indicated that you exported out to PDFX/1a 

Summary of possible workaround.

The latest Adobe Acrobat Reader should have overprint view on by default for viewing overprint of PDFX files.

Print operator:

open PDF in Adobe Acrobat and Press Overprint  and then  proof 
Also print operators need to make certain that overprint is set correctly at the RIP. I've been on some printer forums and some operators don't know where to find it LOL because it may not be specifically listed as overprint.
They may or may not approve this. That is entirely up to their them. In determining if this is a ri$k or not.

 

 

[ajpeck123]

Thanks... will do.

I will report back - but I'm not going to know until I next send this particular file to the printers (maybe in a month or so - we rotate the advertisements). It's not happening with anything else, although I will use PDFX-4 across the board from now on. 🙂

[Hangman]

It makes me smile as this conversation has come up several times before in the forum with some users insisting that PDF/X-1a is still a standard widely used today (which I don't deny but that's not the point) poo pooing when I've suggested they should be using PDF/X-4 as @Dan C, @lacerto and @PixelEngineer have also suggested...

As others have said in this thread, PDF/X-1a does not support transparency hence the issue here, simply placing the file into InDesign won't show the issue, it's all about how the print company you're using is then exporting the file from within InDesign.

A quote from the PDF/X-4 specs...

"The previous PDF/X variants do not support the features of more modern (beyond PDF 1.4) versions of PDF. By 2008, it was time to bring PDF/X up to date with current PDF specifications. PDF/X-4 is based on PDF 1.6, published in 2004. This specification added support for new features, including layers, JPEG2000, OpenType fonts, and 16-bit images. In addition, PDF/X-4 allows the use of transparency, a PDF 1.4 feature forbidden in PDF/X until PDF/X-4."

As @lacerto also highlighted, the PDF file you uploaded is not a PDF/X-1a file but rather a PDF 1.7 file, so I believe his comments are correct...

On 6/27/2022 at 5:54 PM, lacerto said:

Perhaps the file you attached in your post was accidentally produced with some other settings, but it was not a PDF/X-1a-based file.

I also think this issue perhaps highlights some things Serif needs to do moving forwards to be taken seriously in the print space, i.e., proper professional print and colour management. When you have printers taking a client supplied PDF from Affinity software and then placing it into InDesign to output it then you know something is very wrong. If Serif can reach the point where they are taken as seriously as Adobe when it comes to professional print by both commercial printers and RIP manufacturers then I think they are on to a real winner and they will see a far bigger transition from Adobe to Serif increasing market share dramatically.

I believe @PixelEngineer has partially quoted from a response made to a similar question that appears in the Adobe forums (please correct me if I'm wrong about that) but it's really worth seeing the reply to the question in full because it was made by Dov Isaacs, former Adobe Principal Scientist (April 30, 1990 - May 30, 2021) so I think it can be taken as read he knows what he's talking about and I agree with him 100%...

This is what he had to say in 2017 in response to a question regarding the use of transparency where the print company had specified PDF/X-1a as the required PDF format after the user had created a very complex, "intricate 474 page book which included lots of art, texture and transparency"...

"For reliable PDF print publishing workflows, PDF/X-4 is strongly recommended as the PDF subset standard to use. PDF/X-4 supports live transparency and ICC colour management.

On the other hand, PDF/X-1a forces all transparency in your original content to be “flattened” into opaque objects and all colour to be converted into DeviceCMYK. The flattening process often results in quality degradation with flattening artifacts including stitching lines. Conversion to DeviceCMYK assumes that whoever directs you to convert to CMYK actually tells you which CMYK!!!  US Web Coated SWOP? FOGRA? Which? If this isn't specified by the print service provider, expect colour “issues” when printing.

Ironically, virtually all RIPs / DFEs (Digital Front Ends) sold over the last ten years support live transparency, colour management, and PDF/X-4. It is the fear and ignorance of many print service providers that causes them to either require or request PDF/X-1a. Luddites!! In fact, RIPs / DFEs that support PDF/X-4 will yield superior output with PDF/X-4 as opposed to PDF/X-1a generated from the same original content that had live transparency. The PDF file will generally be smaller and RIP faster as well!

All that having been said, if you are not able or willing to find a print service provider who has entered the 21st Century, if you carefully prepare a PDF/X-1a file, you may get acceptable results if and only if the print service provider provides you with the information as to (1) what the CMYK colour space they use is and (2) what the resolution is that they print at. Flattening should be done at a resolution close as possible to that of the rendering device (much of flattening prematurely converts text and/or vector objects into raster images if one or more of the overlapping objects in transparency are raster images).

And optimise for quick web view is totally and utterly irrelevant for printing in any way! (Tends to confirm ignorance of whoever is providing these specifications!)"

[lacerto]

On 7/20/2022 at 7:45 PM, Hangman said:

poo pooing when I've suggested they should be using PDF/X-4

There are other aspects than simplistic "the most recent is the best".

I have included here a PDF/X-4 export of a CMYK document where the underlying RGB color space of the document is sRGB and the CMYK target PSO Coated V3, and where four PDFs have been placed (that is, to be passed through), all produced in InDesign having Adobe RGB as the RGB color space and ISO Coated V2 as the CMYK color space. They were exported as PDF (Press Quality) = PDF 1.3 (no PDF/X standard), PDF X-1a:2001 (PDF 1.3), PDF X-3 (1.3), and PDF X-4 (1.6).

The correct behavior is shown in the attached InDesign exported PDF/X-4 document. However, when this job is exported from Affinity Publisher, it can be seen that a PDF that is not PDF/X-based (but plain and simple PDF 1.3 based device-CMYK document), has been rasterized (texts included), its overprint status of Y100 lost, and PANTONE color lost. This happens with all PDF/X-based production exports in Affinity apps, so it is clear that PDF/X-based export methods cannot be recommended without serious reservations. E.g. in professional use it is common to have third party ads and other documents (logos etc.) placed, and they often come produced in varied ways. Requiring that these kinds of documents need to be produced using a specific standard is absurd. Affinity apps have a unique PDF compatibility rule according to which the placed PDFs need to be produced in version lower than or the same as the host document will be exported (and not just PDF version number but also PDF-X version number; this means e.g. that if the host PDF needs to be exported using PDF/X-3 on printshop's requirement, not only non-PDF-X based but also all placed PDF/X-4 documents will be corrupt). This does not have anything to do with the producer of the PDFs so this happens also with Affinity-produced PDFs.

In practice the most robust export method when using Affinity apps is using PDF (for press) with PDF 1.7 (highest version available) and then uncheck profile embedding (embedding the profile will confuse e.g. Acrobat Pro and hide an overprint status of objects even if they have them; embedding a profile makes the document ICC-dependent and also requires selecting the correct simulation target in Acrobat Pro, another thing that confuses users, including those working at printshops, and causes color values to be shown incorrectly in PDF Output preview).

Affinity apps also always convert native objects (text and shapes) to CMYK color mode when exporting for press, even when using PDF/X-3 or PDF/X-4, which do not require conversion. Placed images in RGB color mode, however, are not converted unless forced. Effects not flattened might have RGB-based calculations applied. These kinds of factors are a reason for all kinds of confusions and problems, especially in context of objects with transparencies being in mixed color spaces and showing artifacts in diverse production stages (in exported PDFs, local prints, print proofs, etc.). 

Professional preflight software is often needed to be able to check that final print exports from Affinity apps are produced as required and behave as expected. This may become as a surprise for many who have previously been using Adobe apps or QuarkXPress, or other professional color managed software.

Another problem is that many large publishers that offer print services to general public, e.g. Amazon, may have strict specs for production. The instructions have often been created just for Adobe InDesign or QuarkXPress, or even for Word and Pages, and in this case be sRGB based. In practice many such big publishers simply just discard any embedded color profiles. In such situations it is clear that the best solution is to deliver a PDF that only has one color space, which means sRGB in RGB based workflow, and device-CMYK color space (normally produced for coated stock with around 300% TAC with profiles like US Web Coated, which is also the default in Affinity apps). Having ICC profiles embedded will not cause the desired effect in such production environment. In practice it is then often safest to produce a device-CMYK production file using a generic profile for the kind of stock that will be used on print.

Things like these explain why recommendations on creating device-CMYK production files keep on be given on this forum. Giving a generic recipe like "just use most advanced technology PDF/X-4", without consulting the printshop (or even against their recommendations), and without realizing or understanding the inherent problems with Affinity apps, is silly. It would be that also in context of Adobe apps and QuarkXPress, which can handle PDF production well no matter what kinds of placed documents are involved and what is required by the printer.

It does not much help that frustrated users blame such big operators as Amazon for bad co-operation and require them to change their production specs. Their workflows, preflight checks etc. may be old-fashioned and their technical support ignorant and naive, but if the users want their jobs be printed without surprises, it is best to adapt, or look for another printer.

pdf16_pdfx4_psocoated3_id.pdf

pdf16_pdfx4_psocoated3_apub.pdf

pdf17_pso3coated_apub.pdf

 

[Hangman]

On 7/20/2022 at 9:58 PM, lacerto said:

I have included here a PDF/X-4 export of a CMYK document where the underlying RGB color space of the document is sRGB and the CMYK target PSO Coated V3, and where four PDFs have been placed (that is, to be passed through), all produced in InDesign having Adobe RGB as the RGB color space and ISO Coated V2 as the CMYK color space. They were exported as PDF (Press Quality) = PDF 1.3 (no PDF/X standard), PDF X-1a:2001 (PDF 1.3), PDF X-3 (1.3), and PDF X-4 (1.6).

Hi @lacerto, just to clarify a couple of things, does PDF (Press Quality) in Indesign not export PDF 1.4 files or has the standard changed with new releases of InDesign (I don't have access to InDesign so I can't check). I'm also assuming that you referring to PDF X-3:2002 rather than PDF X-3:2003 since I was of the impression the former exports PDF 1.3, the latter PDF 1.4 files? Just wanted to clarify supported features for each standard since there are subtle differences between PDF 1.3 and PDF 1.4 in terms of what is supported, not that this has any real impact with regards to the way the Affinity Apps are handling or rather appear to be incorrectly handling PDF Passthrough.

On 7/20/2022 at 9:58 PM, lacerto said:

The correct behavior is shown in the attached InDesign exported PDF/X-4 document. However, when this job is exported from Affinity Publisher, it can be seen that a PDF that is not PDF/X-based (but plain and simple PDF 1.3 based device-CMYK document), has been rasterized (texts included), its overprint status of Y100 lost, and PANTONE color lost.

The Affinity suite appears to experience conflicts between different PDF versions, including different PDF/X versions which seem to emenate from the implementation of PDF Passthrough. My assumption (rightly or wrongly) is that these conflicts shouldn't exist and while the PDF formats themselves appear to export correctly individually, i.e., when not combined within the same document, the indications are that PDF 1.3 and 1.4 (no PDF/X standard files) are not compatible with PDF/X-4 files when using PDF Passthrough and likewise there appear to be compatibility issues between PDF/X-4 and PDF/X-3:2003 in Affinity apps, Publisher highlights these conflicts.

On 7/20/2022 at 9:58 PM, lacerto said:

This happens with all PDF/X-based production exports in Affinity apps, so it is clear that PDF/X-based export methods cannot be recommended without serious reservations. E.g. in professional use it is common to have third party ads and other documents (logos etc.) placed, and they often come produced in varied ways. Requiring that these kinds of documents need to be produced using a specific standard is absurd.

Is this PDF/X specific or an issue with Affinity App Passthrough? For example I can create a document (RGB or CMYK, it makes no difference) using both Spot and non Spot colour, both with Overprint set which when exported as individual PDF files from Affinity Designer or Publisher result in the correct output but when combined in a single document by placing the respective PDF files using PDF passthrough and then exporting to PDF using PDF 1.4 (No PDF/X standard), PDF/X-1a:2003, PDF/X-3:2003 and PDF/X-4) give differing results depending on which combination of PDF versions appear on the same PDF export...

Individual PDF Exports

Note how each PDF Export version exports the file correctly and shows the simulated Overprint in Acrobat Reader.

On 7/20/2022 at 9:58 PM, lacerto said:

Things like these explain why recommendations on creating device-CMYK production files keep on be given on this forum. Giving a generic recipe like "just use most advanced technology PDF/X-4", without consulting the printshop (or even against their recommendations), and without realizing or understanding the inherent problems with Affinity apps, is silly.

This I 100% agree with, any print job has to be produced in conjuction with the company printing the job and to their specific requirments or you're asking for trouble.
 

Individual Documents Above Combined in a Single Document Using PDF Passthrough

Note here the conflict between the Left and Right images and how the PDF 1.4 file conflicts with the PDF/X-4 file in both cases and how the CMYK (non-spot) versions in the bottom row of each file conflct between versions and how the PDF/X-1a:2003 export fails to show any CMYK or Spot Colour simulated Overprint regardless of the PDF version.

Then compare the image above with the same files exported while only showing one of the four placed PDF files and exported using the same four different PDF settings, the only difference here is the PDF 1.4 Export (No PDF/X) now shows the non-spot simulated colour Overprint but again the PDF/X-1a:2003 fails to exhibit the simulated Overprint when PDF Passthrough is applied despite the Overprint being shown for both Spot and Non-Spot colours when the file is exported without PDF Passthough as shown in the first image...

On 7/20/2022 at 9:58 PM, lacerto said:

it is clear that PDF/X-based export methods cannot be recommended without serious reservations. E.g. in professional use it is common to have third party ads and other documents (logos etc.) placed, and they often come produced in varied ways. Requiring that these kinds of documents need to be produced using a specific standard is absurd.

Agreed...

On 7/20/2022 at 9:58 PM, lacerto said:

Affinity apps have a unique PDF compatibility rule according to which the placed PDFs need to be produced in version lower or the same than the host document will be exported (and not just PDF version number but also PDF-X version number; this means e.g. that if the host PDF needs to be exported using PDF/X-3 on printshop's requirement, not only non-PDF-X based but also all placed PDF/X-4 documents will be corrupt).

I've not experienced this, can you elaborate on the specific corruption you've experienced and what you mean by "the placed PDFs need to be produced in version lower or the same than the host document"?

Attached are the PDF files used in the images above. I don't currently have access to Acrobat Pro so I'd be interested to see whether the simulations shown in Acrobat Reader actually reflect the images shown above when the separations are viewed in Acrobat Pro?

Reading numerous posts dating back several years I get the impression that the Affinity App handling of PDF Passthrough is somewhat lacking, acknowleged by the Serif Team but yet to be fixed, I don't know if that is a fair assessment?

Source PDF Files

Circles CMYK X-4.pdfCircles CMYK X-3.pdfCircles CMYK X-1a.pdfCircles CMYK 1.4.pdf

 

Combined PDF Files

Circles PDF:X-4 Export.pdfCircles PDF:X-3 2003 Export.pdfCircles PDF:X-1a 2003 Export.pdfCircles PDF 1.4 Export.pdf

 

Individually Exported PDF Files from a Combined Placed PDF Document

Circles PDF:X-4 Only PT Export.pdfCircles PDF:X-3 2003 Only PT Export.pdfCircles PDF:X-1a 2003 Only PT Export.pdfCircles PDF 1.4 Only PT Export.pdf

 

[lacerto]

@Hangman, I'll have a closer look on your post later, but here are some quick comments:

On 7/22/2022 at 10:12 PM, Hangman said:

PDF (Press Quality) in Indesign not export PDF 1.4 files or has the standard changed with new releases of InDesign

All the InDesign created PDFs that I had included were created in InDesign CS6. I use later versions only periodically and do not have currently subscription for ID on so I cannot check what kinds of changes there are in the latest version. But my point was in creating default PDF/X-based documents according to standards that CS6 version used (so I did not change the version numbers offered). InDesign supports PDF 1.3 (which Affinity apps do not), and PDF/X-standards with lower version numbers than Affinity apps (or pdfLib), e.g. PDF/X-1a:2001 and PDF/X3:2002, but I do not think that this is crucial. [EDIT: Sorry, my reply was more in general lines but, yes, you are correct, the default Press Quality in ID CS6 was for PDF 1.4, I wanted to use 1.3, instead to produce as basic plain CMYK as possible.]

It seems that Affinity apps fail a) with any non-PDF/X-based placed PDF that are exported using any PDF/X-based methods, and b) any placed PDFs that use version number later than the export file will be using.

This means that InDesign-created PDF v 1.3 device-CMYK PDFs (which should be the most fool-proof, basic print PDFs there can be, and should pass any old RIP software that exists in the world) fail with any PDF/X-based export methods (which are all post PDF 1.3, and therefore should not fail, according to Affinity "compatibility rules"). So the version number is not the issue here. Any Affinity created non-PDF/X-based PDFs, whether created in version 1.4 (lowest that Affinity apps support), or version 1.7 (latest that they support), will fail with PDF/X based Affinity created exports, as well.

These kinds of issues do not exist with Adobe apps or QuarkXPress. The mentioned "compatibility rules" only apply when using Affinity apps, and they make professional production quite complex if not impossible. As mentioned, InDesign and QuarkXPress can place any PDFs of any version in the document, and export them using any PDF export method, including ones that use lower version. In Affinity apps placed PDFs (to be passed through), are not converted nor are their features retained (e.g. embedded fonts are lost and rasterized). If they "conflict", the whole file is simply rasterized, which also means that colors will change. EDIT: The non-rasterizing alternative is to allow Affinity app to interpret the conflicting PDFs, which then introduces several other problems (the most serious being that embedded CMYK color profiles are not discarded, as they by default are e.g. when using InDesign, which results in translation of color values if the color profiles conflict -- again something that is typically not wanted when placing CMYK content: it is wanted to be passed through as it is).

I am not at all "against" using later PDF versions, or advocating device CMYK -- I responded only because there are known problems with Affinity apps in handling placed PDFs. PDF/X-based methods have initially been created to make production for press easier, but in context of Affinity apps they require knowledge of several pitfalls, something that most users do not have, and can seriously backfire.

In addition, I do not think that there is basically anything "old-fashioned" in keeping production methods simple, and in a way, in one's "own hands". In this respect, producing device-CMYK is fool-proof as it does not leave anything to be resolved on RIP. When working with InDesign, flattening of transparencies e.g. does not result in rasterization (as it always does when using Affinity apps), so there is no quality loss. It just saves time because you do not need to check these things from the ripped PDFs. It is also more or less fool-proof to produce along sRGB based workflow, as many big publishers marketing their services for general public do.

In this respect, producing using PDF/X-3 or PDF/X-4 (with embedded profiles and mixed color spaces) makes things more complex, especially in situations where apps (like Affinity apps) unnecessarily convert color spaces on export, and do not allow the user e.g. to specify whether transparencies should be resolved in RGB or CMYK color space. Things like these, in context of Affinity apps that allow creating complex non-destructive designs with stacked adjustments -- something that are supposed to be a forte -- are very error prone and likely to cause problems at least if they are left to be resolved at print time (on RIP).

As for the OP's problem, it might well be something that can be resolved by changing the export method. On the other hand, I have seen many posts where these kinds of issues could be resolved only by rasterizing on canvas or flattening at export time, i.e., making sure that all interacting layers use the same color space and leave nothing to be resolved at print time.

Here is a clip that demonstrates the compatibility "conflict". You should be able to reproduce this with any Affinity app. I think that compatibility rules are explained to some extent in the documentation, and also flagged in the internal preflight check (unless you have disabled the feature).

 

[PixelEngineer]

This is in regards to the original problem of the mysterious white square:

Clear communication between the user and the printshop is absolutely essential for any file format that you are sending to a printshop. That goes without saying. I don't think anyone ever suggested that you should not communicate with the printer. Communication is the backbone to successful completion of your project. Every DTP professional knows this and yes it must be conveyed to those that are starting out in this business. On the surface this particular user seems to be in communication with his printshop. Of course, you need to ask the printer ahead of time if they handle the PDF output you intend to use. This way you can plan accordingly. There are printshops that work with different formats. Doesn't hurt to ask. But do ask the printer the proper method for outputDesigning for professional printing - Affinity Spotlighting in the format that you will be working on. Each PDF type has its own particular workflow.

Unless you have the exact file and can analyze the workflow step by step looking over a designer's shoulder while analyzing the actual procedures that the printshop operator used interpreting preflight while prepping the file for the RIP on that particular computer, only then it may be possible to know what actually happened to the person's file. We can only guess. There are numerous phases where the failure could've occurred including file packet transmission. Also the file could've been good to go and simply broke in InDesign for numerous reasons including the program settings or user error (there are too many for me to list).  Maybee the document didn't break at all. 

Of course, every PDF format has its own purpose and each one has its pros and cons. There are so many options available in these types of programs but you need to know when to use them. 

In regards to flattening, there are a number many ways that a user can flatten the file that was uploaded in the beginning of this thread. The printer may take one and reject the other. And there are different approaches to doing it in which you will protect the integrity of the embedded font.

Adobe InDesign users around the world have had these types of problems too for many years using PDFX/1a files. Everyone knows this. This is nothing new. Since Adobe InDesign users around the world are experiencing the same problem with their PDFX/1a files getting "corrupted" during the production process, does that mean that printshops should no longer be accepting PDFX/1a pdf files from Adobe InDesign? There are industry professionals that  mention often that many of these problems occur due to certain scenarios in the way color space, layer are handled in the workflows that can generate these undesired results apparently there are workarounds. This white square situation though I believe may be a similar but slightly different issue. If you want to you can see an example in one of the links. We didn't see the file in this thread but you may get an idea what occurred based on the users description.

A good pdf can get ruined from the operator opening the file in another program instead of a true PDF editor like Adobe Acrobat Pro for instance. In this case the printshop opened the PDF file in InDesign instead of a program designed for PDF like Adobe Acrobat. There maybe a reason for this approach, perhaps they are using a special plugin for this purpose. For this particular situation, there are some users that have indicated if they opened up the file in Adobe Acrobat pressing overprint, it would show the true output as a proof that may be signed off. (To be clear, I can't confirm this and I'm not recommending that but just commenting on what was posted in the link provided below you would have to test it yourself at the actual RIP). Perhaps the print operator wasn't aware of this possible solution. (again we were not there just painting the scenario base on information we are working with). 

For an example regarding the original problem that may have occurred according to the original person asking for help on this thread click the link below. One user mentioned that the risk was not worth it while others found it worked in their case. Although its a thread it may be worth a quick look.

• https://www.graphicdesignforums.co.uk/threads/indesign-problem-with-shadows-on-exporting-for-pdf-x-1a-2001.13669/
• https://forums.macrumors.com/threads/drop-shadows-in-pdf.331676/

There are success stories here in the forum of different Affinity Publisher users uploading PDF/X-1a:2003, or PDF/X-4 PDF passing the printer's preflight process and successfully publish their books.

Did you see the spotlight demo on designing the Affinity Publisher Workbook? At the end he finally exports that large book to PDF/X-4 format CMYK print job.
The entire book was professionally made using Affinity Publisher!

The article in the following link makes some suggestions regarding CMYK workflow for professional printing.
Designing for professional printing - Affinity Spotlight

The problem here is not Affinity's ability to export a PDF/X1a PDF. Affinity Publisher created the output just fine.
It seems to me more of a workflow tweak and a little bit of knowledge and communication and better methods that the printer could've used based on the limited information we were given. 

 

PDF/X-4 was made as a suggestion because of how it handles transparencies because of the issues that occurred. User's should learn about this format and that it exist as a possible option if they want to incorporate it into their workflow if their printer provides that option. 

You can get great results with PDF/X1a just make sure you are working closely with your printshop and get every detail you need. Now that we found out there are some users out there that found a "possible" workaround we can communicate this with the printshop to see if this can be a solution for a successful print job. That of course is up to them. Knowledge and communication is key here.  

[PixelEngineer]

13 hours ago, lacerto said:

Here is a clip that demonstrates

Hi Lacerto, 

Something is not quite right with your video demo. In the beginning of your video you start out in CMYK and then looks like you wanted to switch to RGB mode to make a point only to press cancel??? Why? That's very confusing.

Also, what does this have to do with the original topic regarding the white box transparency issue that so many Adobe InDesign users around the world have had this exact problem with for many years that continues today when exporting their drop shadowed font from InDesign using PDF/X1a workflow out to the printer?

https://www.graphicdesignforums.co.uk/threads/indesign-problem-with-shadows-on-exporting-for-pdf-x-1a-2001.13669/

https://forums.macrumors.com/threads/drop-shadows-in-pdf.331676/

BTW, All that may have been needed was a quick workaround if the printer approved that move. Printshop may have not used best practices in checking PDFs. Careful flattening technique could've also been used  while keeping the integrity of the embedded font intact while continuing to work with PDFX/1a. This supports that Affinity Publisher is working fine regarding this project. There were other factors at play here that had nothing to do with Serif's Affinity Publisher performance.

 

[lacerto]

2 hours ago, PixelEngineer said:

Something is not quite right with your video demo. In the beginning of your video you start out in CMYK and then looks like you wanted to switch to RGB mode to make a point only to press cancel??? Why? That's very confusing.

I just wanted to show both the document CMYK target and the implied RGB color profile: it is Adobe RGB as shown also on the layout. I press Cancel because I do not want to change the color mode. Publisher documents always have color profile assignments for both RGB and CMYK color modes.

2 hours ago, PixelEngineer said:

Also, what does this have to do with the original topic regarding the white box transparency issue

Possibly nothing. I responded primarily to arguments made on supposedly "obsolete" device-CMYK based exports and assumption that these kinds of problems can be fixed simply by exporting to PDF/X-4. This may or may not be true in OP's case but I wanted to point out that PDF/X-based export methods have issues of their own, and that recommending exporting with methods that allow mixed color spaces might not resolve problems related to transparency issues, which in the first place are often results of having mixed color spaces and unresolved transparencies. It does not help that Affinity apps themselves convert RGB defined shapes and text (if any) to CMYK when using these export methods (and then leave transparencies involving RGB based calculations unresolved). I have seen numerous posts with similar issues, and PDF/X-4 just has not been in these cases a magic wand that makes these kinds of problems go away.