Publisher v2.0.4 ; export using PDF/X-1a:2003 ; max ink control ?

[laurent32]

 Is there a way to easily have control over the max ink parameter ?

Or is there a strategy included in the export procedure when using PDF/X-1a:2003 (mostly dedicated to CMJK printing) ?

[loukash]

Isn't it controlled by the ICC profile?
Like ISO Coated 300 which – as the name suggests – limits total ink to 300 %.

[laurent32]

I need to learn more about it…

We often apply profile because we're asked to… without knowing all about them…

Max ink parameter is very important…

I think @lacerto has knowledge to share here…

[lacerto]

9 hours ago, laurent32 said:

Max ink parameter is very important…

Yes, and the TAC limit basically works when converting RGB content and placed CMYK content that has embedded profiles conflicting with the CMYK target profile and is not set to pass through (e.g. AI files with embedded CMYK profiles). Notice here the difference to Adobe InDesign, which by default always discards embedded CMYK profiles and just passes through the original CMYK color values.

Basically the ink limit is applied based on hosting file's ICC whenever the color values need to be recalculated, whether the affected objects will be in vector or raster format, or become rasterized during the process.

This can get really complex, since PDFs placed to be passed through will not have their colors affected, unless there is a "compatibility conflict" (= Affinity thing) and the affected files will be rasterized. Also, overprint status of objects in AI files will be ignored, and in version 2 apps placed AI files will always be rasterized (a bug, most probably).

Because of the complexity, it is best to see that native objects defined in CMYK are simply just within the recommended TAC (since native objects, when exported using the document CMYK color profile, will not be affected by the TAC limit), and that placed CMYK files do not have excess ink usage (as files that get passed through would not be affected), so in practice only native RGB objects and placed RGB files (primarily raster images) will be affected.

Here are two demo PDFs using ISO Coated 300 v2 and ISO Newspaper profiles, where the second page has a conflicting CMYK AI file. The first page has CMYK defined objects demonstrating how ICC based TAC limit does not affect native CMYK color definitions. The bottom circle is in RGB 0, 0, 0 black and when converted shows the ink limit of the profile. The second page is partially a mess because the overprint status of placed objects is lost, but the page demonstrates that the hosting file's ICC will limit the maximum ink usage of files that have conflicting ICC embedded (so the host file with ISO Newspaper ICC will limit ink usage of placed ISO Coated 300. In both situations colors of the second page are translated because of the profile conflict. 

isocoated_300v2_tacdemo_v01.pdf

isonewspaper_tacdemo_v01.pdf

[laurent32]

On 2/25/2023 at 6:18 PM, lacerto said:

Yes, and the TAC limit basically works when converting RGB content and placed CMYK content that has embedded profiles conflicting with the CMYK target profile and is not set to pass through (e.g. AI files with embedded CMYK profiles). Notice here the difference to Adobe InDesign, which by default always discards embedded CMYK profiles and just passes through the original CMYK color values.

Basically the ink limit is applied based on hosting file's ICC whenever the color values need to be recalculated, whether the affected objects will be in vector or raster format, or become rasterized during the process.

This can get really complex, since PDFs placed to be passed through will not have their colors affected, unless there is a "compatibility conflict" (= Affinity thing) and the affected files will be rasterized. Also, overprint status of objects in AI files will be ignored, and in version 2 apps placed AI files will always be rasterized (a bug, most probably).

Because of the complexity, it is best to see that native objects defined in CMYK are simply just within the recommended TAC (since native objects, when exported using the document CMYK color profile, will not be affected by the TAC limit), and that placed CMYK files do not have excess ink usage (as files that get passed through would not be affected), so in practice only native RGB objects and placed RGB files (primarily raster images) will be affected.

Here are two demo PDFs using ISO Coated 300 v2 and ISO Newspaper profiles, where the second page has a conflicting CMYK AI file. The first page has CMYK defined objects demonstrating how ICC based TAC limit does not affect native CMYK color definitions. The bottom circle is in RGB 0, 0, 0 black and when converted shows the ink limit of the profile. The second page is partially a mess because the overprint status of placed objects is lost, but the page demonstrates that the hosting file's ICC will limit the maximum ink usage of files that have conflicting ICC embedded (so the host file with ISO Newspaper ICC will limit ink usage of placed ISO Coated 300. In both situations colors of the second page are translated because of the profile conflict. 

