Can you do a "Global" soft proof in Publisher?

[Ldina]

I know you can add a Soft Proof Layer Adjustment to a specific page in Publisher. That's fine for a single spread or a small document.

But, what if you have a document that has 10, 20 or 50 pages? Do you have to add that same exact soft proof adjustment layer to every single page individually in order to soft proof the entire document? That would be a waste of time and effort, since the entire document will presumably be printed using the same output device, paper, ink and profile.

Is there a way to add a "single" Soft Proof Adjustment Layer that soft proofs all pages in the document? 

And for clarification, I assume each placed or embedded element in the Publisher document (jpg, png, psd, ai, afdesign, etc) will have its own profile and will be converted using its embedded color space to the destinations color space. For example, there may be different linked images in the Publisher file, each with different embedded profiles...e.g., Adobe RGB, sRGB, grayscale, various flavors of CMYK, etc. Each element needs to be converted using its embedded profile as the source, to the destinations profile using the specified rendering intent. I'm also assuming all elements created inside the Publisher document itself will use the document's color space as the source, right?

Thanks for any feedback. 

 

[v_kyr]

See related:

 

[Ldina]

v_kyr,

Thanks for the link, which didn’t show up in my search. Interesting discussion.

Seem to me Publisher needs a simple Global soft proof setup for the entire document instead of a convoluted workaround prone to error or layer stacking order, grouping, etc. It’s so fast and easy with InDesign. Also, with InDesign, you can assign separate color spaces and rendering intents to individual placed images so each image is converted to the destination print space optimally and looks it’s best when printed. One image may look best using perceptual intent, and another with Relative Colorimetric. Without these capabilities, one needs to convert all images to the final destination print space in the original authoring application before placing the image in Publisher. That”s a time consuming, inefficient way to work and makes it difficult to repurpose a design for different output spaces. What if the client decides to change printers late in the game and and that printer requires a different profile?

Serif needs to rethink this, in my opinion. 

[thomaso]

1 hour ago, Ldina said:

One image may look best using perceptual intent, and another with Relative Colorimetric.

This reminds me to another (long) thread about soft proof issues or limitations. Maybe this post of Dan (Serif) is a good place to see if it feels relevant for you:

[loukash]

8 hours ago, Ldina said:

Is there a way to add a "single" Soft Proof Adjustment Layer that soft proofs all pages in the document? 

There is a way via Master pages:

 

Caveat:

To be truly a global effect – as in "one click on, one click off" – it seems that all content must be in the child master page(s) of the Soft Proof Master. Then you can globally turn it on an off from any page you're currently at.
Logically, individual content placed directly on top level of any individual page won't be affected globally, as Affinity layers are hierarchical. 

The "self-grouped" Soft proof on a separate master page layer – as outlined in the other thread – still needs to be turned on and off individually for each page. Not sure if it's a bug or a feature.

[lacerto]

What is your purpose of applying a Soft Proof adjustment? I ask this because if your document color space is CMYK and you already have the correct target CMYK profile applied, then what you see is the closest approximation Affinity apps can show of how the printed document will look like (it is like having permanent CMYK target soft proof turned on in Adobe apps, except that you would not be able to have a realistic preview of spot colors or even CMYK colors that are out of sRGB color gamut). If you have an RGB document, the CMYK profile that you pick in the Soft Proof adjustment gives a less accurate simulation. On the other hand, if your goal is to have a preview on how a CMYK document with RGB images linked/embedded or containing RGB color definitions will look like in (s)RGB or different CMYK color space would look like, then you could not use Soft Proof adjustment for this, and you would get best approximation by producing PDF documents in required color modes and viewing them with the correct simulation profile.

If you do not have pixel layers in your Publisher document, you could also switch between different color modes (RGB and CMYK), or assign different color profiles (e.g. coated, uncoated and newspaper ICCs) within the same color mode, without causing change of color values (just causing change in visual appearance of colors).

