lacerto

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.

Btw, I noticed that PDF producer in your demo file was Quartz PDFContext??? Was the file produced (post-processed, saved as, pages extracted) in Preview and not directly in Affinity Publisher? This could well cause all kinds of issues, especially if you try to produce a standard PDF/X-1 file... EDIT: If this was done only for extraction of pages but you create the actual print file using Publisher, and PDF/X-1a:2003, as shown in your screenshot, I do not think that there will be issues. Good luck!

Yes, a level adjustment. I'll try to reproduce this on macOS Publisher v1 version -- I tried already on Windows v2 but there could not recreate the issue... EDIT: Could not reproduce this (by converting the PNG file you provided into a picture frame, cropping it and applying Level adjustment; it exported without problems to PDF/X-1a without transparencies). Perhaps there is something else on the page that causes it, another adjustment placed somewhere on upper layer, e.g. that hand image?

What is the "regolazione livelli" that you have applied on the image? It is probably this that causes the "SoftMask" and does not get flattened at export.

The fixed file still showed the same issue. I ran a Convert to PDF/X-1a fix (using Coated Fogra 39, as did you; note that it might be better to use US Web Coated v2 instead, but I do not think that running the fix changes the TAC, though). demo2 correct with Adobe_fixed.pdf Running PDF fix is of course one way to resolve this, but I would try to find out the actual cause for the error. I could not reproduce it by converting the PNG image you provided to a Picture frame but then again I imported the image from file system rather than via Clipboard from a video app. Anyway, just converting to picture frame and cropping did not leave any transparency in the image when exporting to PDF/X-1a from Affinity Publisher.

Sorry, I misinterpreted the Italian language menus and can now see that you actually converted the images to picture frames (rather than image layers). The problem is not in the images themselves, and I could not reproduce the problem by just converting the image into a picture frame, either. Do you have any F/X or adjustment layer applied on the page where the problem occurs (p.52)? Basically if there has not happened any error in exporting to PDF/X-1a, this should be a fool-proof method to flatten transparencies so it would be really interesting to find out what causes this.

I was wondering why since if you place or paste raster files (from file system or stock photo site), or screenshots, they already are image layers.

Ok, thanks. The specific transparency that existed on that image was "SoftMask". It may exist in the placed image already, and Affinity apps might fail to flatten that kind of transparency during export. I have not seen this happen before so it would be interesting to examine this closer. Can you post that image on the forum (zipped, if possible)?

Perhaps something went wrong with the export because when I run compliance test against the demo file, I get the following results: ...so this file would fail in any automated prepress check possibly done in context of file delivery.

Does that image have any F/X applied? I am not sure if I understood the import method (turning placed images into image frames?)

I had quick look on the file and it seems pretty much standard DeviceCMYK file with text having K100 color values and max TAC around 300% (something you would get e.g. with US Web Coated v2), so without knowing any detailed specs I would say that this should produce as expected. However I remember that you were asked to produce the file without transparencies (and basically using PDF/X-1a standard). You currently have in the demo file on page 15 (52) live transparency due to having applied outer shadow on the leftmost image. Unless you have PDFs placed in your document, I would export the production file using PDF/X-1a, or alternatively remove or rasterize these effects on the canvas.

Yes, that was my comprehension of color management in Adobe Reader (but as said, it is long ago I have had mere Reader installed on a production computer), so therefore I was surprised to see the behavior with embedded ICC (but as for handling non-managed file, just rendering in full display gamut would not be odd even if a bit user-unfriendly, considering that there is no explicit color profile configuration as there is in Pro). Pro-non-pro conflict is of course possible, especially in a kind of environment that has the whole CS6 package, a few of the most recent CC apps, and Adobe Acrobat Pro 2020 and X installed on the same computer. They all work fine, except for Adobe Reader DC (current version). But considering that there is plenty of Reader competition, and seeing how Pro features are developed in reach of a single click, mere Reader seems now a kind of a teaser app, especially for users already subscribing to a single product like Photoshop. Having two single app subscriptions (especially Acrobat DC Pro) is [nearly] as costly as subscribing to the whole package...

