lacerto

Yes, I agree that it would be appropriate to default the effect color to the document color mode (I guess the app just remembers the last used color model?). The preflight calculator should of course also apply color profile based conversion instead of naive conversion RGB value to CMYK, and should naturally consider the effect of opacity and blend mode. As it is now, the warning is, as demonstrated, often given for an RGB based effect color using an opacity setting, and even if there is no overlapping (that is, when the color is not blended with underlying colors), but not when the color (even with a K value) actually causes exceeding of the TAC limit because of the blending effect and underlying colors.

My experience is that there will always be intermediate tones besides those specified in the Gradient Map adjustment. The stray tones can especially be seen when using color images. In context of black and white images this does not normally show, so if exact number of levels is not important (and it often is not, as images are normally not viewed at pixel level), the shown methods would be fine (though setting up a kind of accurate stepwise gradient is rather tedious). In low-resolution images, sporadic intermediate tones, even grayscale, are of course more easily discernible. intermediatetones.mp4

If you want to have exactly 6 levels then you need to combine the Posterize adjustment with Gradient and Black & White adjustments (the last one being useful when working with a color image). The exact number of levels will then be determined by the Posterize adjustment while the Gradient adjustment determines the color scale. With Black & White adjustment you can determine the brightness level of primaries and how they interact with the defined gradient: exactnumberofshades.mp4 You can use the Histogram to check the number of levels in the image, or create a document palette (note that only max 64 tones/colors will be created). Often it is also necessary to add a solid layer at the bottom of the design (I suppose in situations an image has partial transparencies). If exact number of levels is not required, then the shown methods will produce appearance of decreased levels and are adequate.

I am not sure if Softproof adjustment is something the messes this up for you (at least it should be turned off when you export). But Affinity Publisher is really quite lost when checking effect of effects 🙂 The following demonstrates how it wrongly reports an RGB 0,0,0 shadow with low opacity as excessive ink usage (so just staring at naive conversion of RGB 0, 0, 0, not taking into account the opacity level), while it totally ignores the effect of K99 shadow (not in itself causing excessive ink alarm, but because of having Multiply blend effect, will mix with underlying colors so that the TAC limit is exceeded): effectofeffects.mp4 So, the cause of effective TAC becoming too heavy in your design might be either in leaving Softproof adjustment on when exporting and messing up the colors, or using shadow effects with RGB 0, 0, 0 (becoming four color CMYK when converted) with Multiply effect. You could try if defining the shadow color as something like K99 and lower opacity level makes the job pass within the defined TAC limits.

Make sure that you also have "Look inside placed documents" checked! Note however that this tool does not take into account the effect of blend modes and overprints so the total outcome of an exported file can still exceed the set TAC limit without any warnings displayed.

That is fine, but it is good to know that this does not cover effect of blends and overprints so an exported output can have exceeding coverages not spotted by the preflight calculator.

I think that the repeated questions are typically related to separation preview, while images (and possibly also native elements) are still in RGB color mode. If that kind of tool can also show problems in placed CMYK content (already when it is placed on the canvas and not just in the exported PDF), then all the better. That is, users would like to have a kind of an interactive in-app preflight tool that exists e.g. in InDesign (note that this tool also takes into account effective TAC assisted by things like overprinting and blend modes): properinkcontrol.mp4 In lack of something like that, post-export tools like Adobe Acrobat Pro and callas pdfToolbox, and PackzView (the only one that is free, but with limited availability), are pretty much the only tools that can handle TAC and other preflight related tasks effortlessly and professionally. Everything else that I have seen (including postprocessing of separated inks e.g. with Ghostscript) are rather convoluted workarounds, but of course better than not having anything at all (= dismissals from the printer).

Odd, now that I tried, the macOS version of Publisher (2.4.2 on macOS Sonoma 14.4.1) does have native objects CMYK readings updated after a profile change, so perhaps it was just a temporary (memory related) issue. But for placed images, reopening is still necessary. I tested the profile you referred and it seems to operate correctly: limitingtacmacos.mp4 Color data seems to be very easily affected by memory issues. At some point I experienced problems (on macOS) where I could not get realtime CMYK readings (in Photo Persona accessed Info panel) at all for placed RGB objects, neither for native or placed RGB images.

Have you tried the save, close and reopening trick, as advised by @thomaso. This should result in RGB images being properly assigned with the "new" (currently active) target CMYK profile so that you get correct reading already when using TAC picker or CMYK picker, but most importantly, when you actually export to CMYK PDF.

