lacerto

Yes, and both methods can also be used (with monospaced fonts) labelling e.g. sectors of a pie object:

Using Justify All, as advised by @thomaso is useful, and can be applied accurately with a monospaced font to create a specific, uniform space width, like below, where the width is set to 5mm to create a kind of a ruler. I also noticed a bug since I suppose that the ligatures should not have effect if forced alignment is used [Actually I am not sure they should be used with monospaced glyphs, no matter which alignment is applied, so I do not see the point why ligatures have been defined for Aptos Mono, in the first place]. letterspacing.mp4

Ok, I see. It is quite possible that my example is not useful for you. It just limits to demonstrate a situation where a CMYK image that has already intended, final color values, can be merged using a blend mode without causing color values to change. The file also demonstrates the weak point of using Affinity based PDF/X-based transparency flattening, as the transparencies are flattened by rasterization, which shows clear pixelation of underlying rasterized text objects. In practice it may be necessary to manually remove background of all participating objects and then manually flatten them (merge them with the rest of the final image) at optimum resolution (to guarantee optimum and homogenous rasterization).

Try with the attached package. It may have elements that differ from the condition you have in your document, but the idea was to compare how using different Blend modes (Glow and Lighter Colour) on a placed CMYK TIFF bitmap compares to one where Blend Mode curve is used, instead. There is also a separate TIFF that has transparent background, just for easy comparison to how the yellow of the "logo" changes or is retained when using different methods. There is also a CMYK PDF that is exported by using the PDF/X-1a:2003 method that shows a PDF that has transparencies flattened (Amazon requirement), and where the original CMYK values of the logo are retained (when using the Lighter Colour blend mode). PDF/X-1a:2003 and PDF/X-3 are methods where transparencies are automatically flattened. PDF/X-1a:2003 additionally forces CMYK color mode in situations there are mixed color modes in the source files. Hope this helps! logotest.zip

The results may be file-dependent, but with my tests with using Lighter Colour Blend mode and forcing transparency flattening with PDF/X-1a:2003, the original CMYK color values of participating images were retained. Not so if using the Blend Options curve [But it is naturally necessary to isolate the blend mode to only affect the required layer(s)].

Lighter Colour blend mode respects the color values of the layer on top, which may be important as the OP mentions CMYK values.

I ran a quick test by placing PDF/EPS files in context of data merge, but could not reproduce the issue otherwise than when violating Affinity general PDF compatibility rules. So e.g. in the following two attachments, the Affinity logo is created in Illustrator and exported as PDF 1.3 (which Affinity apps cannot produce), and it is retained as vectors and colors unchanged (K100), no matter if it is exported to PDF1.7, or PDF/X-1a:2003 (internally 1.4) from Affinity Publisher, while the PDF containing CMYK elements ("A" characters and a K100 ellipse), exported as PDF1.4 from Affinity Publisher, will be rasterized because of violating compatibility rules for being a placed non-PDF/X file but exported using any PDF/X method (or if exported using non-PDF/X method but version number lower than the placed PDF). testpdf17.pdf testpdfx1a.pdf My point is that I could not reproduce data-merge specific anomaly in vector graphics being (inadvertently) rasterized, so it is worth the check if the reason for rasterization could be in violation of Affinity PDF compatibility rules. The easiest way to check this would be exporting using PDF v1.7, which is the most compatible export method within Affinity apps, as it should be able to export without rasterization and color changes all placed PDFs created using Affinity apps, whether PDF/X-based or not, and disregarding the version number; note though that I have note tested PDF2.0 which is not a common PDF version at least within commercial press and is not e.g. supported within Adobe ecosystem). PS. It was interesting to note that non-PDF/X-based PDF in version 1.3 (produced from Illustrator) works without issues within Affinity apps also when placed in a document that is exported using PDF/X-based methods, which demonstrates that there is something wrong in Affinity PDF/X-based exports whenever having Affinity-based non-PDF/X files placed in the document (PDF-X1a:2003 is based on 1.4, PDF/X-3 on 1.4, and PDF/X-4 on 1.6 so technically a PDF1.4 based non-PDF/X-based file, like in the posted example, should work without issues with all PDF/X-based exports).