Personally I can see only one good use for Soft Proof adjustment within Affinity apps, and that would be when using an (s)RGB document and designing a color scheme that should have reasonably similar visual outlook both in RGB and CMYK (or at least being able to quickly see the difference), or when using any color document mode and wanting to preview the colors in grayscale (e.g. to see if there is enough contrast between color definitions, and adjust the values if needed). 

[Ldina]

@loutish, thanks for your post. I need some time to review what you have suggested and will give it a try.

@lacerto, I wasn't clear on everything you shared, so my response may miss what you were trying to get across. Setting up the Publisher document in the final CMYK press color space is an "early binding" workflow. In this workflow, all images, illustrations, etc, are typically converted to this final CMYK ICC profile, using the ideal rendering intent for each individual image, before placing into Publisher. That works fine as long as the final print space remains the fixed. What if a printer hasn't yet been selected? What CMYK profile do you use? What if the 2nd press run is sent to a completely different printer who requests a completely different press profile? I often use the same page layout file for multiple outputs...printing presses, sRGB PDF files, wider gamut RGB spaces for inkjet printing, etc. If I force everything to fit into a smaller CMYK color space from the start, I'm stuck with that smaller gamut, even for RGB output which is capable of a much larger gamut.

Another way of working is a "late binding workflow", where you set up the page layout document with a wider gamut RGB space (for example, Adobe RGB), which preserves more color gamut in native elements and placed files, so the design can be repurposed for multiple output devices. This way, one can place images with multiple color spaces and profiles into Publisher...sRGB, Adobe RGB, ROMM RGB, grayscale, Lab, or even CMYK (though I try to avoid CMYK to CMYK conversions if possible). As long as each placed element's embedded profile is recognized and honored by Publisher, and as long as you can set each item's rendering intent individually inside of Publisher, and as long as Publisher will convert each element using its  parameters, a global soft proof will show you what your design will look like using any output device's ICC profile. When the final output device is determined, THEN I Export to PDF late in the game to the final destination workspace. This insures I get the most accurate color and the widest possible color gamut that particular destination device is able to render. The original Publisher document and all placed images remain in their pristine, wide gamut color space, making it possible to repurpose quickly and easily.  An accurate monitor soft proof requires a wide gamut, well-calibrated monitor, which has a larger gamut than the final output space. That's the way my system is set up and it's the way I work. My press proof simulations (on my monitor and on my inlet printer) are usually a near-perfect match to press output using this workflow in InDesign.

Soft proofing a single image in Affinity Designer or Affinity Photo works fine, and adding a soft proof layer at the top of the layer stack on a single image is no big deal. For a Page Layout program with dozens or hundreds of placed images and illustrations, I believe a different color management strategy is required. In my opinion, Adobe has this right with Indesign. It's flexible, fast, easy and accurate. 

For RGB output ONLY (PDFs for the internet, etc), Publisher works fine for my needs. For press work, I'm not yet convinced Publisher is ready for primetime. I used a late binding workflow, which to me, is more flexible and preferable. 

[Ldina]

@loukash…I was finally able to make the master page soft proofing work, but it took quite some time to figure out how to do it. Your video helped. That’s a step in the right direction.

I wasn’t able to find any way to assign “object level rendering intents” to individual placed images and I’m assuming Publisher doesn’t support that. Some images convert better using perceptual intent and others convert best using colorimetric intent. Without object level rendering intents, one is forced to choose one or another. The only workaround I currently see is to do all the conversions in the authoring application before placing them in Publisher. This is time consuming and enforces an early-binding workflow. 

Thanks again for the video.

[lacerto]

14 hours ago, Ldina said:

Setting up the Publisher document in the final CMYK press color space is an "early binding" workflow.

