lacerto

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.

I think that in order to have .psd files associated with Affinity Photo within Bridge, you additionally need to explicitly do the association using the Bridge Preferences (File Type Associations), as follows: That is, the association within Bridge does not necessarily reflect the default app currently associated with the extension within Explorer, so you need to change it within Bridge to have PSD files browsed within Bridge to open by default in something else than Photoshop (or Illustrator).

BMP is the native Windows bitmap standard, and in that sense very commonly used bitmap file format, which, as mentioned in this thread, is already (partially) supported within Affinity (Windows version) apps as opened / placed file format, Clipboard format and resource link format, and additionally as part of .WMF/EMF export format. The core of the BMP format, the DIB image structure, is also very commonly used in Windows programming (because being free and well documented image file format) to handle bitmaps programmatically. The BMP file format is also supported on macOS (both as open/import and save/export format) not just within office apps like Microsoft Office 365 and LibreOffice, but also e.g. by Photoshop, Pixelmator Pro and Corel apps, that is, within the kind of professional graphic design apps for which Serif wishes to offer an alternative. BMP file format is by no means a common file exchange format within graphic design industry, and is in many ways a limited file format, but nevertheless it is well supported by the competition. Serif's call, of course, to decide how high they aim in their claim of offering a "fully featured" (their choice of words) app package, and how much their offering lacks and requires additional tools for doing simple and common tasks like ones asked in this thread.

I think that the current omission of BMP export format is a kind of a priority issue. There is hardly a Windows image app in the world that could not save in / export to native Windows bitmap format, so in that sense not having explicit BMP support is a kind of an absurd shortcoming in a dedicated graphic design app suite. There is, after all, direct support for opening (certain kinds of) BMP formats, and as shown above, support for pasting inherent Windows bitmap formats via Clipboard (and subsequently saving them as linked .BMP resources), and support to save mixed graphic content as .WMF files, which can contain native Windows bitmap resources, so in a way the kind of minimum support already exists as a workaround. On the other hand, BMP format has several sub formats (1-, 4-, and 8-bit indexed formats that Affinity apps support only cursorily if at all, RLE packaging, advanced 16-, 24-, and 32-bit depths many of which only rarely used, legacy OS/2 format, etc., so proper implementation of the format would certainly take some time and effort. A kind of elementary implementation did not stop Serif when they added basic (currently bugged and incomplete) support for WebP and and JPEG XL, so in that sense just adding basic support for Windows BMP format (which inherently does not support ICC color profiles and would be very simple to implement in plain RGB format), as well, is something that at least Windows users can reasonably expect to have, and are also likely to have sooner or later.

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.