lacerto

Did you mean text frame clipped into a text frame, like below (the clipping, inner text frame with green background within margins, but the selected outer text frame with white text fille extending beyond)? If so, it is worth checking that the clipped text frame does not have boundaries extending the safe zone (even if there were no characters rendered beyond it).

Aren't these kinds of odd renderings often symptoms of duplicate font installations (however possible for system fonts) or a corrupted system/app font cache? For clearing duplicate installation and system-wide issues (if this were not an issue affecting just Affinity apps) there are plenty of instructions on the Internet, but what would be up-to-date instructions for clearing Affinity-specific font cache (both on Windows and macOS)? [EDIT: The font used for rendering artboard titles is pretty small but does look like it could be Arial, while the rest/most of the UI text is not, so the problem might be related to just Arial.]

There is no way since Affinity apps cannot map color values (in any color space) to library colors, whether special (spot) inks, or defined in some process color mode, like in case of PANTONE+ CMYK Coated or Uncoated, in CMYK. But I fail to see the point of trying to match any color value (RGB or CMYK) within a CMYK-based PANTONE color library since that would mean different colors for anyone trying to use that library color, depending on which CMYK and RGB color profiles they are using in the document where the color is to be applied. I am not sure if even PANTONE describes the conditions where their CMYK color swatches have been produced. These are pretty much obsolete libraries from the time ISO-based color management with calibrated wide-gamut displays were not available (so that it was not possible to render realistically even the CMYK color gamut on regular displays). E.g., the CMYK color definition of P-65-8 C is M100 Y41 (= PANTONE defined value) which produces slightly different colors depending on the kind of paper these values are printed on (and depending also on print conditions), and different RGB values (whether expressed in 8-bit, percentage or hexadecimal notation), depending on the underlying document CMYK and RGB color profile pair. #e80e65 = R232 G14 B101 in 8-bit is pretty close to the conversion that you would get if your CMYK profile is U.S. Web Coated and RGB profile sRGB (the default Affinity profiles): #ED1063 = R237 G16 B99 in 8-bit. The defaults in Adobe environment vary depending on the version of CS / CC and the conversion values are also likely to be slightly different because of using a different color management engine.

I have only superficial knowledge of these new standards. The new more advanced features basically make production simpler and more versatile but it does not seem that ability to convert from one standard to another becomes any easier or less important. So I would imagine that capability of Adobe apps and QuarkXPress to accept any mixed collection of placed PDFs disregarding the version number and transfer all relevant information (color values, overprinting, transparency) no matter in which PDF version it is exported to (including these new versions) -- even when it needs to be flattened, converted or (prematurely) rasterized, continues to be a valuable asset. In a way the new features make version control and management yet more complex. New standards probably also require new RIPs and it remains to be seen how fast upgrading will happen, and at what level the new standards only mean automated prepress routines that basically only split and downgrade jobs to meet former more basic standards. I do not know but I have a feeling that failed files are converted to sRGB (factory default RGB) and then to U.S. Web Coated v2 (factory default CMYK). I cannot say whether they are Affinity-specific, but e.g. Adobe apps and CorelDRAW do not seem to use masks in similar exports.