Not really, you are describing very old workflows. A typical workflow would be placing RGB content (images), and also use RGB color definitions for native objects if desired (e.g. to guarantee wider gamut for digital production). When you work e.g. with InDesign, and choose Press document, you have dual color space and document target color profiles both for RGB and CMYK, and you will see placed content in full color gamut. You are by no means restricted to keep your initial profiles (which you will always by necessity have) but can either assign or convert as needed (and if converting, will have CMYK based swatch colors redefined without loosing current color assignments). So you are by no means "bound", even if every document necessarily has initial target color profiles defined.

Basically the same applies in Affinity apps even if the "secondary color space" (CMYK if you work with an RGB document, and RGB if you work with a CMYK document) is not explicitly chosen as per document (but will be determined by defaults in the Preferences), with the important difference that CMYK mode will restrict your working color gamut. So in Affinity environment there is really a practical difference (even if you can freely switch from CMYK to RGB or vice versa, without causing color conversions, as long as you do not have "Pixel" layers: you typically do not, in Publisher). So if full color gamut is important to your workflows, you might consider working in RGB color mode (note though that you would not get what you want e.g. with spot colors and with Lab color mode; and if you intend to place 16-bit content, will get very large production files).

There are also many caveats in Affinity apps when producing to multiple color spaces, one of them being handling of black (and gray), as Affinity apps do not have the kind of context [Black] that would produce K100 for CMYK color spaces and RGB 0,0,0 for RGB. And as mentioned, using CMYK targets with Soft Proof adjustments does not give as good simulation of the target color space as using the CMYK mode with the appropriate target, and their global use is convoluted. Press, PDF/X-3 and PDF/X-4 modes also do not retain native RGB color definitions, which may or may not be important in pure late binding workflows, so there are things to check (especially making sure that the underlying CMYK color profile is correct as it will be used for all these conversions) when trying to reproduce workflows used with different ecosystems. In Affinity apps PDF/X-based export modes also have serious limitations as regards placed PDF content, so if your production workflow is dependent on either, make sure that you will not have inadvertently rasterized content. Working in RGB color mode also has restrictions related to working with spot colors, e.g. the "K-only" button that can and needs to be applied to correctly apply spot inks and tints -- and regular coloring -- (making RGB and Grayscale images handled as true grayscales) would not be available in RGB color mode.

You should also understand that you cannot assign CMYK color profiles at export time without causing conversion of all CMYK color values (also ones in placed content, unless the values are marked to be passed through, and most importantly, all native K blacks), so there is no late "keep values" option available to be used for making kind of cosmetic target changes to near ICCs at export time (even if you can switch to CMYK mode and then assign a different CMYK profile from the one assigned as the workspace default). Note too that in context of placed content the embedded CMYK profiles are not discarded so if there is a conflict with the (underlying) CMYK color profile, all color values will be converted accordingly (no matter how "late").

Despite of what is mentioned above, you could probably produce the kind of pure RGB workflow based "late binding" documents that will get converted only on RIP, but it won't be smooth as choices you need to make when exporting PDFs differ from ones you would make in other page layout apps, and documentation will not help you. So Adobe Acrobat Pro or another prepress tool will be needed. At least you should be sure to get a ripped proof. 

[thomaso]

24 minutes ago, lacerto said:

A typical workflow would be placing RGB content (images), and also use RGB color definitions for native objects if desired

Does this work in Affinity? I am not able to export an RGB .afpub with some 100 M, 100 C, 100 K elements correctly as PDF/X-4. – How would an RGB .afpub be used if I need to maintain a client's corporate 100 M for instance or want to achieve a print with 2-3 inks only?

rgb > cmyk.pdf

[lacerto]

44 minutes ago, thomaso said:

Does this work in Affinity? I am not able to export an RGB .afpub with some 100 M, 100 C, 100 K elements correctly as PDF/X-4. – How would an RGB .afpub be used if I need to maintain a client's corporate 100 M for instance or want to achieve a print with 2-3 inks only?

What I mean here is that you are free to define your native objects in RGB, and when produced to digital documents (to RGB), these values will be retained for richer colors. I also mention that in Affinity environment native RGB definitions are not necessarily retained even if they are wanted to be retained (as by specs when exporting to PDF/X-3 or PDF/X-4, which is what happens if you export from InDesign). 

