lacerto

That is not how it works, though. If you want to apply K-Only on an image and have it exported on K plate, it must be the sole operation on that image layer. You could apply K-Only, then apply adjustments (which cause the image to be handled as an RGB resource), and once finished, rasterize and convert the resulting pixel layer back to image resource, and then apply K-Only again, to force pixels on K plate. Or, you could export a K-Only image with adjustments explicitly to grayscale. That is admittedly quite convoluted.

My apologizes for all wrong assumptions!

If it has been tested there is no doubt that this will work perfectly! The method I was referring is based on color profiles and basically guarantees that too much ink is not applied, taking into consideration the actual media that will be used, while the visual appearance should be retained and be kept neutral, but that method would never result in K100 + a specific mixture of CMY inks applied, so the result could be less "rich", less intensely "black" than when using a predefined mixture where K100 + CMY mixture is applied (especially when tested). If I am assuming correctly, your are applying this to musical notation, and in this case the rich black would also be applied to thin lines like staff and stems (as all elements of the score would be created using fonts and fills), so therefore I was wondering the purpose of this procedure. But as you're printing digitally, misregistration issues are different from offset printing, and if they happen (showing as misaligned colors), would show anywhere and not just in thin and small objects, and the remedy is also different (done on the device and not in the design).

This is a bit strange procedure (especially if you have regular body text or notes in K-only), and also, because determining "rich black" with a predefined mixture is a bit odd, unless a specific tone (e.g. bluish, brownish, etc. tone is wanted), but in case neutral rich black is wanted, the easiest solution, as long as all you have in your design is text (anything laid out using fonts) and native shapes, is to use a different CMYK profile than what you currently use, either by using File > Document Setup > Color and switch the CMYK target profile, and make sure that you have Convert option selected. Or, when exporting, using a different CMYK profile than what your document uses. This will make sure that the rich black conversion is optimal and neutral (determined by the color profile). If your current CMYK profile is already correct, first switch to another CMYK profile but using the "Assign" option. Then convert to final CMYK profile and use the "Convert" option. But if what you really need is having CMYK 60, 40, 40, 100 (and limit the change strictly to text), then Find/Replace, shown above by @thomaso, would be the solution.

In lack of Adobe Acrobat Pro or other tool that you can use to directly convert a CMYK output to sRGB, I would first export a PDF/X-4 file from Designer, which will produce an all CMYK file using the color gamut you are seeing on your canvas. Then I would open that file in Designer in RGB color mode and export to RGB color mode PDF and SVG. The colors should be pretty close to ones you have in the original CMYK mode document. equalizing_cmyk_and_rgb.mp4 2. LOVE SAVES THE DAY for inflatable flat for printing color copy_pdfx4.pdf 2. LOVE SAVES THE DAY for inflatable flat for printing color copy_rgb.pdf 2. LOVE SAVES THE DAY for inflatable flat for printing color copy_rgb.svg

If the issue is that colors get clearly more saturated in RGB mode compared to native CMYK (in which mode the design is created), the reason is that RGB based definitions and/or effects have been used while staying in CMYK mode which cannot display RGB gamut. If you want to have RGB output as close to CMYK as possible, always define all colors using CMYK color model, including effects. Note that use of effects and adjustments typically causes conversion of certain elements to raster objects (as in your design, indicated by the fact that conversion of image color spaces is necessary to have all elements converted to RGB).

You should be able to convert everything to RGB simply by forcing it with export settings. Remember to also force conversion of image color spaces:

As stated above, if you have Photo, you can use Channels panel and/or histogram. But you can cope with mere Publisher, as well, as you can use the Color panel to check color values of text objects (and vector objects), and adjustments like Channel Mixer to reveal color in parts that look black (K-only) but involve multiple channels. poorishmanspreflight.mp4 As for causes Publisher will convert K-only to CMYK (multi-channel), there are various, three of which are mentioned in the video clip. One further, very common reason, is applying any adjustment or blend mode on text or native K-only objects, causing rasterization to CMYK. Applying F/X effects will often also do that, even if outer effects and Gaussian Blur might survive non-rasterized. Using opacity percentage, too, would cause rasterization to CMYK in case PDF output does not allow live transparency. Last but not least, Affinity apps by default embed document ICC in a PDF export, which will cause incorrect readings in tools like Adobe Acrobat Pro in case "wrong" simulation profile is active, or when using Ghostscript for separation.