isocoated_300v2_tacdemo_v01.pdf 26.87 kB · 5 downloads

isonewspaper_tacdemo_v01.pdf 26.86 kB · 5 downloads

Thanks @lacerto, I'll need to read carefully, things are getting very complex with all the possibilities we have…

Knowing that I'm exporting to PDF/X-1a:2003, using CMYK format document (apub) with undefined color profile yet, would you say :

- I can use RGB files with undefined color profiles ?

- I can use RGB files with defined color profiles that would match the color profile I would set to the apub document ?

I prefer to work with RGB files because because 40% of my work is for print and 60% is for web…

My print goes to rotary printing (45g/m2 paper) ; what color profile for the apub document would you suggest ?

- Just to be safe, I generally convert PDF to RGB pictures before printing, would you not do the same ?

[lacerto]

On 3/2/2023 at 6:06 PM, laurent32 said:

Knowing that I'm exporting to PDF/X-1a:2003, using CMYK format document (apub) with undefined color profile yet, would you say :

- I can use RGB files with undefined color profiles ?

- I can use RGB files with defined color profiles that would match the color profile I would set to the apub document ?

The inner workings of color management are not easy to describe, so seemingly simple questions like ones related to ink control often require a longish answer to become answered at any depth (or at all). Some of what is said below has been mentioned in another recent post I made on this forum related to changing a CMYK profile while keeping existing color values, and in numerous posts made earlier both by me and by other users. Apologies for the repetition and wordiness, but here goes:

When you create a publication in RGB or CMYK color mode, you always have both RGB and CMYK profiles assigned for the document at its creation time. Whatever color mode you choose for your publication, you will be suggested the default color profile for that color mode and given a list of profiles for the chosen mode installed on your system. The defaults in Affinity apps are sRGB for RGB documents and US Web Coated v2 for CMYK (just to mention these two color modes). The user can change the defaults via Preferences > Color. The latent color modes (e.g., CMYK if you create an RGB document, and RGB if you create a CMYK document) will be assigned to a new document based on these settings (and called as global or working color profiles).