I am not sure that I understood what you mean here or how you produced the PDF you attached. You should be able to use CMYK definitions in an RGB document and then export to PDF/X-4, and these values will be retained. You just need to take care when exporting to PDF/X-4 that you specify CMYK as the export color space (since you cannot avoid Affinity apps from converting native colors to CMYK anyway), so if you leave it unspecified or used the document color space (document color mode being RGB), Affinity apps will use the factory default US Web Coated, which results in kinds of converted color values shown in your document. Your document however shows PSO Coated v3 so something else has happened in your export (could it be macOS related; I tested this now only on Windows and with v.2.0.3).

EDIT: Perhaps you specified CMYK, and then also specified the profile? The profile must match your document CMYK target: ensure that it is what you want by switching to CMYK and seeing that it is PSO Coated v3. Then cancel and make sure that you specify CMYK AND document color profile, and you should be good.

Attached is a PDF/X-4 document that shows pure C, M, Y and K and that has been created from an RGB Publisher document and that will show the underlying CMYK color profile as output intent when viewed in Adobe Acrobat Pro.

cmyktest_pdfx4.pdf

[thomaso]

18 minutes ago, lacerto said:

Your document however shows PSO Coated v3 so something else has happened in your export (…)

EDIT: Perhaps you specified CMYK, and then also specified the profile?

Yes, the .afpub was rgb > cmyk.afpub
• set to sRGB,
• colours as CMYK (+ 1 Pantone),
• exported as X-4
• with CMYK + PSO Coated v3.

Good to see it works in your PDF. – I assume the different output intent doesn't cause my conversion issue from RGB, – but what makes the difference? Would you mind to upload your sample as V1 .afpub?

[Ldina]

Thanks for all the helpful posts.

@lacerto...Frankly, my head is swimming at this point, and I have a lot of confusion about Publisher, so maybe the way I am accustomed to working doesn't translate well to this environment. I haven't wrapped my head around the many differences between Affinity and Adobe, especially with Publisher and InDesign and their handling of color management. I'll need to understand it better to find a suitable workflow. I got good, predictable results with InDesign, but it seems I'm comparing apples and oranges, at least to some degree. 

I'll have to mull all this over and see if I can make more sense of it. Anyway, thanks. 

[thomaso]

14 hours ago, lacerto said:

If you do not have pixel layers in your Publisher document, you could also switch between different color modes (RGB and CMYK), or assign different color profiles (e.g. coated, uncoated and newspaper ICCs) within the same color mode, without causing change of color values (just causing change in visual appearance of colors).

@Ldina, for your current soft proof question this hint of @Lacerto may be a helpful 'summary' and easy do use / try. The important part for that version of a non-destructive soft proof workflow is the term "assign", which refers to the "Document Setup". Unfortunately, this window always opens with "Convert" activated, regardless how you have left this window by pressing "OK" before. Once you forgot to press "assign" you can undo the conversion via the Undo History panel.

37 minutes ago, Ldina said:

apples and oranges

Concerning colours there are a few fundamental differences which might not be obvious or may confuse.
For instance …
… the handling of colour swatches, colour palettes, global colours, spot and overprint swatch properties
… the Lock button in the Colours panel,
… the limited abilities with spot colours in layout and export,
… the missing option "preserve colour values" on export,
… the handling of 100 K.

Each of them has various threads in the forum, some in 'Feature Requests', more in 'Questions'.

[lacerto]

16 hours ago, thomaso said:

Would you mind to upload your sample as V1 .afpub?

Here you go, but targeted explicitly to PSO Coated v3, as shown in the clip below (the initial latent CMYK target is ISO Coated v2, as per my system CMYK default):