Thanks, I noticed these posts, and found them confusing (especially the last one you referred as it mentions color preferences and overprint preview in context of mentioning Adobe Reader), and as mentioned, considering lack of current official documentation supporting Dov's claims, or installation-time warnings (something that I am accustomed to see when installing Adobe apps in an environment with already installed Adobe apps, in context of trying to install something not supported), installation requirements, etc., I am not sure if this could actually be a deliberate change. Anyway, I am not going to uninstall Pro just to test this, and I am not currently at office so cannot test Reader installation on a computer with no Pro pre-installed, or macOS version behavior on a wide-gamut display on modern mac (and Ventura).

You're welcome, @FromTheDeep -- I am happy to be able to help, though I'm afraid often end up adding confusion, as color management related issues can get pretty complex. Before experiencing this issue by reproducing it in latest Adobe Acrobat Reader (Windows version) also with a file with embedded ICC, I would have answered that whenever exporting to RGB and using sRGB as document and export color space, embedding the profiles should guarantee that your clients get good visual approximation of how colors are intended to look, both when using a modern browser and when using common PDF viewers. But now I am not sure: there are plenty of posts on Adobe user forums that report issues with Adobe Acrobat Reader and oversaturated colors on wide-gamut displays also when using embedded profiles that I am not sure of a definite answer. Whether it is a bug related to having both Adobe Reader and Pro version installed simultaneously (which I doubt because there are reports extending to a few years back, and not all users have had both apps installed), this, nevertheless, is true at the moment: On the left, Adobe Reader plug-in is used within Chrome, which is a color managed app (has been for a few years now, similarly as most major browsers though on some, color management might need to be specifically turned on), which for unmanaged files like your initial post (which did not have an embedded profile) means that sRGB profile is applied (assigned) to them, meaning that your clients are seeing approximately correctly rendered colors (even when having wide-gamut displays). On the right is the same file shown in Adobe Reader (latest version), non-color-managed and with full display color gamut, and it would appear to be an error, especially since the same behavior can be experienced even if the file had sRGB profile embedded. But considering that there is nothing mentioned at installation or system requirements of possible conflict, nor could I find anything mentioned on Adobe Reader help and web site (only on user-forums), I really do not know what to say. Anyway, whenever working with color-managed apps, the method to guarantee correct rendering is to export to sRGB and embed profiles. A kind of a workaround is to provide rasterized proofs, or ones that stay within browser (whether color-managed or not). I can see how poor option it is to ask your clients to install a specific (color managed) PDF viewer, as many of them are likely to be on Windows and use Adobe Reader as a desktop app (and experiencing this problem if they have wide-gamut displays, or possibly, additionally a dual installation of both Reader and Adobe Acrobat Pro, if it is really this situation that is causing this behavior). You could perhaps place the files on your site for download and if rasterized file formats are not possible, ask (if "hope" is not enough) that the clients use browser PDF plugin if it seems that viewing PDFs on a separate PDF viewer shows oversaturated colors. To me, the app to go is Adobe Acrobat Pro 2020. It is based on perpetual license and Adobe still sells it both for Windows and macOS. An alternative would be pdfToolbox by Callas software but it is even more expensive (perpetual license, too). There is free software (both for Windows and macOS) called PACKZVIEW, which is a decent viewer, but as far as I understand credentials are only given to professionals and especially ones within package industry. But I think that for proper prepress functionality (fixes, etc.), either of the first mentioned apps is required. As an independent (sole) subscription based app Pro DC is pretty expensive (if you do not need its document sharing/editing features), so I do not think that it is impossible that Adobe tries to push users to full CC subscription by having made Adobe Reader non-color managed (as it can be made color managed = Pro by "simple" push of the money button).