Yes, but that is kind of tricky. As can be seen on the clip above, the placed RTF and Excel sheets can be fully edited in layout, but their formatting comes from the source documents. So if anything is changed in the hosting document, it will be lost if the changed source is updated. Therefore it might be simpler to just import "static" updates like sources that have been re-exported to PDF and then placed PDFs get updated in the layout. [UPDATE: In principle linked and updated RTF and Excel sheets can use InDesign defined (table) styles, but in practice manual reapplying and adjustments are nearly always required after an update.] For this reason data merge based updates (and as a special case, capability of updating already merged fields) is more versatile as it allows the hosting document to format the data container and just take the actual content from the data source: update_formatted_merge.mp4

These things are not impossible because something like this has been done already well over a decade ago 🙂 rtf_xlsx_links.mp4

If the feature has not changed since CS6, there is no chance that this happens inadvertently as the user either needs to manually update the data source, or fetch updated content to the already merged data fields. While there are limits as to what can be done to an already merged data field (e.g. as regards formatting), there are clear benefits of having truly updatable (linked) data merge. You can keep the merge setup files simple and use them in multiple documents amended in various different ways. updatable_datamerge.mp4 Affinity Publisher data merge could be automated with 3rd party tools and have data source update and remerge of data done on a push of a button, but it is a bit tedious because Affinity apps do not have accelerators defined in dialog boxes (and not even all menu items), so definition of automation needs to be done using screen coordinates, which is error prone.

In lack of proper preflight tool, you could open your exported PDF in an Affinity app, and get pretty reliable interpretation of color mode of objects in the PDF (things like overprint status would not be read, at all, but you should be able to detect things like K100 vs. four-color-black).

It IS a poor man's report tool because it will signal K100 in any PDF with ICC embedded (the default setting of Affinity apps when exporting to CMYK) as a four-color black (similarly as Adobe Acrobat Pro, if the implied but not explicitly stated target profile is not selected as the simulation profile). A good question is: will this be four-color black also on plates, or does it depend on skills of print-shop personnel that native colors will be output despite of ICC-dependent input ("input" in context of imposition software)?

Trying e.g. Lighten Blend Mode could be an acceptable workaround: Lighten.mp4

That was a sad try as I later noticed that I had somehow managed to turn off scaling of all FX applied in the design myself, before turning them back on 🙂

Try using "Scale with Object" property on your Outline FX: UPDATE: Just tried it myself: unfortunately does not help...

As Affinity apps do not allow conversion of color space of swatches, you would basically need to apply CMYK conversions on your HSL (RGB) definitions by using "Select Same" and/or "Select by attribute" features (available in Publisher and Designer), and using the Color Panel and CMYK sliders (and type in one of the color values or alternatively turning the lock off, to have the conversion made just by switch of the color model). If you do not have lots of pages, you might want to consider using Soft Proof adjustment layer with your CMYK target on top of each page containing RGB definitions. That would force the RGB gamut to come pretty close to actual CMYK conversions to the same target (just remember to turn off Soft Proof when actually exporting to CMYK). The price of that trick is that everything will be rasterized (as always when using adjustment layers in Affinity apps). [The way Affinity apps behave in CMYK color mode (forcing in a way automatic CMYK Color Proof according to the target CMYK Profile for everything placed in the document) will become as a surprise to anyone having worked with InDesign, where dual color model (RGB/CMYK) can co-exist so that RGB colors show in full RGB profile color gamut, while CMYK definitions are shown in target CMYK gamut. A specific color proof is used to force simulation of RGB color space in target CMYK.]

As I do not have personally needs for the kind of "global" swatch redefinitions described in this thread, I had a look on how this is done in InDesign and Illustrator (CS6), and basically silent updates to swatches are not supported in either app (which IMO is good; just having "conflicting" color definitions silently updated whenever a swatch called "Orange" is used in an existing and opened palette could be a catastrophe). However when loading or assigning a swatch using the same name as existing swatch (and also when trying to create a swatch with an identical definition with an existing swatch in the same palette / swatch library), the user is notified and the conflicting swatch can be imported/created using a different (unique) name. Afterwards it is up to the user to update the existing definition with the new one, or merge the conflicting definitions so that the old definition gets updated with the new one while keeping the current assignments (including tints and attributes of depending children). E.g., in InDesign this can be done simply by deleting a swatch and have it replaced with another swatch, while keeping all existing assignments and dependencies. Swatch color model (including spot color definitions) can be replaced similarly without losing assignments. There are no similar functionalities in Affinity apps, so whenever a swatch with a specific name in an app-wide palette is updated the existing assignments to that swatch are just lost. In Publisher and Designer, it would be possible to "select same" or "select by attribute" feature to select objects using the "old" definition and then do reassignment. As for document palettes and global swatches, existing color definitions and names and assignments are retained so the UI does not notify if there is a conflicting swatch using the same name e.g. in an app-wide palette, or in a "global" document palette that gets autoloaded when creating a new document. But at least existing assignments and parent-child dependencies are retained so it would be possible to manually update the definitions (as per document).

