Exporting K100 text

[paleolith]

I'm designing and AfPub doc in RGB, since I want to export for the web as well as to print. I checked with my printer for profile (U.S. Web Coated SWOP V2) and what black to use -- they recommend (no surprise) K100 for text, Rich Black for other black areas.

How should I be set up so that my RGB export has R0 G0 B0 text, and my CMYK export has C0 M0 Y0 K100 text, while doing normal conversion for non-text?

If I'm better off just converting to CMYK and working there, that's probably OK. I have compared my RGB and CMYK exports (from my RGB AfPub doc) and see very little difference, perhapsin large part because the color in my document is mostly photos, not synthetic. The only object that looks noticeably different is one of those 5-gallon orange coolers.

[lacerto]

41 minutes ago, paleolith said:

How should I be set up so that my RGB export has R0 G0 B0 text, and my CMYK export has C0 M0 Y0 K100 text, while doing normal conversion for non-text?

You basically cannot, if your job also has color content. You could have RGB 0, 0, 0 black exported to RGB black for digital purpose and K100 (actually gray 0) for press, but then you'd need to export the press job using grayscale mode, and that would not work with native color RGB objects (which would be in gray). There is no equivalent of "[Black]" swatch of InDesign that exports as K100 in press exports, and RGB 0, 0, 0 in digital exports so if you want to have that, you need to convert text black for both purposes (which is not necessarily a big job since you can use e.g. Find / Replace to convert all K100 text to RGB 0,0,0, or vice versa, in one go; or use text styles, which, though, is less reliable way to do it).

As you are going to export to press, too, I would choose CMYK as the primary color mode and define text as K100, and all native art in RGB (that is perfectly possible, since Publisher will keep your RGB definitions without converting them to RGB (just remember to have lock turned on in the Color panel if you use that to define object colors). You would naturally also place all your images in RGB color mode. When making the final digital export, you would then convert K-100 black to RGB 0, 0, 0.

There are benefits of primarily using CMYK color mode, e.g., to have the "K-Only" button available, which would let you have your grayscale images automatically processed as grayscale (or control the conversion/non-conversion manually for each image) when exporting to CMYK, instead of being converted (typically inadvertently) to four-color black. Keeping the job as CMYK will also make your press-related exports more relaxed, considering the need to have the optimum CMYK document target profile applied, as you would not need to make document color mode swaps just to make the right CMYK color profile assignment.

[paleolith]

Thanks, this is very helpful guidance. It definitely seems that going CMYK is right for me, given how little seems to get lost in translation in my doc.

I've been careful to keep my font color strictly cascading from Base, so I should be able to swap between K100 and RGB 0 0 0 successfully.

When you refer to "native art", do you mean generated, such as for example filling a rectangle with a specific RGB value, which might be outside the CMYK gamut? As opposed to photos or scans? I have only a few generated objects, all rectangles all filled with the same color.

Edward

[lacerto]

1 hour ago, paleolith said:

When you refer to "native art", do you mean generated, such as for example filling a rectangle with a specific RGB value, which might be outside the CMYK gamut?

Yes, basically objects (shapes, text) where you define color values (and model) with internal tools. Whatever color model you use to define a color value for a fill/stroke, gradient stop etc. attribute for these objects, the definition is saved as a native value and used when you export so that the initial gamut is fully exploited. Often design principle might actually be opposite, to produce output that is visually coherent both on digital and print media. 

[Martyn Folkes]

On 2/29/2024 at 1:40 AM, lacerto said:

use e.g. Find / Replace to convert all K100 text to RGB 0,0,0, or vice versa, in one go; or use text styles, which, though, is less reliable way to do it

@lacerto, why do you say styles are a less reliable way to do it?

[lacerto]

2 hours ago, Martyn Folkes said:

@lacerto, why do you say styles are a less reliable way to do it?

Sometimes there are manual overrides that do not get easily changed, and forcing a style definition can have consequences where you lose one attribute when forcing another. Affinity apps especially typically need to have local formatting secured with character styles because simply just reapplying the same style might cause losing local formatting. If the task is easy enough (look for text with RGB 0,0,0 fill and replace it with CMYK 0,0,0,100, or vice versa), it is basically a one-click job to have it done. If there are swatch assignments, it could easily be done that way, too (and if assignments are global, this would probably handle tinted blacks, as well).

But I have not tested this much in practice so you might well get good results with styles. Select same and select all by type feature (available in 2.x version of Publisher) can also be very useful in jobs like this.

[Martyn Folkes]

I use styles based on Base (including the character styles) which has the colour set to K100. I have also set the text defaults to K100. Hopefully that would mean that any manual overrides would also adopt K100. I try not to use local or manual overrides, but I understand that these can creep in sometimes, and this could possibly change the colour.

So I suppose it would make sense to do a Find and Replace as a last step before export.