The way black color is handled can be rather complex, and is further complicated in a color managed environment where color definitions can (inadvertently) change when changing color modes, or when e.g. copy pasting identical color values from different color spaces. Just consider the following clip showing how "black" text gets handled and its appearance changes when defined in different color modes and when (intentionally) getting converted from CMYK to RGB color mode and vice versa, and also, when changing the document color mode from CMYK (where colors are simulated / proofed as if printed according to the active CMYK color profile) to RGB: blacks.mp4 In e.g. InDesign, there are user-selectable controls which allow avoid this fluctuation by optionally rendering all black as black as possible (without actually changing the underlying color definitions), instead of using true values. It is also interesting to note the differences in color conversions between Affinity Publisher (as shown above) and InDesign (below), when the underlying document color profiles are identical (sRGB and ISO Coated v2). The small difference in CMYK to RGB conversion is understandable, but I wonder if RGB0,0,0 to CMYK conversion was previously similar as in Adobe ecosystem, so that the conversion would be rich black (rather than K95)?

I would "solve" this by replacing the text parts that need to be hidden by using forced line breaks (assuming that the text object uses common line spacing) -- and making a hidden copy of the original text if it should still be available. Basically leaving clipped objects as "available" in an exported PDF is expected behavior, but it may require specific tools to be able to select and edit them (so e.g. clipped ellipses might still be ellipses in a PDF opened for editing even if not in a PDF viewer with editing capabilities). So simply just clipping objects would not typically result in a kind of re-composed design in an exported PDF that would (selectively) destruct exported objects: instead, the export would consist of different kinds of clipping groups. More specifically, I would not expect that clipped text, which is wanted to be retained as text, and selectable, would get any special treatment, when exported. UPDATE: In e.g. InDesign, it would be possible to select clipped parts of text and convert just these parts to curves (while retaining the visible part as selectable text), but that would not "hide" what was actually written, just make it non-selectable as text. If there are privacy or security interests involved, these kinds of issues should be resolved differently.

There is one thing that is not always obvious, causing all kinds of issues when opening Illustrator created PDFs in Affinity Designer. By default, Illustrator embeds native AI version of the job in a PDF saved from Illustrator. While some apps are able to interpret (at least some of) this native data, Affinity apps cannot do this, but just read in the PDF portion of the file. This means two things: The objects interpreted from PDF data have decreased editability, so the document has lost its structure, complex but editable objects have become separately rendered objects, etc. Certain objects, perfectly rendered and reproducible (printable) in PDF, may be totally omitted when opened in an Affinity apps. This includes e.g. complex gradients like this: ...also crucial production attributes like overprinting, so e.g. when a text object or any shape has trapping ensured using overprinting at abutting colors, like below having 0.2pt red outline overprinting over the background black, to avoid a gap caused by a tiny misregistration (below previewed in Illustrator, and fully carried out in the PDF saved from Illustrator): ...loses its overprint status when opened in an Affinity app (which is an omission within Affinity apps, not something that happens inherently when interpreting PDF), and becomes a knocking out element, which not only makes the text object visually "bolder" than designed, but also loses the trapping quality and typically results in the kinds of "seams" mentioned in the original post (not only showing in diverse zooming states on screen, but also when printed, as tiny gaps where paper shows between abutting colors not sharing a common ink): So, Adobe Illustrator support, which Serif lists as a kind of a compatibility feature, is severely limited, and cannot be trustfully used for professional purposes, because key features, related to (press) production, are not properly translated, and because certain objects might be totally missing, or coarsely misinterpreted when read from the PDF layer. I would be very careful in context of any kind of professional work claiming "Illustrator compatibility" without ability to open and check the details with Illustrator. This kind of trust may result in gross errors.

