Export of placed PDFs not correctly cropped

[rcheetah]

I have a huge problem. I can't export PDFs for files that include PDFs. They will not get cropped correctly when exported, but are completely messed up and missing their cropmarks. 

When doing the same in Designer, they're already wrongly cropped in the software itself, even when I use .afdesign files. 

Everything ist in Affinity 2.0, also the files. 

I'll attach a screen video, so you can see for yourself. 

[rcheetah]

Here is the .afpub file. I embedded the files with this one. In the video they we're linked, but I tried exporting with the embedded version, and it still was the same error. 

Müllbeklebung Montage.afpub

[Lee_T]

Hi rcheetah,

it appears that the PDF is not embedded.

Lee

[Hangman]

Hi @rcheetah,

I believe this is a known bug...

If you change your Page Box setting from Maximum Content to Media Box your file should export correctly with its crop marks though, from me, doing so freezes Publisher completely resulting in me having to do a Force Quit.

There are some major issues with placed PDF files in Publisher v2.1.0 and v2.1.1 and the moment.

[lacerto]

I seem to be able to crop something similar correctly from Publisher 2.1.1 on both Windows and macOS (Win 11 and latest macOS Ventura), but noticed that when initiallly trying to embed the placed PDFs, this failed (similarly as it seems to have failed with OP).

 

Müllbeklebung Montage_test_embedded_cropped.pdf

[Hangman]

This is what I get, first using Maximum or Minimum Content, then using Media Box for the Page Box Setting... Basically, using either Maximum or Minimum Content crops both the top right along with the crop marks when exporting to PDF...

[Hangman]

13 minutes ago, lacerto said:

but noticed that when initiallly trying to embed the placed PDFs, this failed (similarly as it seems to have failed with OP).

Resource Manager suggests the OP had his or her PDF files Linked rather than Embedded...

 

[lacerto]

17 minutes ago, Hangman said:

Resource Manager suggests the OP had his or her PDF files Linked rather than Embedded...

Yes, the behavior was identical in my test. I embedded in Windows, closed the document, reopened it and made sure that files showed Embedded in Resource Manager, closed and transferred on macOS, where nothing showed on the canvas, and the Resource Manager showed the status as linked.

Similarly as OP I had placed the PDFs (produced as both PDF 1.7 default and PDF/X-1a from Designer 2.1.1 Windows version) as interpreted and then exported as PDF 1.7 (default) the selected placed PDFs. I used Maximum Content as the crop option, but did not have the placed images scaled or rotated. 

So this kind of file:

Müllbeklebung Montage_embedded_macos.afpub

[Hangman]

1 minute ago, lacerto said:

Yes, the behavior was identical in my test. I embedded in Windows, closed and made sure that file showed Embedded in Resource Manager, closed and transferred on macOS, where nothign showed on the canvas, and the Rsource Manager showed the status as linked.

How bizarre and somewhat worrying if embedded PDF files are suddenly no longer embedded when switching platforms. Do you see the same if using Save as Package and then transferring between platforms and is it multi-directional, i.e., does the same happen from PC to Mac and Mac to PC?

 

6 minutes ago, lacerto said:

Similarly as OP I had placed the PDFs (produced as both PDF 1.7 default and PDF/X-1a) as interpreted and then exported as PDF 1.7 (default) the selected placed PDFs.

The OP exports using PDF Passthrough rather than Interpret which turns out to be the issue...

• When the placed PDFs are either Linked or Embedded and PDF Passthrough is set to Passthrough the exported PDF is cropped and missing the crop marks.
• When the placed PDFs are either Linked or Embedded and PDF Passthrough is set to Interpret the PDF exports correctly.

 

[lacerto]

2 hours ago, Hangman said:

The OP exports using PDF Passthrough rather than Interpret which turns out to be the issue...

Oh yes, I seem to have missed the part they switched back to "Transfer" after first having switched from "Transfer" to "Interpreteren".