Thanks for the note. I was surprised to see this behavior in Reader and I would have assumed that it would at least adhere settings made in Bridge (as I could not find any settings related to Color Management in Preferences, in neither Windows or macOS version). I have not had mere Reader installed in ages so I had to install it now just to test the behavior, so at least the installation version did not have this behavior fixed. But I will check now if there are updates. EDIT: No luck with updates as my version is the most recent there is (Windows 11 Pro): EDIT2: I just tested behavior of Reader with an embedded ICC and it treats it just the same as a file without an embedded ICC, and I'm not sure if this can be right. It could be an issue of having both Reader and Pro installed on the same computer (even if I have Pro 2020 and not a DC/CC-based version, and installation of Reader definitely does not have effect on color management of Acrobat Pro). There might also be some recent change in behavior of Reader, so it may be possible that recent free (mere "Reader") versions are deliberately made non-color managed...

Please observe this video to understand differences in color management between Adobe Acrobat Reader (or DC without Pro features) and Adobe Acrobat Pro (in this case Pro 2020): colorviewers.mp4 As you can see, at least on Windows (this is from Windows 11 Pro latest version, and latest Adobe Acrobat Reader), rendering of colors in Acrobat Reader is basically non-color managed and the colors get rendered in full display color gamut (in this specific case a color profile measured with a device calibrator on my Lenovo laptop). I cannot say whether this happens also on macOS, because my portable mac devices are sRGB-only capable, but it might well be that colors are truncated to sRGB on macOS version of Adobe Acrobat Reader, even if the display could render wide-gamut colors, but on the other hand, I am not sure why this should happen -- in some ways it is better to have either non-colormanaged environment and then fully colormanaged environment, rather than some kind of half-baked color management, since the example file (provided by you) is basically "DeviceRGB" (having 0.7 0.3 0.3 in percentage RGB values) so how it gets displayed (as for visual appearance), depends totally on the viewing app at hand and the way it has been setup. Accordingly, when you have Adobe Acrobat Pro and full color management, you can get as-per-object information on color profiles possibly applied on the objects, and then render them using the matching color profile, or a conflicting profile and get different visual appearance or color values. Whether color values stay unconverted, depends on whether the objects are ICC dependent (=> color values are recalculated while appearance is tried to be retained), or if they are "device dependent" (color values stay but appearance typically changes according to the profile). Another, and remarkably more complex behavior is involved in print production involving CMYK and the confusing way Affinity apps handle PDF print production and ICC profile embedding, but this is beyond this topic.

As for license related to FontAwesome Free, please check https://fontawesome.com/license/free.

I tested this with 2.1.1 on both macOS (latest Ventura) and Windows (latest Win 11), but without any issues. My JSON looked like this: [ { "ID": 1, "Text": "Image 1", "Image": "Images/1653299237.jpg" }, { "ID": 2, "Text": "Image 2", "Image": "Images/1653299130.jpg" }, { "ID": 3, "Text": "Image 3", "Image": "Images/1653299153.jpg" } ] ...and the setup .afpub file was saved so that Images folder is directly below. So unless you use a different version of Publisher (which might have an issues with JSON), I'd suggest that you check that you have saved the setup file in correct location. Otherwise I'd suggest checking the syntax of your JSON (since when you set up the merge only the first record is fetched so if there is a problem with record separation, performing the actual merge might fail, including the first image).

Using e.g. FontAwesome and Unichar formula to produce symbol glyphs in an Excel sheet and then fetching them with Data Merge (below 1,001 icons, with a colored ellipse in the background of a Data Merge layout cell) is not too bad, either: Each icon is conveniently grouped, but background and stroke color and style could easily be changed en masse by using the Select Same > Fill Color command. As symbols are still glyphs of a font, their size and coloring could be changed equally easily by using the Select Object > Frame Text command. [The example is a variation of file-based image merge shown above by @David in Яuislip which uses a sizing picture frame as a container of merge instead of a text frame. If the images are initially placed files, it would be easy to make them linked and then create a file list by using in-built features of the file system, e.g. in Windows by using Copy as Path command for files selected in File Explorer.]