Yes, considering that these file-based assignments are not linked / do not get notified if there are updates, this does not seem to be a practical solution. But because global colors are practically document-wide, there are no other practical options available, either. UPDATE: The biggest argument against use of these kinds of methods in context of Affinity apps is that as both LUTs and Soft Proof based abstract ICCs are applied as layer adjustments, they cause rasterization of vector based exports (e.g. to PDF, EPS and SVG) and would therefore be useless in workflows where vector format needs to be retained. This does not happen when these adjustments are applied on vector objects (shapes) in Photoshop and exported to PDF (even when disabling PS editing capabilities and producing standard PDFs). My advise would be just defining an app color palette (and copy it to be available for all three apps, which in itself is quite a nuisance) and make sure color assignments are truly made (links highlighted) -- at least on macOS, updating the assignment highlight has been buggy for a long time so just to make sure that assignments are really applied can be tedious. But as long as app palette swatches remain unchanged, the assignment links stay highlighted, and lose the highlight if there is a conflict with the current definition. In Publisher and Designer, "select same" feature would allow updating obsolete fills with the the current definition. Copy pasting across apps and documents (and retaining swatch assignments) would be possible, as well. Features related to truly global swatches (like child tints and overprinting) would not be available for such assignments, of course, so app palettes have only very limited use. The limitations of Affinity palettes is further stressed in SVG workflows as it seems that (named) swatch assignments cannot be used, at all, as style or class definitions, so their global change effectively would not be possible in produced files, either.

Abstract ICCs can be applied as per layer so basically limited even object-wise. As ICCs are external files, it would be possible to have a global effect on all documents where the same ICC is applied, if the ICC file is edited or replaced. I have tested this in PS where I can e.g. create s specific color in LAB, apply an adjustment layer that changes the color in a specific way (using e.g. HS, Curves or Levels adjustment), then export the effect as a LAB .icc and use that as per layer via PS Color Lookup adjustment, and have exactly identical color transformation that was achieved with adjustments. In Affinity apps it would basically be possible to use Soft Proof adjustment layer-wise, but the problem is that the abstract ICCs that I have created from PS do not behave identically as when applied as an abstract profile within PS (even if the demo abstract ICCs that come with PS and macOS do). But LUTs that PS creates at the same export procedure DO behave identically in both apps and produce the expected transformation, and LUTs are also external files. The effect of LUTs can also be limited to single layers (objects), so it would seem that it is possible to use them for the kinds of purposes described here. Whether it is practical depends on workflows one is accustomed to, and working with LUTs and abstract ICCs is admittedly very different from palette-based global assignments and color transformations that can be achieved by color groups/styles based mappings in apps like Illustrator or CorelDRAW. But as these kinds of methods are not available in Affinity apps where not even document color palette creation (with auto-assignments) and automatic maintenance is supported and where existing assignments are so easily lost and poorly translatable across documents, the alternative methods might be at least worth a look. LUTs are available as a layer adjustment in all three apps but it seems that they can be created only in Affinity Photo and Publisher Photo Persona. Also, it seems that the kinds of adjustments included in export are limited (e.g., I have have not been able to export effect of an HSL layer to a LUT file EDIT: I just retried and now it worked without problems so I might just have done something wrong on my first try). UPDATE: I just tested this and unfortunately a LUT file is not linked so the changes made to the file will not be automatically updated in objects where a LUT is applied. What a bummer. Abstract ICCs probably would be but at the moment they do not behave reliably in Affinity apps, and also cannot be created with Affinity apps. UPDATE2: It is the same in PS, too, so even if the linked LUT or abstract ICC file changes, it will not be automatically updated unless reapplied (which is in itself a task that can be done because full link to source is displayed, and if files are placed in default folders, simply just selecting the same LUT or abstact ICC will reapply the effect). In a way this is reasonable, but there is e.g. no notification of an outdated link (updated LUT or profile).