Sorry, no. I am rather lazy reporting and following bug reports... It was very useful to know that just saving, closing and opening again does the required refresh! I had assumed that this happens at export time at latest, if at all. Closing and reopening might in current versions also work in many other related situations I have experienced where placed images have not been updated. In some situations images can be updated "in-place" by using the "not-found" trick (renaming the folder where linked images are located and updating with Resource Manager at document open time). But in some situation it has been necessary to physically remove a placed file and place it again to have color or profile related information updated. The macOS versions have generally many issues related to having color date updated (e.g. in the Color panel), but typically these errors have been just kind of "lazy refresh" issues (like having up-to-date reading when deselecting and reselecting a native object).

Phew, that's at least a very good workaround. I had not noticed this!

If your blacks are RGBs, basically just applying (assigning) an appropriate color profile would limit the total ink to a specific maximum value. If the max TAC is as low as 260% you appear to have uncoated (or very lightly coated) media. Choosing e.g. US Web Uncoated would limit the total ink to 251% and keep the job neutral, not making it diluted or desaturated but basically just limiting excessive ink in darkest areas. If your colors are already in CMYK, you may consider converting the job (color definitions) to RGB, and then choose an appropriate profile in context of the press conditions and media that limits the total area coverage and manages ink usage with proper methods (like applying undercolor removal and gray color replacement curves). (Converting from CMYK to CMYK is normally not a good idea but if there are clear spots with excessive ink you might get away with it by applying manual tone control.) But my point is: by using an appropriate profile you will get balanced (non-color cast) properly managed tones and will get excessive ink usage automatically limited. Playing with soft proof and manual tone controls can be useful in RGB based output workflows (that expect the print file to be in RGB color mode), but typically not when using commercial press. See below how changing from an app. max 330% TAC Euroscale Coated profile to US Web Uncoated effectively limits the inks to max 250%. limitingtac.mp4 Note how Affinity apps appear to require refreshing of placed RGB images before ink limit of a changed profile takes effect (something that does not happen when using e.g. InDesign, so there both early and export-time profile reassignments are correctly applied for RGB objects when exporting to PDF) -- I have a feeling that this did not happen earlier within Affinity apps, either. It also seems that the macOS versions are even more broken as there (at least with native chip on macOS Sonoma 14.24.1 and latest Publisher 2.4.2) assigning a different CMYK profile does not seem to have effect on conversion of neither native art in RGB color mode (the RGB 0, 0, 0 black rectangle), nor in RGB image, so on macOS profile-based TAC limiting is badly broken. Note that US based profile may not be ideal in European press so you could ask your printer if they have a recommendation for the output profile considering the press conditions and used media. UPDATE: It seems that on macOS the native objects can be "reassigned" (refreshed) at least by selecting them and switching the color model within the Color panel (without making color conversion). On Windows "refreshing" is not needed (and should not be required on macOS, either). UPDATE2: Sorry, I read your initial message a bit carelessly and thought that TAC 260 was the goal, instead of TAC 280. You can come pretty close with e.g. Uncoated_Fogra47L_ViGC_300.icc, which has 274% as the TAC.

There are surprisingly many PDF/A formats, for PDF/A3 alone three sub types. I have very poor understanding of differences between the sub types but when I had a look on reasons why Apple Preview created PDF/A file failed in Adobe Acrobat, I got the following: So things related to metadata, and encoding (mapping) of font containing unnamed glyphs (the font that I used was Arial, which has multiple character sets). PDF/X-Change, on the other hand, creates a report of what is done when converting to PDF/A, and shows the following, when it creates a PDF/A-3a file from the same PDF/X-1a:2003 based test file that I used: What it also does is that it embeds font sub sets, which means that it does not include all various Arial character sets and glyphs which the document does not use, and my guess is that this (if not done) could be the primary cause for not passing compliance tests. PDF/A measures are basically ones that are done for compatibility and to improve archiving, but as mentioned, I have no clue of details and why there are so many sub types (or which sub type is most common and "most compatible")..

You can convert a PDF file created by an Affinity app to PDF/A format. On Windows, you can use PDF-XChange Lite (free version) and determine which kind of a PDF/A format the file will be saved in: PDF-XChange is unfortunately available for Windows only. MacOS Preview can save a previewed standard PDF as PDF/A file, but when I tried to verify the format in Adobe Acrobat Pro, the Preview saved file (formally PDF/A-2b) failed to pass the compliance test. PDF-XChange created version passed all compliance tests. I do not know if there are free tools for macOS (or online) that can convert a PDF to specific PDF/A format (there are commercial solutions available also on macOS, e.g. PDF Studio, that can do this and pass compliance tests).

As @walt.farrell suggested, holding down the Alt/Option key while using the Text tool (either Frame or Artistic), lets you alternate between overlapping text layers (the focus changes on each time clicked so if you want to select text, do it when you Alt+click the correct frame). If the Move tool is used, instead, the selection will alter between all overlapping layers (not just text layers).