lacerto

I had initially that impression, too, but my point was actually rather the opposite: showing that the root of these kinds of errors might be in preprocessing, and be deeper and structural in nature. In many jobs these kinds of issues are marginal, and can be avoided with workarounds and careful planning and print production. Serif's PDF interpretation is in many ways formidable, and the app trio as total can be a valuable tool, but for press-related jobs it is not a very robust, or compatible one. Printing press is a diminishing industry, and prepress tasks demand a lot. I think that the world already has the tools this brand of production requires, and even if they are now again in strong development, unfortunately they have also become more expensive, because less and less people really need them, and many of those who still do, will now also effectively use AI, too. And the development also costs. As for "mere" digital production, the tools seem to become more and more "accessible" (affordable), but there, too, the need for individual and human input appears to diminish (or to some extent be totally replaced). Anyway (at least personally experienced, and hopefully the perspective is a bit cynically distorted), challenging times for creative people, and everyone involved in graphic design business (no matter how big), especially press-oriented...

When complex conditions increase (like need to flatten transparencies, overprinting, and interaction of placed files, including Affinity files, containing such attributes, with underlying native content), the risk of inadvertent changes in PDF production typically increase. The following video demonstrates issues with overprint attributes (which are simply just ignored) also when exporting to PDF a Publisher document that has .afdesign file with overprinting objects placed on a native magenta rectangle: overprintissues.mp4 This shows that problems with PDF production are not just ones related to inability to handle in a trustful manner PDF placements (considering inadvertent rasterization, color translations and incorrect overprinting), that is, something that could be attributed to needing to use third party PDF library, but also handling interaction with placed Affinity files, and native content, and calculating correct color values when exporting to CMYK PDF (and all rasterized CMYK formats). The video also illustrates problems with automatic flattening of transparencies involving overprinting objects (resulting in miscalculated total values of flattened color areas), even if a document consists of native objects only.

You might be facing what is known as Affinity PDF compatibility rules, which cause e.g. that e.g. all non-PDF/X based exports (like ones that have been exported using the default version 1.7 that supports transparency, including overprinting attribute), placed in an Affinity document and exported using PDF/X-based method (like PDF/X-1a, which automatically flattens transparencies, and also guarantees CMYK output), will become rasterized and have its color values converted. Note too, that Affinity apps always flatten transparencies by rasterization (they do not support recalculation of color values while retaining vectors, similarly as Adobe apps do), so rasterization happens for that reason, too. If your issues are related to generation of QRCodes, and having opacity and overprint attributes applied on them, you should be fine as long as you generate PDF 1.7 based PDFs, as those will have these attributes retained without causing rasterization. But if you subsequently place these PDFs on another Affinity document, and then try to export that document using PDF/X-1a:2003, in order to have transparencies flattened and overprint attribute to have the desired effect, you are in a trouble. To understand what I mean, see how Publisher and InDesign export a version 1.7 PDF containing overprint and transparency attributes, using PDF/X-1a:2003 method: pdf_compatibility.mp4 InDesign flattens the transparencies and resolves overprinting by recalculating the color values of affected objects, while retaining all objects as vectors. Affinity Publisher has rasterized the QRCode and made K-only based code rich black, but also distorted color values by knocking out colors from an underlying shape by using the shape of the QR Code. The IDML and the QRCode slice are attached for experimentation. qrcode_pdf17_w_overprint_and_opacity.idml slice1.pdf