As the PDF has well-defined page boxes, Affinity apps should ideally (if not otherwise then for co-operative purposes) offer an option to crop a document (create artboards) according to an existing, document-defined page box, rather than automatically cropping to the bounding box of objects -- or at least default to cropping to the artbox (largest defined page box). I do not think that there is a conflict in having a trimbox (and bleedbox) smaller than artbox (or media box). E.g. Illustrator, CorelDRAW, VectorStyler, Xara Designer Pro and PDF-XChange all open the PDF cropping it to the artbox. Inkscape (1.4) offers options for cropping to different page boxes but then fails to create the page size according to the selected option.

I think these are just hastily implemented features. At some point Serif was eager to have an apparently competitive feature list half-way implemented, leaving loose ends to be "soon" attended (at some point even along some kind of a roadmap). The way the support for .webp and .jxl is implemented is a kind of a hallmark of this kind of development, sometimes called "promiseware". Now the development has been stalling for a good amount of time, so it could be said that we now have "hopeware". That's just fine if one is not dependent on missing features so that one can pay once for working, existing, software and then a little bit for a another, hoping the best for the future competition! Win-win, or lose-lose 🙂

What you say "exactly" above is: ...which is not what I see: It is not at all mess, having 662 text objects mapped to more or less correct glyphs, having mostly just vertical bars and legatos as curves. Open it in e.g. Illustrator CC2025, and see what happens when glyph-mapping fails (is given up): ...or in Xara Designer Pro (here v19.01) to see what happens when embedded glyphs are used but not mapped to actual installed fonts (fidelity is good but editability very poor): Ties would initially be text (e.g. Opus Special Std) in original notation software and when exported to PDF: ...but they would also be "edited" with pretty different "text tools" and input methods (of course mapped to keyboard, but pretty customary): What I am saying is the Affinity apps do an excellent job in interpreting the PDF. But I see no much point in using Affinity apps to edit musical scores, in any other than some limited technical tasks, needing to fix some details when the original notation software is no longer available. UPDATE: As for comparison to PDF editing (with e.g. Adobe Acrobat Pro), this is of course the main choice whenever integrity of the original file is wanted to be retained, just making isolated changes. But imagine e.g. a task where you need to translate lyrics (remove the original, or set it in layers to be selectively turned on or off as per language), etc. The file would naturally be fully re-interpreted, and there are significant risks (possible failures when RIPped for commercial press), but that kind of job would also be very painful to carry out in true PDF editor.

Yes, but much is "editable" text (rather than curves), so as far as appearance is close to match, it may be worth an effort (to make some minor changes). One needs to have notation software to be able to actually edit notes, durations, legatos, staccatos, etc. so I am not sure to see the point of opening a score in an Affinity app. I am just saying is that they do the interpretation pretty well...

Publisher (or the other Affinity apps) map the embedded glyphs pretty well to ones of installed fonts so that the "text" remains editable, but there are prerequisites, like in this case having the Opus fonts (from Sibelius, total of 17) installed, and the old Type 1 version of Times installed (glyphs would be totally wasted if Times New Roman OpenType were used, which I suppose also makes this task inaccessible for modern macs): So, with the embedded fonts available (installed), one could get pretty usable "text": Depending on what needs to be edited, one plausible option would be to convert the embedded fonts to curves. This can be done e.g. with Adobe Acrobat Pro, or Ghostscript (which was used to create the PDF, in the first place), without having the fonts installed. When subsequently opened in e.g. Designer, the appearance is fine, but editability "symbol-wise" of course pretty much zero: 03 Georg Friedrich Händel Lascia ch io pianga_nofonts.pdf

At least in the Windows version (2.6.3) it is possible to drop the document profile when exporting to JXL. But then there is another bug where Affinity Photo (at least) adds a Color Profile meta data tag and marks it for sRGB, without making a conversion, so the result [whenever working with non-sRGB source file] would be guaranteed to be interpreted erroneously when the file is opened. It seems that it is not possible to omit this meta data misinformation for JXL files.