Note that you need to ensure that your underlying (implied/latent) CMYK target profile is correct. Also, when you export to PDF/X-4, you need to change the target color space to CMYK (from the default "As document", which would actually use factory default US Web Coated v2 as the target profile), and then choose "Use document" for the CMYK target profile; choosing explicitly the target at this stage MAY result in retranslation of colors even if the target matches the implied CMYK target (recalculation will happen and there may be rounding errors)!

Note that in version 2 you no longer even can choose RGB color mode as the target, which is correct as much as no matter what you choose here, the color mode of the export file will be CMYK, which you can easily verify with the attached file that has pure RGB swatches defined.

The point is: it seems that Affinity apps cannot produce PDF/X-3 or PDF/X-4 so that RGB definitions in native objects are retained, nor can they produce a mixed-mode PDF where document color definitions in RGB or CMYK for native objects are retained ("do not change" kind of export PDF). In addition, while non-PDF/X-based exports with RGB definitions are naturally possible, then all native colors will be in RGB, also the explicit CMYK definitions that are wanted to be kept (like e.g. official corporate colors with CMYK definitions, which to certain narrow extent could even be unreachable in (s)RGB color gamut). [Placed image content can be in mixed mode naturally, but that is a separate matter.]

Additionally, as shown in this post, if you intend to work in RGB color mode, you need to be careful to not create a conflicting CMYK export, causing all CMYK definitions to be recalculated (as seemed to have happen when you exported your PSO Coated v3 in RGB color mode).

Affinity apps are a kind of a PDF high school...you need to know much more than when working with Adobe apps, and when uncertain [and working with Adobe apps], you could just ask the printer to get step-by-step instructions. 

pdfx4_rgb_implied_psocoatedv3.afpub

 

[thomaso]

6 hours ago, lacerto said:

Additionally, as shown in this post, if you intend to work in RGB color mode, you need to be careful to not create a conflicting CMYK export, causing all CMYK definitions to be recalculated (as seemed to have happen when you exported your PSO Coated v3 in RGB color mode).

Thank you! for the video, it makes the difference obvious: I had not changed the documents RGB colour space & profile but only selected CMYK as export space + PSO Coated v3 as export profile.

The way of changing the documents profile first (even with "assign" instead of "convert") to get an RGB document properly exported as CMYK appears odd to me. I would expect Affinity would do the correct conversion during the export process 'just' according to the export settings. Actually this Affinity requirement to modify the document colour space before & as export colour space reduces the advantage of RGB as document working space.

But it is definitely good to know this workflow option.

[lacerto]

2 hours ago, thomaso said:

The way of changing the documents profile first (even with "assign" instead of "convert") to get an RGB document properly exported as CMYK appears odd to me.

I seem to have demonstrated the workflow poorly since this is not what happens here. The document was created initially in RGB mode so it got its RGB profile selected at that point. At the same time, a document always also gets a latent (implied) secondary (in this case CMYK) target profile, and this will be the profile defined in the Preferences > Color. In my case, this would be ISO Coated v2.

I show on the video, how I change the underlying ISO Coated v2 to PSO Coated v3. This needs to be done so that I first switch the color mode from RGB to CMYK without changing the CMYK profile at that stage (it would result in change of color values). After the color mode is switched, I go and change the CMYK profile to PSO Coated v3 by using the Assign method, so that none of the color values change. After that I finally switch back to RGB mode so that I can demonstrate how to export from an RGB document a PDF/X-4 document so that CMYK definitions are retained. They do not change because the document is exported explicitly in CMYK color mode (and NOT the document color mode, which is RGB, and which Affinity apps cannot use, so this option results in using factory default US Web Coated v2, and changed color values). Additionally, the CMYK color profile must not be explicitly selected but left as "Use document profile", which is now PSO Coated v3 (if PSO Coated v3 is explicitly selected, I noticed that there are minor rounding errors, showing that color values are actually recalculated instead of just left at their existing CMYK values).

I do not understand why the color profiles cannot be selected and assigned/converted simultaneously similarly as in InDesign and CorelDRAW, as this is quite complex now.