Sorry, bad formulation. I just meant that PDF 1.7 ("press ready" based) is the most robust export method whenever having PDFs that need to be placed for passthrough but which naturally cannot be used if the job contains transparencies and live transparencies are not allowed in print PDFs. In that kind of situation one possible solution would be flattening transparencies manually on the canvas (either by rasterizing or dividing the overlapping shapes and applying calculated solid color values). The more frequent situation is to have both color modes ICC based, which might produce right colors even if might fool the PDF viewer to show incorrect color values. But what I mention does happen at times (this is from private exchange of posts I have shared with @Ldina😞 In these kinds of situations the true color values cannot be displayed in e.g. Adobe Acrobat Pro because the native values are buried under dual ICC based CMYK and RGB layers intermediary ICC RGB layer, so there is no clear target profile to choose. It is impossible to know which color values will be transferred on plates. I am not sure if I understood, but it may be that rasterization always happens in (s)RGB color space and is then translated to export CMYK so there are multiple translations. What do you mean? I assume that In a situation compatibility is violated? If so, I guess it is because there is no swatch like [Black] in Affinity apps, like there is in InDesign, which basically means "keep this as K100 whenever outputting to CMYK, and RGB0,0,0 when outputting to RGB)" so when conversions do happen, black is retained (or converted to K100 or RGB0,0,0). Thanks. Yes, they are shown in Adobe Acrobat Pro as masks:

Sorry, I am not sure which kind if situation you meant. I suppose 1-bit bitmaps are related to masking but if you can post a singe PDF that demonstrates it I can check how it shows in Adobe Acrobat Pro.

The thread kind of escalated sideways (to issues related to embedding and more generally problems related to placed PDFs), but I think that in your file the fix is to change the crop option or the placed PDFs from Maximum Content to MediaBox or ArtBox.

They should not, since interpretation is basically the same as opening the file, so that should work as long as the contained elements can be interpreted by Affinity apps (not all features can, so e.g. there may be errors related to rendering of fonts which might get rasterized to keep the appearance, rather than converted to curves or replaced with another font, or interpreting certain gradients (smooth shaders), and all sorts of minor errors that can happen when interpreting PDF content. Colorwise the major issues are loss of overprinting attribute and inadvertent change of color values because of conflicting color profiles. As for passthrough, I assume that your version numbers refer to PDF export version number (and not the version number of a placed file). I have added some comments in italics: PDF 1.4 - All placed PDF versions are correctly exported (as long as version number of placed PDF is 1.4 or smaller) PDF/X-1a - All placed PDF versions are incorrectly Rasterised on export PDF/X-3 - Placed PDF 1.4 are incorrectly Rasterised on export | all other PDF formats are correctly exported (as far as I understand all non PDF/X-based placed PDF gets rasterized, as does PDF/X-4 which uses a later version number) PDF 1.5 - All placed PDF versions are correctly exported (as long as their version number is PDF 1.5 or lower) PDF 1.6 - All placed PDF versions are correctly exported(as long as their version number is PDF 1.6 or lower) PDF/X-4 - Placed PDF 1.4 are incorrectly Rasterised on export | all other PDF formats are correctly exported (as far as I understand all non PDF/X-based placed PDF gets rasterized) PDF 1.7 - All placed PDF versions are correctly exported (correct, but if live transparencies are not allowed, they need to be manually flattened or rasterized on canvas). I do not really know. I think that compatibility rules are related to not just version number (requirement that export version number is the same or later than version numbers of placed PDFs), but to complexities related to mixed color spaces (RGB and CMYK) and live transparency. Since both features are by specs allowed in version 1.4, but RGB and transparency are not supported in PDF/X-1, and transparency not supported in PDF/X-3, this would appear to explain why non PDF/X based PDFs placed for passthrough are categorically rasterized (as Affinity apps cannot currently flatten transparencies by means other than rasterization, and it seems that complexity of handling affected parts separately is currently avoided by rasterization of the whole file). But why aren't these features supported in PDF/X-4 then, and why placed PDF using version number PDF 1.3 (= always CMYK and no transparencies) get rasterized, or why PDF/X-1a cannot export PDF/X-1a (placed for passthrough) does not seem logical. It seems rasterization also depends on use of features, especially blend modes, and issues with colors getting changed at export to presence of dual color space RGB & CMYK in situations where live transparencies are retained (transparency blend mode is left in RGB mode while objects where they are applied can be DeviceCMYK). Anyways, this gets easily overly complex and hard to control so a kind of a rule of thumb for problem-free creation whenever PDFa are placed for passthrough would be always exporting using PDF 1.7 and make sure that live transparencies are allowed in production files (and otherwise flatten them manually or rasterizing them qualitatively on the canvas).

I tried to upload both the .afpub and PDF files to show the difference but the forum keeps on rejecting my .afpub uploads. I am attaching them here as a zip file and hope they finally get through. layersv1vs2.zip What these files show is that when v1 .afpub is opened and upgraded to v2, the document structure can be exported to PDF layers and read back at levels beyond 1 (I have tested up to level 3 which is already good, but have not checked if there is a level limit). This is interesting because as far as I know PDF specs allow multilevel OCGs but in practice I have not seen other than Affinity apps utilizing the capability. It is probably related to the fact that Adobe apps use OCG layers at global level as e.g. language/translation levels throughout the document, while Affinity apps use them at per page level. At page level multilevel hierarchical grouping is useful while at document level less so. Adobe apps also enhance PDF and EPS exports by including native AI layers in them so there is obviously no need to support reading back OCG layers within Adobe apps. Anyway, OCG might become a useful method of providing multilevel organized document structure e.g. for print production and accordingly avoid the need to provide Ai compatible EPS and PDF files for postprocessing.

Do you mean that when transferring v1 .afpub files with "Layer" layers, they do not translate to "Layer" layers when saved to v2 .afpub files? My understanding is that when you export layers in PDF format from version 2, you will get Acrobat OCG multilevel support both in Adobe Acrobat and when reading these PDF files back into Affinity apps. In version 1 there was only root-level support both when showing these layers in Adobe Acrobat, and when reading back Layer layers in Affinity apps. So rather than degraded the support for OCG layers has improved. It is another thing that Affinity OCG layers are not global (contrary to Adobe created), and that Affinity created OCG layers are not supported in anywhere else (at least as far as I know) than Adobe Acrobat, and that no other than Affinity apps can read them back. But personally I consider this a valuable feature addition within Affinity apps suite. layersv1.pdf layersv2.pdf

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).

Here the issue is experienced on macOS. where_is_it.mp4 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.

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.

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).

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.

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).

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.