You probably mean that Affinity apps simply just ignore any profile and just export to the .webp format ignoring the document profile, just saving the color values (causing significant distortion of color values whenever a wide-gamut document profile is used). They also drop any profile embedded in a .webp file and just read in the color values, assigning any profile the user has as an active working space profile in the Preferences. However, they can embed the active document profile within a .JXL file, and do also read in any embedded profile in a .JXL file.

One problem might be that it seems that bit rates (16-bit TIFFs) do not get converted to 8-bit (unless "Everything" is rasterized). Is it possible for you to produce flattened images (if there is no need for retaining transparency) in 8-bit at DPIs which do not require downsampling? Those kinds of images should also be compressed effectively (but might then contain JPEG artifacts...) UPDATE: I ran a test using Publisher and InDesign where I had 16- and 8-bit TIFFs and 8-bit JPGs at varied DPIs and exported to RGB PDFs downsampling to 300dpi, using default compression rates, and noticed significant differences, especially if 16-bit TIFFs are involved. Publisher leaves them 16-bit while InDesign converts them to 8-bit (also when exporting to RGB). Files and placed PPIs involved: Export sizes: Quality-wise there were no significant differences, and texts looked fine in all files also when downsampled to 300. I have no experience of the effect of decreasing the JPG-quality (was the default 98) but as for InDesign, the image quality setting was "Maximum" and compression setting "Automatic (JPEG)", and the produced filesizes clearly smaller also when exporting (and downsampling) mere 8-bit JPGs.

It is related to the peculiar way Affinity apps interpret and process grayscales. Your barcodes are grayscale PNGs which is perfectly fine. However, when placed / opened and interpreted, Publisher has assigned these grayscales "K-Only" attribute, which in a CMYK document allows an Affinity app to handle a grayscale image as black ink (K-Only, C, M and Y 0), which is how print industry typically processes grayscales. However, there is no such thing as CMYK PNG, or K-Only PNG, so when the document is printed, the "K-Only" PNGs are simply just ignored and will not be printed. In the following, I fix the issue by switching the color mode to CMYK so that K-Only button becomes available. I then turn off the "K-Only" attribute for all barcodes and switch back the document to RGB color mode so that the barcodes get processed as RGB images and will be printed: fixed_konly.mp4 The fixed Publisher file is also attached: Barcode_fixed.afpub

You could also do something like this to simulate defining a matte hex color (meta data) for the transparent background of a raster image placed in Designer: changebg.mp4

CorelDRAW is actually pretty unique in its print capabilities, because it is one of the few that makes it possible to create fully professional (color managed) signatures and custom n-up print jobs, rather than being limited to RGB and printing to a local printer -- but these limitations are typically not significant in personal projects so users coming from e.g. Microsoft Publisher and the like (non- or semi-professional) software may expect to have these kinds of features in professional graphic design software. But in fact they are also missing from Adobe apps (or have limitations like the booklet feature of InDesign), so if something like this is needed and not given for a 3rd party (printer) to carry out, it would require e.g. duplicating and arranging pages in Adobe Acrobat Pro using a JavaScript (to avoid manual imposition workflow or tedious repetitive work when needing to make fixes or updates), or purchasing (subscribing to) an InDesign plug-in, or dedicated (typically PDF based) imposition software. So extra skills, or at least some extra money (not much, though) is typically needed... UPDATE: For Windows, there is a free imposition utility with limited features available at https://www.montax-imposer.com/download. Paid versions have less or no limitations but for simple jobs (including kinds asked in this thread) already the free version would be enough. I could not get the Acrobat Pro based plugin version of the utility save the custom templates I created, but the stand-alone version works without problems. It might take a while to learn to create more complex signatures but the utility allows manual editing so it is quite versatile. And as it operates with PDF source files, it has no problems creating color-managed output.

Workarounds are the second nature of software with internal limits, and welcome in lack of anything better, and often just needing a bit of re-thinking and flexibility. But having features like ones asked in this topic for ages in PC software like Microsoft Publisher -- possibly also in Serif PagePlus??? -- understandably causes frustration in users who are accustomed to create advanced projects and finish them without needing to settle with tricks and compromises (and often without help of 3rd parties). I think it was possible to create custom signatures already in CorelDRAW 1.0 in 1989 (but I might well remember wrong):

