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

It seems my compliments to macOS version of Excel were premature -- I have US English UI language active in the operating system but Finnish regional settings (including date and number formatting), but my Excel (also using US English UI) just keeps on showing all cell formatting using US English regional settings, even if I have the default editing preference (in Excel) set so that the system group and decimal separator should be used! I have macOS Sonoma 14.2.1 and latest Excel 16.8.3 installed. So it seems that the current macOS version of Excel forces US English formatting according to OS UI (and/or Office 365 UI language), no matter what. On Windows it works in a predictable way even if it requires manual intervention: the formatting you had in your Excel sheet shows as being "custom", but after having been changed to use explicit US English formatting (using Excel Windows version), I could open the file in Publisher so that date and number formatting show correctly.

That's the language (and graphic libraries available to it, including ImageMagick) I would use for the task (especially if raster-based). See e.g. https://github.com/ImageMagick/PythonMagick.

These controls also reduce opacity of enclosed text. To reduce opacity of text frame background fill only, I could not find any other fix than replacing the Outline FX with regular outline attributes. After that, opacity of text frame background fill operates as expected. outlinefx.mp4 As this was an .afdesign file, it may be that the oddity with FX Outline was initially caused by applying stroke attributes (with opacity setting?) in context of Appearance panel, or possibly from attributes used in the shape around which the the outer text was aligned (and the ellipse then lost in Designer), but at one point when I was examining this design I managed to create a central object with text with 100% opacity white as text frame background fill, which still had a good deal of transparency, which I could not turn off (the fill could be turned off and then redefined without any change). It did not come from transparency attribute that can be applied using the Transparency Tool. In context of FXs, partial transparency can become from multiple places, some of which are just alternatives (like the controls you mentioned), but in addition to those, color attribute and the layer itself have transparency attributes of their own (blending modes included), as have similar attributes that are available in individual FXs themselves, so it can become quite confusing, even without mixing involvement of multiple apps and tools that are accessible only in them (or sometimes via a Persona). Sometimes also the Fill Opacity setting available in FX Panel is directly interconnected to the Opacity of a Layer panel (but not in this case).

I had another look on this, and now on macOS. There I first changed number formatting to US English style using System Regional settings (from the default Finnish one), and then simply just opened your .XLSX file in Microsoft Excel (latest version). The formatting came correct out of the box, including the date, and surprisingly were not "custom" formats in macOS Excel (which, btw, in many ways seems smarter than its Windows cousin). So what I did was that I just copied the Excel data onto Clipboard, selected all cells in Publisher imported .XLSX file that is otherwise properly formatted, just messing up number formats, and pasted. Alignments come wrong, but it is a simple task to right align required columns, and vertically center align cells. pastefromexcel.mp4 On Windows (using Finnish regional settings, at least), I had to open the .XLSX file in Excel and change number and date formatting that were interpreted as "custom" to standard US formats, and save back. After that, Publisher opened the file correctly (excluding alignments). On Windows, you can also use Clipboard to transfer correctly formatted data via Clipboard (using the default Rich Text Format), but on Windows reformatted .XLSX is read correctly (on macOS it will still be read incorrectly).

Well, it seems it cannot, not at least the test versions that I created from Affinity Photo version 1 and 2, with 5 pixel layers. The default Zip compressed TIFF file additionally showed the active layer with pixel content as corrupt (and no other layers present). LZW and non-compressed TIFFs were shown correctly but the empty layers were not present. And as mentioned, Affinity Photo 1 cannot open TIFF files created from within Affinity Photo 2 with Affinity layers (because they cannot open Affinity Photo 2 files). So the key to the "layer mystery" and why Photopea, indeed, is a solution to share Affinity layers with ANY user (not just Windows!) that have an image editor capable of opening a Photoshop files with layers -- is that Photopea can open native Affinity Photo v1 and v2 files and save them as standard .PSD files with layers that any app supporting PSD import (with layers) can open. So Photopea basically does the job that Affinity Photo should do in the first place! Because Photopea does what it does, one begins to wonder, but hopefully Ivan Kutskir still is (and stays!) independent and just has managed to de-engineer .aphoto format (as he once did with .PSD format before it was partially publicly documented). For more information on Photoshop format and apps that support PSD format, see e.g. https://www.loc.gov/preservation/digital/formats/fdd/fdd000523.shtml.

It seems it has been possible to Adobe developers at least from 2012 (InDesign CS6): importing_custom_formatted_excel.mp4 The clip is from Windows that uses Finnish regional settings with space and comma as group and decimal separator, and as text is interpreted rather than using live formats, needs to be find-replaced to set formats correctly. InDesign would probably read the file correctly if system regional settings were changed and the app restarted. InDesign reads the custom formats meaningfully both from .XLS and .XLSX formats, so I think this is basically just a question of maturity of apps, and level of programming skills.

To stretch this a bit further, the trick when using a custom color font, is to use Lighten blend mode so that an Excel sheet can define 1,000 different colors simply by reading hex definitions. On macOS the color of the actual color component can be previewed but the final color is of course result of blending the three components, so the method requires some training 🙂 a) The data source: b) The data merge setup:

The bug seems to be related specifically to incorrect interpretation of custom formatted data. This is how the currency cells are formatted in the original Excel sheet (at least when opened in Windows Excel by default using Finnish regional settings): When I change this to standard currency formatting with US dollar, and specifying in Excel preferences that custom group and decimal separators (that is, the US comma and dot, instead of Finnish space and comma) should be used: ...and then save the document, and place it in Publisher, I wlll get formatting right: I'd imagine that this works identically on macOS, but have not tested. EDIT: So whenever using an Excel sheet that has different number separators from what the system uses, one can specify in Excel preferences exceptions (the setting is global, so once the reformatted Excel sheet has been saved, the regular system setting based formatting can be returned):

Here is a setup where specific Segou UI Emoji glyphs with different background colors are clipped into (heavily zoomed in into) Arial (and also table cells) and where text gets coloring definition from an Excel sheet, so it is not necessary to use a custom font (self-created). I just created one to make it possible to precisely define a color in source by mixing 10 RGB components.

What do you mean "during" (the color font would be defined in the merge setup and clipped into the actual font that will give the shape) -- so cumbersome, but after it has been done, actual merge should be "smooth" (at least in marketing jargon) 🙂