[thomaso]

22 hours ago, lacerto said:

At the same time, a document always also gets a latent (implied) secondary (in this case CMYK) target profile, and this will be the profile defined in the Preferences > Color. In my case, this would be ISO Coated v2.

Thanks again! Not your video was poorly demonstrating but myself failed to notice your document reset from CMYK to its initial RGB/sRGB at 0:51 – 0:56 min.

Yes, I can confirm this workflow maintains CMYK values without the need to switch the document colour space if  the app preference is set to the desired export profile (= output intent for PDF/X). Also this method appears to maintain the original profiles of placed resources on export as expected if "Convert image colour spaces" in the 'More' options is unticked (as it is in the default X-3 / X-4 export presets) … while the buggy, limited 'BlendingColorSpace' still may cause issues.

So unwanted conversion of colour definitions appears to be mainly a lack of a clear, unambiguous Affinity interface, especially the wording "Use document profile" in the 'More' options seems actually to mean "Use the profile currently set in the app's colour management preference" if the document is still set to RGB and contains objects in CMYK colour definition which do not get converted this way (~ 'preserve values').

In addition the "Convert" button visually pressed by default in the 'Document Setup' is misleading by implying a conversion will happen in every case with the current setting, especially if the user has set a profile with "Assign" + closed this window with "Okay" this interface misleads as soon the window gets reopened again.

[lacerto]

15 hours ago, thomaso said:

Affinity interface, especially the wording "Use document profile" in the 'More' options seems actually to mean "Use the profile currently set in the app's colour management preference" if the document is still set to RGB and contains objects in CMYK colour definition which do not get converted this way (~ 'preserve values')

Or still more accurately: "Use document profile" means (when CMYK is selected as color mode in the control above): use the current CMYK color profile set for the document (which is by default one defined in the Preferences > Color when the document was created, or one defined manually last time the document color mode was CMYK).

This option will then pass through all CMYK values defined for native objects, and will convert all native RGB values to the target CMYK (also when using PDF/X-3 and PDF/X-4, whereas Adobe workflow does not, as by default it would pass through all RGB values, with appropriate profiles for later conversion; Affinity apps will convert native RGB to CMYK in any case when using PDF/X-3 or PDF/X-4; and when using non-PDF/X-based export, will convert all native color values either to RGB or CMYK; there is no "do not change" option).

Defining an explicit ICC profile at this stage signals to Affinity apps: use THIS profile instead of the document profile to recalculate color values, even if the current document profile is the same as the explicitly defined one (resulting in recalculation).

Possible conversion of color values of placed content (mainly raster images) is determined by "Convert image color spaces" setting (but e.g. placed .AI color space will always be converted, disregarding the value of this setting). However, PDF content placed to be passed through will never be converted (unless becoming rasterized), e.g. not even when exporting placed RGB PDFs to CMYK and forcing conversion of image color spaces, or exporting placed CMYK content to RGB.

This kind of behavior can make it very hard to produce properly to multiple color spaces (pure CMYK or pure RGB)-- or PDFs for optimal late color conversions with correct source and target profiles (i.e., mixed color mode PDFs, and correctly converted placed and native CMYK content).

[Ldina]

Tomaso and Lacerto...