Well, as demonstrated above, Affinity apps often bloat the file size when meta data is omitted. And practically, it is enough to have this simple tag included, to have information on the color profile included and have the file properly color managed: Certainly no need to drop this because saving some disk space. But it is a different issue when full ICC profile is redundantly (and inadvertently and unnecessarily) saved just because the app cannot properly create a lean, DeviceCMYK PDF output (unless told so, using PDF/X-1a:2003, with all unwanted side effects). These are file size differences when exporting four different RGB TIFFs to press PDF using InDesign and Affinity Publisher, differences in practice consisting of (unnecessary) ICC inclusions: ...something confused like this: UPDATE: The forum software is not color managed, so it only just takes color values, without conversion, which can be seen below, where two images, the left one having Pro Photo RGB ICC embedded, and the right one, with sRGB ICC embedded, would closely match if color managed: First managing, then dropping is of course useful when there is no longer use for the profile (e.g. when creating DeviceCMYK files that need no further processing at RIP), to save disk space, but for general purpose there is no much point in being this frugal, since this may result in heavily distorted visual appearance when the image is used again in varied contexts...

I am not sure if I understood correctly your goal but if it is ok that the PDF stays in RGB color mode and placed images as small as possible, I would make sure that the document color mode is RGB/8 and not CMYK. Then you could export forcing rasterization of "Everything", and specifying downsampling to desired DPI (unless you can have placed images already at the desired resolution). This would reduce the bit depth to 24-bit (8-bits per channel), and avoid image-specific (typically redundant) inclusion of ICC profiles. You would not be able to extract anything image-wise from the PDF but you should have the end result at optimized file size and quality.

As mentioned, the initial cause of this behavior is that you have black text that knocks out other inks (Cyan, Magenta and Yellow), causing "holes" in them, and if you have any misalignment issue with print heads, it shows like this, minor white gaps between the ink edges. In commercial press this is called misregistration, and the ways these issues are tried to be prevented is overprinting small black text on lighter colors, or adding trapping (e.g. specifying an outline that overlaps a bit with an underlying ink), or specifying a common ink for bordering objects so that there will be no paper blank between the objects when separating the job). Trapping is partially automatic in some apps (not within Affinity apps), or it can be applied by the printer or by the RIP software, but often it needs to be applied manually. You might have been able avoid the problem without print head alignment routine also by manually applying overprint attribute for your text, like this: Simply just having text as K100 would semiautomatically work when exporting to PDF, because Affinity apps by default overprint objects that have K100 applied on them. You had RGB 0,0,0 applied for text objects, which would typically be output as four-color black when printing or exportin [in which case you would not have experienced the problem in the first place], but as I mentioned, printing routine might result in the RGB black being converted to (near) K100 ink (in my test print to a virtual printer, it was rendered as containing 1% Cyan and 98% Black, and knocking out other inks, i.e., not overprinting), which is why I suggested that you try if defining the text as K100 would automatically make it overprint (as it does by default when exporting). But it did not work as expected when printing. One step further would be adding C0M0Y0K100 as a swatch in a document palette, then making the swatch global, and finally applying it "Overprint" attribute, as shown in the screenshot above. This SHOULD guarantee that the text overprints also in context of printing so that any registration issues could be avoided (and it had been interesting to see if overprint attribute is truly noted in Affinity printing routines, since it might be that it is not, if Affinity apps send the printer driver converted and interpreted color data anyway). Keeping the printer in good condition is of course always a proper thing to do, and helps avoiding all kinds of quality issues. The primary reason for the gaps might still be there in your job, so making sure that it does not occur when printing with another printer, I'd recommend making the above mentioned change (at least making sure that the text is K100 and other inks 0, which, as default, will cause that PDF exports will have black text as overprinting).