Yes, here it happens when saved on macOS and transferred onto Windows: where_are_the_embedded_files.mp4 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.

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.

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

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

It does not seem to be as much a question of "old" vs. "new" apps, but the level of support for different standards, some legacy (like non-Unicode Windows or Mac encodings), some new (like variable fonts). All browsers on Windows that I tested (Chrome, Firefox, Edge) can render the SVG test file provided (the one created by AI CS6) without problems, as can apps like LibreOffice Draw, VectorStyler, CorelDRAW (after PANOSE font matching and showing all codepages), Xara Designer, and Krita. But Affinity apps are not alone, so e.g. Inkscape and GIMP cannot, nor can Adobe Photoshop CC 2023. And it seems nothing on macOS can render it correctly (except VectorStyler, after manual fontname mapping; UPDATE: Google Chrome can, without any issues while Safari cannot), so having the support and then capability to change to something more universal (even if just converting to curves, but having correct rendering) and up-to-date is a useful and important feature.

If it is a question of having a memory issue at the time of using "Replace image" feature while having the Resource Manager open (either for single or multiple files), using a trick of renaming the original jpgs in the file system, then reopening the Publisher file, and then (when Publisher cannot find the linked files and shows a dialog box warning) choosing "Yes" to relocate the files, but choosing the TIFF files instead of the original JPG files, might be able to avoid the memory issue (as I assume that it technically just replaces filenames rather than tries to allocate memory at the same time, which Resource Manager probably does). Worth a try, anyway.

Text > Show Special Characters (this shows also many other white spaces and special characters). Thanks for the info. Hope the initial issues with transparencies are now history. They might have been a separate issue totally (since I did not manage to reproduce these problems by using the resources that you provided and methods that appeared to have been applied on them). To be sure, you could run PDF/X-1a verifier routine with Adobe Acrobat Pro on the actual production file.

No it is not but since the demo fix was also a Quartz production, I think that the issue is actually caused by extracting demo pages from Preview! So this may be just an illusory issue caused by Preview, and the initial file exported from Publisher is just fine -- just a guess.