Thank you for continuing this conversation, as I learned a lot from your dialog. I dropped out for a while because I had to catch up a little (I'm still not there!).

The way Publisher handles color is quite different from InDesign and I'm so used to InDesign, that this takes some getting used to. One (of many) important thing that I didn't understand was that a placed "Images" and "Pixel layers" are different in Affinity. Another is the ability to assign a rendering intent to a placed image in InDesign, which I don't see, or can't find, in Publisher. Things aren't yet fully clear to me, but some of the fog is lifting. 

You may have answered this in your discussion, but I haven't quite got it yet. If I want to design an 8-page brochure that I will send to press AND export as an RGB PDF, how do I do that to retain the maximum color gamut for the CMYK Press PDF and the maximum gamut for the sRGB PDF? In other words, I don't want any RGB images, native elements, etc, clipped to a CMYK gamut before creating my sRGB PDF file. Is that possible? Can I just switch modes back and forth at will in Publisher before making my exports...i.e., RGB mode for the RGB PDF, and CMYK mode for the press export.

Thanks.

[lacerto]

13 minutes ago, Ldina said:

If I want to design an 8-page brochure that I will send to press AND export as an RGB PDF, how do I do that to retain the maximum color gamut for the CMYK Press PDF and the maximum gamut for the sRGB PDF?

I would create this as a CMYK document and iƒ possible, select the correct target profile at this stage. The RGB profile that would be used for the document would then be the one you have defined in Preferences > Color, and by default it is sRGB.

I would then place all raster image content (photos, etc.) as RGB files. You would not see full sRGB gamut while working in Publisher, but would get the images in native sRGB once exported to digital PDFs. If you need certain native objects, fonts, etc. to be defined in RGB, you could define the color values in RGB color model (using the Color panel), even if their appearance would be adjusted to simulate the current CMYK target. If it is important to see the full sRGB color gamut while determining the color values, you could temporarily switch to RGB mode (as said, just switching the color modes does not change color values as long as you do not have (Pixel) layers). At that point, you could also have Soft Proof adjustments to have an approximation on how specific RGB definitions look in different CMYK color spaced or in grayscale.

You could alternatively of course create the document in RGB mode (and select sRGB as the document RGB profile). But as mentioned above, you would at some point need to specify the actual target CMYK profile and most probably change it from the default profile determined by Preferences > Color. That is a bit tedious process, and there are rather strict steps that need to be taken to not cause inadvertent CMYK conversions at the time the production PDF is created (as mentioned, CMYK conversions WILL happen at export time, in case you use PDF/X-based methods, or the default press-based export methods, that explicitly use the CMYK color mode). The additional restrictions as for applying coloring on grayscale images (not having the important K-Only button available), etc. might also be a reason why working with a CMYK document might be more useful and straight-forward, despite the narrowed RGB color space while working (but not when producing).

As for determining CMYK values for native objects (shapes and text), the most important thing is to use K-100 (and C0 M0 Y0) for black text. For other objects, I would use RGB definitions, which would then be converted to optimal CMYK values according to the CMYK target that you would know at the time of production (you could use another document in RGB mode to see the colors in full color gamut, or temporarily switch to RGB color mode). I would initially choose a generic CMYK profile (like the default US Web Coated v2) that has TAC limit around 300%). This way, if and when you change the CMYK profile and you have any CMYK definitions or placed CMYK content, you could most often just "Assign" the new profile so that CMYK color values do not change. But if you have lots of CMYK content and clearly different target profile (e.g. newspaper targeted profile that needs to have low TAC), you would need to use the convert option when choosing the new profile, and then change the black text color (now changed to four-color-black) back to K100.

There are some additional considerations, mainly related to placing CMYK content that has embedded profiles. When you place these kinds of files (e.g. AI files), InDesign by default discards embedded CMYK profiles and just passes through the native CMYK values, so does basically the same as when placing PDF files. Affinity apps, however, would leave CMYK color values unchanged only if the placed AI file does not contain an embedded profile, or if the embedded profile matches that of the document target CMYK profile. (For PDFs placed for passed through the native CMYK values would always e passed through). This might cause some headache whenever a CMYK document profile is later changes, as I am not convinced that the placed CMYK mode files will be correctly updated to have information about changed conditions so that color values would not get incorrectly converted when creating the production PDF.

I am sorry for providing (likely) "too much information", as your situation might be much simpler than described here so you would not need to take into account all the aspects described here. But simplified instructions might be harmful, too. The best advice I can give is to use a tool that can check the produced color values from the PDF itself. If you do not have anything better, opening the production PDF in Affinity Publisher (or Photo, where you can also use the Channel panel to view separations, and view histograms) would make it possible to view the color values of objects and pixel layers (even if you could not check things like overprints). 