Then nothing surprises me. You basically cannot place PDFs for interpretation passthrough and export to PDF without experiencing some sort of issue. There are certain specific workflows that  can be used without problems, but having e.g. crop marks in placed files seems to work only if the placed files are rasterized (either because of "compatibility rule" violation, or beforehand on the canvas, or intentionally at export time. This has never worked properly in Affinity apps.

[Hangman]

5 minutes ago, lacerto said:

Oh yes, I seem to have missed the part they switched back to "Transfer" after first having switched from "Transfer" to "Interpreteren".

5 minutes ago, lacerto said:

Then nothing surprises me. You basically cannot place PDFs for interpretation and export to PDF without experiencing some sort of issue.

I guess that depends on the source of the PDF, if it's one you've created yourself and have all the associated 'elements and fonts' for then it doesn't appear to be an issue.

7 minutes ago, lacerto said:

There are certain specific workflows that  can be used without problems, but having e.g. crop marks in placed files seems to work only if the placed files are rasterized (either because of "compatibility rule" violation, or beforehand on the canvas, or intentionally at export time. This has never worked properly in Affinity apps.

Obviously, that depends on the version of PDF you're exporting to... exporting to PDF 1.7 certainly allows crop marks in placed files to be exported without rasterisation.

What is odd, however, are the PDFs exported using Passthrough which end up cropped and minus visible crop marks... take a look at the attached PDFs, in particular, the layers for the two using Passthrough, the crop marks are there and the file only appears cropped because of the addition of two additional mask layers (which don't appear in the Interpreted exports).

Uncheck the two additional mask layers and the file appears correctly...

Müllbeklebung Montage (Max Embedded Interpet).pdf

Müllbeklebung Montage (Max Embedded Passthrough).pdf

Müllbeklebung Montage (Max Linked Interpet).pdf

Müllbeklebung Montage (Max Linked Passthrough).pdf

 

[lacerto]

3 hours ago, Hangman said:

does the same happen from PC to Mac and Mac to PC?

Yes, here it happens when saved on macOS and transferred onto Windows:

 

As can be seen, I deliberately eliminated the chance that this could have been caused by the OP's missing files. As the OP had placed the files to be passed through, the placement method does not seem to play any role here [I mean in losing the embedded files], either. 

[Hangman]

reminiscent

23 minutes ago, lacerto said:

Yes, here it happens when saved on macOS and transferred onto Windows:

Did you also spot that when you opened the file in Publisher on Windows and selected one of the placed PDF files (1m 26s), the Original size is shown as 0 px x 0 px and the Placed size as 0 mm x 0 mm which is interestingly reminiscent of an old Publisher bug that caused an error where the Publisher file couldn't be opened because it contained features from a newer version of Publisher, though that is clearly not the issue here...

Normally, even if the resource is missing, Publisher still shows both the Original and Placed sizes in Resource Manager...

23 minutes ago, lacerto said:

As can be seen, I deliberately eliminated the chance that this could have been caused by the OP's missing files. As the OP had placed the files to be passed through, the placement method does not seem to play any role here, either. 

Passthrough vs Interpret however does make all the difference as shown in the previously posted PDF files...

[lacerto]

11 hours ago, Hangman said:

I guess that depends on the source of the PDF, if it's one you've created yourself and have all the associated 'elements and fonts' for then it doesn't appear to be an issue.

Sorry, a typo, I meant of course "for passthrough" and not "interpretation". If PDFs are safe to be interpreted (e.g. own still editable production), there typically are no problems, as long as there are no profile conflicts (which can easily rise inadvertently because the placed PDFs without an embedded profile will have the working color profile assigned to them rather than the hosting document color profile).

But as for passthrough, whether your placed PDF workflow has any chances to behave expectedly much depends on whether you can choose your production method freely, and what kinds of features you will have in the placed files.

Assuming that the printer requires all in CMYK and no live transparencies, and more specifically PDF/X-1a, as might still be common, and you need to place PDFs and use passthrough, you will have problems, no matter which kinds of PDFs you are going to use.

Below are examples where a PDFv1.4 file has been placed for passthrough and exported to PDF/X-1a:2003, and another example where a PDF/X-1a file has been placed for passthrough and exported to PDF/X-1a:2003. Both scenarios should "in principle" work considering the Affinity "compatibility rules", since the PDF version numbers are the same in source and destination -- so one might assume that just taking care that transparencies (blend modes and opacities) get flattened the file would be easy to produce to meet expectations.

pdf14.pdf

pdf14._to_pdfx1a.pdf

pdfx1a.pdf

pdfx1a._to_pdfx1a.pdf

Nothing at all gets passed through: everything is rasterized, including text (not involved in transparencies at all), and all native color values are recalculated and incorrect, and spot colors and overprint attributes lost. All color values (already defined in CMYK) get changed even if the profiles are the same in the placed file, the document and the exported file (though this should not matter when native color values are assumed just to be passed through).

So no news here, I just wanted to test if 2.1.1 has any developments in PDF production, but it does not seem so.

The most flexible export method, using PDF (press-ready) and PDF v1.7, would allow using all kinds of PDFs placed for passthrough, but if transparencies need to be flattened, there is no other option than using PDF/X-1a or PDF/X-3 (and optionally force conversion of placed RGB images), since PDFv1.3 is not supported. And non-PDF/X-based PDFs placed for passthrough will then always be rasterized (even PDFv1.3 files). 

But as can be seen, even if PDF v1.7 could be used freely, more "complex" production features, like files using crop marks, can cause problems, and accordingly require allowing interpretation.

[lacerto]

8 hours ago, Hangman said:

Normally, even if the resource is missing, Publisher still shows both the Original and Placed sizes in Resource Manager...

Well, it is obvious that nothing is really embedded in current 2.1.1 versions (at least in Publisher). The status just says "Embedded" as long as the path (which is saved even if the files were actually embedded, which can be seen when making embedded files linked again, since by default the earlier link path will be used). I am not sure how old this bug is, but it can be easily verified just by looking at the file size of the Publisher file supposedly containing embedded files, and if that is not enough, by manually breaking the access to the path where the (actually still) linked files are located. That link naturally breaks when transferring the Publisher file to a different computer or on the Internet (like it did for OP when they uploaded the file on the forum post).

[R C-R]

28 minutes ago, lacerto said:

Well, it is obvious that nothing is really embedded in current 2.1.1 versions (at least in Publisher).

At least for me in the 2.1.1 Mac version, it seems to depend on the type of item(s) that are embedded vs. linked. So for example a file with several >10MB PNG files saves at about 32.5 MB if embedded but just a bit over 500KB if linked. I also tried a mix of PNGs, afphoto, & NEF files, all at least 4 MB each, & that also showed significant differences when all were linked vs. embedded (around 2 vs. 20 MB).

Annoyingly, in one file containing a different mix of file types there was no difference in file size when linked vs. embedded, but I could not repeat that & I do not remember exactly what file types I used.

[lacerto]

9 hours ago, Hangman said:

Obviously, that depends on the version of PDF you're exporting to... exporting to PDF 1.7 certainly allows crop marks in placed files to be exported without rasterisation.

Yes, but then the cropping options can mess up the export, at least Maximum and Minimum Content both have been somehow broken for ages. I am not even sure about their purposes but neither e.g. crops the export exactly to the bounding box of the selected objects (the option that is available when cropping an imported/placed PDF within e.g. Photoshop or InDesign). If the design does not have live transparencies, or live transparency is not a problem, PDF 1.7 is a solid choice and crop marks (if any) of objects that have been cropped by using e.g. Media Box or Artbox options, will be included and nothing is rasterized. But if there is a "compatibility rules" based conflict and resulting rasterization, print marks are guaranteed to be included only in the rasterized objects, while  they may be omitted for objects that do not get rasterized, whenever using Maximum or Minimum Content crop options.

[lacerto]

1 hour ago, R C-R said:

it seems to depend on the type of item(s) that are embedded vs. linked

It seems so. PDF files will not be embedded even if their file size is large.

EDIT: But oddly, the file size of the Publisher file does get increased, so it is possible that the PDF files are actually embedded but there is a glitch in the code when it is time to render these files (the embedded resources are not found or something goes wrong in processing, resulting in these files being marked as linked).

[Hangman]

2 hours ago, lacerto said:

It seems so. PDF files will not be embedded even if their file size is large.

EDIT: But oddly, the file size of the Publisher file does get increased, so it is possible that the PDF files are actually embedded but there is a glitch in the code when it is time to render these files (the embedded resources are not found or something goes wrong in processing, resulting in these files being marked as linked).

Thinking about this it makes little sense. I've downloaded loads of user files in the forum created in Windows, containing embedded PDF files and opened them on macOS without any issues with the placed PDFs shown as embedded in Resource Manager so I'm really unsure what is going on here...

Could you perhaps create a simple Publisher file on Windows (if you have time), place a couple of embedded PDF files in the document, Save it then Zip it up and post it. I'll then take a look to see if the PDFs are still embedded when opened on macOS or whether they show as Linked just in case this is a new v2.1.1 bug...

[lacerto]

1 hour ago, Hangman said:

Could you perhaps create a simple Publisher file on Windows (if you have time), place a couple of embedded PDF files in the document, Save it then Zip it up and post it. I'll then take a look to see if the PDFs are still embedded when opened on macOS or whether they show as Linked just in case this is a new v2.1.1 bug...

The behavior is identical on macOS and Windows and you can easily test it by embedding a large PDF file (e.g. one that contains embedded raster images, I tested this with a 10 MB PDF containing lots of low-res images). Then after having embedded the PDF in Resource Manager, save the Publisher document and rename the file that you embedded in the file system, then open the Publisher document. The supposedly embedded PDF file is no longer rendered on canvas and if Resource Manager is opened it is shown as "Linked", not embedded. Any raster images embedded are rendered normally and their status is "Embedded". Notice how Publisher file size nevertheless increases and decreases depending on whether it is embedded or linked (or removed), which indicates that the file would appear to be embedded, but just cannot be rendered.

[lacerto]

Here the issue is experienced on macOS. 

 

Linking/embedding behavior is very odd within Affinity apps. As can be seen, even if this single file (PDF size of which is on disk about 10MB) is linked, the Publisher document wastes 25MB disk space when the file is saved. On Windows it takes about 11MB, which is a lot, too, for storing information for a single linked file, but why is the macOS version still over double more bloated? As it is, it actually seems that even a linked file is already some way embedded. What is even stranger is that on the video clip embedding does not actually increase the file size at all, while on other occasions (experienced when first testing the behavior before making the final recording) embedding clearly increases the file size. Yet on certain occasions embedding truly happens and the Publisher document file size might nearly double so having a 10MB file embedded might waste about 35MB disk space (on macOS).

There are lots of posts reporting odd and sudden document file size increase, and as the behavior shown on the video does not happen consistently, it is possible that the clip just demonstrates an old bug that does not happen all the time. It might of course be partially a macOS specific issue, too (I am running Ventura 13.4.1 in native mode), but I doubt it because the same behavior can be witnessed on Windows 11, just not taking as much disk space.

[Hangman]

13 minutes ago, lacerto said:

The behavior is identical on macOS and Windows and you can easily test it by embedding a large PDF file (e.g. one that contains embedded raster images, I tested this with a 10 MB PDF containing lots of low-res images). Then after having embedded the PDF in Resource Manager, save the Publisher document and rename the file that you embedded in the file system, then open the Publisher document. The supposedly embedded PDF file is no longer rendered on canvas and if Resource Manager is opened it is shown as "Linked", not embedded. Any raster images embedded are rendered normally and their status is "Embedded". Notice how Publisher file size nevertheless increases and decreases depending on whether it is embedded or linked (or removed), which indicates that the file would appear to be embedded, but just cannot be rendered.

I'm seeing the exact same issue, this definitely looks like a new bug...

[lacerto]

2 hours ago, Hangman said:

I'm seeing the exact same issue, this definitely looks like a new bug...

I suppose so. This was the first time for me, too, to experience "vanishing" embedded files. I was just perplexed to see the feature suddenly working (and of course at the time I tried to record the behavior). Perhaps the absurd file size (when having mere links) is a related bug, though I have read a few threads trying to explain why linked files can increase the container size (I have an impression that this is more or less a permanent question on the forum).

[Hangman]

I've reported it as a bug now in the Bugs thread along with a couple of other oddities, e.g., based on your earlier screen recording I noticed that renaming the placed pdf and replacing it causes the replaced pdf to appear with a negative 2^31 dpi in Resource Manager...

[rcheetah]

 

Sorry for being absent so long. I had my settings misconfigured, so I didn't receive any notifications.

Well, this thread escalated quickly. There seems to be more bugs related. I don't know of how much help I am at this point. Do you need anything from me? To be honest, a lot of things discussed went a little over my head. I just realised, that Affinity has a lot of troubles with embedded colors, and maybe even from other affinity suite files.

I come from Adobe, and I still use it daily as a professional. I use Affinity only for private projects, and this is not so  often the case. Every time I try to do something, I become very frustrated, because things just won't work. Some of this are missing features (e.g. still no raster vectorisation for designer …), some of them are like this just bugs. I understand I have a hard time because it's a different software, and I have to get used to it. But often it's so utterly frustrating. I was completely in rage when writing the original post, that's why it was so straightforward. I used all my focus to not be impolite. 

In my workflow, I mostly create the designs in one file, and when I print them myself, I montage them in a different file by placing it in there. In this case I printed on labels, so I wanted to save space, and put everything on one page. Of course I wouldn't waste three A4 pages of label paper by printing each design separately. So exporting print-ready designs with crop marks and placing them into a new A4 file is my workflow for this, coming from Indesign. This way I don't have to create the cropmarks myself, and have the bleed for cutting it myself. Would you suggest a different workflow? If not, which export and import options should I use for this workflow?

Aside from my workflow – as you figured yourself – Affinity clearly has a lot of bugs with this sort of stuff. So this would really need fixing. Color management and placement of files seems to be a pretty core thing, and this is Affinity 2.0.