You can subsequently change the latent secondary color profiles by switching to desired color mode (e.g., in Publisher and Designer, using File > Document Setup > Color), selecting the desired profile and choosing "Assign" to keep the current color values unchanged (note however that switching between the modes causes conversion of (Pixel) layers, so switching between document color modes can normally be done without problems only in Publisher and Designer where raw pixel content is typically not used. You could then switch back to former principal color mode, if preferred, but whenever you export to secondary color spaces, the underlying profiles determine how the colors will (by default) be converted at export time, and how their values are displayed when you switch the color model in the Color panel while having the lock turned on (which is the default setting). 

If your principal target is CMYK and you do not yet know the exact color profile, I'd choose CMYK as the document color mode and, as the profile, something close to the final target, e.g. if you already know that the job will be printed on coated, uncoated or newspaper stock, choose something like ISO Coated v2/US Web Coated v2, Uncoated Fogra 29/US Web Uncoated v2, ISO Newspaper/US Newsprint as the CMYK profile. As the RGB profile, I would choose sRGB (you could then place RGB files without a profile that would be assigned with the sRGB profile, or RGB files with wider color gamut having their profiles embedded).

For RGB files the profile based TAC limit would automatically be applied when exporting to CMYK. Within Affinity apps, native RGB objects like vector shapes and text are always converted whenever exporting to CMYK formats (even when using PDF versions that do not require it; this is a clear difference to InDesign). Whether placed RGB images (most importantly raster images) will be converted, depends on the export settings but e.g. PDF/X.1a:2003 will always convert RGB images to CMYK, so the total amount of ink could be checked with e.g. Adobe Acrobat Pro, or by opening the PDF in an Affinity app, whenever using export methods that create pure device-CMYK output. Other PDF/X-based export methods would by default leave RGB images in RGB color mode [but if I remember correctly, in Affinity apps PDF/X-3 will convert image color spaces to CMYK, even if not necessary] and would just include necessary ICC information so that the separation can later be made on RIP by the printer. Using PDF tools like Adobe Acrobat Pro it would be possible to check the TAC that would be applied with the target CMYK profile.

For placed CMYK files, and native objects defined in CMYK, working with indeterminate (non-final) CMYK profile would be more problematic, since when you finally know the profile and need to prepare the production PDF with correct specs, you'd need to either convert existing CMYK values according to the new CMYK profile -- which always also causes K-only based black color values to change to four-color values, but also in losing swatch assignments, so post-conversion tasks would need to be done like changing former K-only parts back to K-only based. But the conversion would also apply TAC limit and automatically take care of excessive ink usage. If the current and final CMYK target do not differ much, it would be fine to just assign the new profile (via File > Document Setup > Color), which would keep the existing color values, and then just manually adjust some key colors if necessary and ensure that there is no excessive ink usage.

As for placed CMYK files with no embedded ICC profiles (which would e.g. include EPS files), the situation would be more problematic, since reassigning a new CMYK profile does not auto-tag placed files and reassign them with the final CMYK profile so when exporting, the original CMYK values of these files would change (including K-only based definitions, which would certainly be unwanted). The assigned ICC profiles of these files would need to be updated by first changing the global working CMYK profile using Preferences > Color to the required project specific CMYK profile, and then physically replacing these files (removing them from the canvas and placing them again) -- in version 1 files updating could be done by "replacing" the files via Resource Manager while still keeping the files placed on canvas. A trick where linked source folder is renamed and the document is then reopened, letting the app to re-read linked files in their new location at document open time, would probably help automating the profile update process. But because of the complexity of reassignment, it is best to avoid placing CMYK images in publications, at all, if the final target is not known and it is likely that the default CMYK profile needs to be changed. As for CMYK files with embedded profiles, they should be changed in their source apps to avoid "inadvertent" conversion of CMYK values when producing the final PDF exports.

This is precisely why InDesign by default discards embedded CMYK profiles of placed content and just passes through original CMYK values -- one would need to see much trouble and image-based manual tweaking to get InDesign behave like Affinity apps now do in regards of handling of placed CMYK content. As it is, the best way to avoid these problems is to avoid placing CMYK content, and when necessary (e.g., when a publication contains illustrations or charts where K-only based values need to be specified or retained) (re)import them after the final CMYK profile is known. Because of complexity of reassigning images with no embedded CMYK profiles, it would be best to use image formats that allow embedding ICC profiles. Having CMYK content placed in PDF files that can be passed through (basically ignoring profiles) would be otherwise the best method, but then there are complexities involved in Affinity PDF compatibility rules.

It is unfortunate that the situation has not improved along version 2 apps (but rather got even worse in some respects), so we can only hope that color management related features and especially PDF production will improve in the future. Much of what is said above does not probably apply to most users of Affinity apps, though. The complexity related to production primarily affects projects where lots of 3rd party CMYK content needs to be placed and the files either contain mixed or conflicting ICC profiles as regards the target CMYK profile (i.e., profiles that InDesign just discards and uses native CMYK values), or do not contain profile at all, and the import-time assigned working CMYK profile would conflict with the final CMYK target. For these kinds of workflows, using a dedicated prepress tool for PDF post-processing would probably be a wise investment.

Many users, and especially ones who print just their own content, can safely use workflow where all placed content is in RGB color mode and CMYK definitions are only used in text, which is defined as K100 (CMY 0), or created with in-app tools without needing to import anything. Often these kinds of jobs are also printed on self-publishing print shops which specifically request either Device-CMYK transparency flattened content produced with methods like PDF/X-1a (and who would simply just discard all embedded profiles if included), or who want to have plain RGB content (including text, that is defined as RGB 0, 0, 0). When using these kinds of workflows, there is generally no need to worry about TAC limits and ink control. If there is really need to include a specific CMYK profile and it differs from the currently used, it can normally be done just by using File > Document Setup > Color and then Assign the correct CMYK profile. This would keep the existing color values (specifically K100 of text) and apply the requested TAC at export time.