lacerto

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