I might have misunderstood what is implied here, but in my experience defining text or object color value using an RGB definition (any value, including 0, 0, 0), will always be translated whenever converting to CMYK at export time. This happens in all press-related apps that I have experience of, even if Affinity apps do behave in a bit peculiar way in certain situations (see e.g. the attached file, using sRGB color space and implied ISO Coated v2 CMYK document color profile, where an RGB black will be converted to K95, instead of rich black, as would be expected): affinityblacks.afpub Because of this, the "correct" ("controlled") method of doing these kinds of conversions would be doing it by using File > Document Setup > Color, and then using the "Convert" option and selecting a new CMYK target profile for the document (it is generally recommendable to have the document initially in CMYK color mode whenever targeting to CMYK; placed images, however, should generally be in RGB color space). For insignificant profile changes, using the "Assign" option would be a better choice, to avoid (unnecessary) change of current CMYK definitions. Note that when converting, the color values of objects that have been applied by using CMYK based swatch assignments will be implicitly translated (even if assigned colors still typically appear to be unchanged), so the swatch definitions are not converted even if the assignments are seemingly retained (but actually lost; keeping the assignments with changed swatch definitions would make it possible to change the converted values back to K100 simply by adjusting the swatch definitions, but this is not a usable method within Affinity apps). This means that the blacks need to be anchored to K100 either by using a text style definition, as advised above, or by using the "select same color" method, and then (re-applying the desired (original and unchanged) swatch value. It may be worth a note, too, that there is no equivalent within Affinity apps to a CMYK based swatch value [Black] that is used in Adobe InDesign, which causes that objects that have been assigned with [Black], will be exported as K100 whenever exporting to CMYK (and choosing to "keep color numbers"), and as RGB 0,0,0 whenever exporting to RGB. Within Affinity apps, K100 objects will be exported as dark RGB grays when exporting to RGB color spaces. [UPDATE: Using [Black[ will also guard objects assigned with this swatch value from design-time translations, when performing non-export time CMYK to CMYK color conversions; there is no comparable feature within Affinity apps.

It appears so. It is strange, though, that some Windows apps, like Notepad, behave correctly (showing true italic glyphs), some (like PhotoLine) show slanted/skewed fakes, and some (including e.g. Microsoft Word, and apps like CorelDRAW, Adobe apps, and Affinity apps, fail to display italic versions at all (if both upright and italic versions are installed) -- or upright versions (depending on which was installed first). As mentioned, some variable fonts having both upright and genuine italic glyphs, do behave correctly in all mentioned apps, so this appears also to be somehow font dependent. I tested the mentioned apps (PhotoLine, Adobe apps and CorelDRAW, same versions) on macOS and they all show the upright and italic versions of Merriweather correctly, which would imply that there is nothing wrong with the font itself. All in all, an odd problem.

I get upright versions marked as "Custom":

Yes, I agree that this is crucial. But I have not been able to find out what makes the difference so that some apps can interpret the slant parameter as an "instance" so that the italic versions appear as separate fonts. It is of course possible to manually skew any type at any degree, but why predefined "skews" or "slants" do not appear as instances in all apps supporting variable fonts is obscure to me. I have not been able to clear this up even when loading these fonts in FontLab 8, so I wish that someone with strong font technology experience like @kenmcd could explain this for us! UPDATE: Sorry, I failed to see the actual point of your comment. The fact that Merriweather, too, has non-slanted/skewed and separate cursive glyphs makes this much more complex an issue. I checked this only superficially and had assumed that this might be related to just failures to mechanically slant or skew upright versions of fonts (because variable fonts like Cascadia Code with similar properties work without issues in these same apps).

This is quite interesting, as it seems that encoding italics variable instances can be done in multiple ways, but not all apps support the way it is done in Merriweather. In addition to Affinity apps, current Adobe CC2025 apps and CorelDRAW fail to recognize them (at least on Windows), but e.g. PhotoLine shows them without issues: InDesign CC2025: PhotoLine: On the other hand, all the mentioned apps show without problems the italic instances of e.g. the variable font Cascadia Code.

Yes, I think that there are some internal "tricks" involved to avoid inadvertent rich black generation, and one is having the default for decoration fill set in K12. It will of course be automatically converted to whatever RGB gray (if actually activated), but stays as a K value (by default) whenever exported to CMYK so it will not cause problems in terms of rich black and CMY warnings (if turned on in preflight). But if it were explicitly specified in the equivalent RGB value, it would trigger the preflight warning, even if the actual CMYK conversion did not contain CMY values but were converted to a K value, AND, even if the decoration itself is not applied. This would previously happen (at least I recall so) also for RGB 0,0,0 text, which however is now converted to K95 (and CMY 0), while it previously was converted to rich black (as it, IMO, basically should be). RGB 0,0,0 text will NOT cause CMY preflight warning because of this. But RGB grays still cause, whether applied to text, fills or decorations (active or inactive), and as mentioned, even if they were actually converted to mere K values. In addition, I have noticed that there seems to be some kind of "memory" involved with object color definitions so preflight color warnings may be triggered even if all current definitions were mere K values (e.g. below with the mere K fill). Decorations have the additional issue in not being able to trustfully show the true underlying color mode: the color picker shows always the value in document color mode, even if the internal value were defined in another color mode. confusedpreflight.mp4 The .afpub document and PDF of the video clip are attached below. test.afpub test.pdf

It is in the (inactive) decorations: cmyindecorations.mp4

"Why create PDFs" and "the whole point of avoiding formats like PDF"? When the current stagnated development state is finally broken, there will be a few disappointed affixionados, but many happy users searching for alternative tools at more economical price, but being able to produce professional industry standard PDFs effectively.

It is just the app's term for the fonts installed and residing under C:\Windows\Fonts (admittedly a bit confusingly because the term typically refers to pre-installed fonts that come with the operating system), and shows such fonts on green background color. The utility can additionally search for local fonts from the user-specified "FontSets" residing on hard drives (e.g. from Adobe Font Folio 11 or Corel Fonts) and would show such fonts with yellow background color, and online fonts (both from free and commercial resources), showing them in red. The indicated matching accuracy is relative to the letter image created by the app (I have no idea why the font I had installed, which is an old TrueType TTF from ITC, had a slightly smaller accuracy than the OpenType version by the same vendor).

UPDATE: I do not know why I had it installed, so I actually used a utility to find out:

I am not sure if I understood correctly what was requested, but there is a way to create separate PDFs (per page) without using 3rd party tools if either Affinity Designer or Photo is available, by opening the merged PDF containing all pages in either app, and then using the Export Persona to generate the PDFs: separatepdfs.mp4

Click the Browse button within Bridge (see screenshot above), and then point to the Photo.exe, which you should have installed here: ...in case you have installed the app by using MSI installer. If you instead have installed as an app (using MSIX installer), then the executable is hidden under C:\Program Files\WindowsApps, which you cannot directly access. In this case you might have desktop shortcut (a .lnk file) created that points to Photo, and you could instead select this .lnk file when browsing for the associated app within Bridge. Or, you could alternatively choose to uninstall Affinity apps and download the MSI setup package so that you can install the Affinity suite as traditional Windows applications.