[loukash]

2 hours ago, Ldina said:

The way Publisher handles color is quite different from InDesign and I'm so used to InDesign, that this takes some getting used to.

I hear you! It was a long process for me as well.

[Ldina]

@loukash You've got that right! It is a process, but I'm getting there gradually. And thank you for your helpful posts, on numerous subjects!

@lacerto Thank you for the in-depth and very helpful explanations. I prefer all this detail because prepping a job for a press can be complicated and there are so many places where one can mess up the files. With the help of this discussion, I am getting a handle on it. I totally appreciate the need for 100K text, line art, corporate colors, etc. It is also helpful to know that placing an AI with an embedded CMYK profile can result in unwanted conversions because I design brochures for engineering companies with a lot of line art. I guess the safest route with Publisher is to place AI and PDF files without embedded CMYK profiles. I'll definitely experiment.

So, if I have any native colors that I want to print in specific CMYK colors, just define them in the color picker using the CMYK boxes, regardless of my currently selected color space. Now I understand what I didn't in a few of your original posts. It's a very different model.

When editing photos in Photoshop, I was accustomed to editing in Adobe RGB, then doing a soft proof and checking whether the image would convert better to the destination CMYK space using Perceptual or Colorimetric Intent. I'd leave the file as Adobe RGB when placing it, but I would set the rendering intent of each placed image individually inside of Indesign. When exporting to PDF, each image would be converted using its embedded profile and the rendering intent I chose when placing it. I'm guessing this cannot be done in Publisher, and that all content that is not already in the destination color space will use the rendering intent specified in Preferences. 

Thanks for your patience and your help. I'll get there, hopefully sooner rather than later. 

[loukash]

1 minute ago, Ldina said:

@lacerto Thank you for the in-depth and very helpful explanations.

@lacerto is our PDF Jedi!  

[lacerto]

3 hours ago, Ldina said:

I'm guessing this cannot be done in Publisher, and that all content that is not already in the destination color space will use the rendering intent specified in Preferences.

I assume that this is what happens. I do not think that the behavior is properly documented (e.g., whether this only happens when opening a document with a conflicting color profile and converting, or if the same method is used globally whenever conversions are needed). Anyway, there are no image-specific settings (either for making sure that an image really has the desired color profile and changing it if needed, nor for image-specific rendering intent), so there may be situations where you want to convert to target CMYK (when known) to guarantee best possible conversion.

The Resource Manager basically shows the color profile (either embedded or an empty string if no color profile is embedded), but I am not entirely sure that placed images without a profile actually get assigned with the current document profile, or if the need for conversion is examined only when needed, e.g. at export time or when rasterizing images on canvas. As I just tested this with multiple CMYK profile reassignments, it seems that placed images marked with no profile export correctly (without color changes), while images with conflicting profiles get recalculated values so at least it seems that there is no need to refresh placed content after a profile change (neither in current versions 1 or 2). At some point I think that placed image content without profiles used to be tagged with document profiles and were not always properly updated when the document profile changed. 

Btw. I just noticed that when placing raster image content (at least TIFFs) with an embedded CMYK profile and there is a conflict with document CMYK target, the raster images are handled similarly as AI files with conflicting CMYK content and get recalculated color values -- but not when exporting by using PDF/X-based methods! I had not noticed that before (because I very rarely place images in CMYK mode, and if I do, always convert to required target). So there is frequently a new oddity to learn about (as mentioned, Adobe apps by default discard all CMYK profiles, PDF/X-based methods are not a special case).

3 hours ago, loukash said:

@lacerto is our PDF Jedi!  

@loukash is just kidding... I did not know anything about PDF intricacies before entering the Affinity environment, and still know very little, but I have just learned about differences in production methods between Adobe and Affinity apps. I think that the latter make us all kinds of PDF gurus in the long run. Which is not an entirely bad thing 🙂