Not just theoretically, because it could be done with abstract ICCs that are based on Lab color definitions. Any one color value can be mapped to another with a LUT, OS and device independently. I am not saying that it is practical at the moment, but possible. Also, color groups/styles in AI and CorelDRAW would allow complex app-specific color mappings and the kind of design OP is looking for. Affinity apps are very poor in these kinds of workflows.

Creating an app palette would allow creating an app-specific (e.g., related to Publisher only) palette with (named) color definitions, and assignments that stay when a document is closed and reopened. The app palette can also be edited and edited swatches will be available app-wide in all documents; changes to definitions of app swatches would be shown by losing the assignment link to an edited swatch (that is, existing assignments will never be updated with a changed definition). This is not the same as a document-specific global swatch, the features of which are capability of having an overprint attribute and depending children, and capability of having an editable color definition and have the change reflected in all objects (including depending children) using the assignment. It is also possible to create .csv based custom color libraries and place them in the same folder amongst PANTONE color libraries (.csv files), and specify them as RGB or/and CMYK, and optionally as Spot. Color assignments made by using these swatches, too, will be retained when the document is closed and reopened (and will lose an assignment link if changes are made to the color definitions). These swatches would be different from the ones of an app palette in that they cannot be edited within an Affinity app, yet appear as global swatches with saved custom names, and accordingly show as names swatches on the Tint view of the Color panel (which is also their default view, similarly that of global swatches). The swatch names could be used when adding these colors into a document palette (and optionally making them true global swatches capable of having overprint attribute and child tints). These kinds of custom libraries would also be automatically available for all three Affinity apps, but I think they would be lost whenever apps are updated, even if used with an .EXE based installation (that is, in a folder which would remain unchanged at program update), so backup copies would need to be saved so that the definition files can be copied back to PANTONE library folder after an update. I have not tested whether custom .csv libraries could work in context of Microsoft Store based installations, nor have I tested this on macOS where these files would need to be placed in the app container when using Affinity store based versions. I have no idea whether this could work with Apple Store purchased versions, at all, but on macOS it is clear that these kinds of custom files cannot survive an app update, and that the changes need to be made for each of the three apps -- so probably not worth the trouble. EDIT: I remembered incorrectly the placement of PANTONE libraries on Windows so instead of using Common folder for all three apps, they are placed in app-specific folders (similarly as on macOS, in app-specific packages). It is good to understand that if these kinds of "global" swatches are used to create true document-based global swatches, the link to the original swatch definition is lost and there is no way to see whether the definition of underlying original color has changed. Personally I do not see problem here as there should also be a way to protect a document-based color definitions from such changes. The point of this post was just to remind that there are ways to have user-defined color swatches automatically available for Affinity apps; whether they need to be used as document-wide global colors (with features like overprinting, editability and depending child tints), is up to the user,, but if not, the original swatch assignments are permanent (or perhaps it is more appropriate to say "permanentish" -- Affinity color assignments are confusing and kind of feeble, very easily lost).

An example would be nice! In my rather superficial and schematic tests PDF/X-4 files placed for passthrough generally behave well in a sense that they are not rasterized and their native colors are passed through when exported from an Affinity app (disregarding the app that initially created these files). On the other hand, I have noticed that multiple PDFs (including PDF/X-4, and ones created solely by Affinity apps) do not seem to interact expectedly with each other e.g. in Adobe Acrobat Output Preview or Packzview, meaning e.g. that overprint and blend mode attributes are not correctly rendered nor calculated, even if the attributes themselves appear to be exported. This means that the actual effects on paper of complex jobs placed on top of each other or on colored background are utterly hard if not impossible to predict. RIPped proofs (if not printed ones) would be the only way to ensure expected output. Attached are PDF/X-4 exports made by Affinity Publisher 2.4.0 and InDesign CS6 using the same components, and only the export created by InDesign shows effects of interactions of all involved files when using tools like Adobe Acrobat Pro 2020 and Packzview. multiplepdfx4_apub.pdf multiplepdfx4_id.pdf

In that case I do not understand what same or exact size (on different devices) means (assuming that your image really has the same amount of pixels). 1 px measures different width and height depending on the device, e.g., as shown on my post, I can have my laptop screen filled with pixels in range of 800 x 600px => 3840 x 2400px (+/- effect of scaling) so the size of the image will vary while having it zoomed at 100% level all the time.

I do not think that there is a realistic way to control that. There are many factors that affect the actual width a specific amount of pixels measure on a computer display: ...and the ultimate variable is the user and their preferences: dpirelativity.mp4