Standard color definition questions

[LinSims]

I'll admit that I am pretty ignorant how to use FM's color features, because other than adding the corporate colors to the defined list they aren't something I have to deal with. I've never worked with commercial printers, so the terminology is strange to me. However, as part of my template redesign project, I thought I'd make the names consistent and also set the definitions up so they provide optimum output to PDFs.

This lead to me looking through both the standard definitions and the help files, and noting that quite a few of the standard colors are set to "Don't Print". Yet text with a "Don't Print" color applied (e.g., Mauve) shows up in PDFs anyway. This confuses me. If my output is always to PDF, does it matter what the "Print As" is set to? What about the Overprint? 

For the color values, I've been setting the model to RGB and inputting hex to the # field. Is that more accurate than using the RGB settings themselves, or the CMYK or HLS settings? For output to PDF purposes, does it matter what the model currently shows as? As far as I can see, FM just leaves it at whatever you last set it to, so if I changed the model from CMYK to RGB, all the other colors would use RGB as the model unless I changed it again. (Also, I keep trying to type RBG and I find that amusing.)

I did finally figure out how to use Tint, but I'm still wondering if it should be Process or Spot or Overprint or Knockout or if any of those actually matter given my output is always, always PDF. 

In short, when my output is always PDF and the PDF is never sent to a commercial printer but may be printed on ink jets or laser printers, what are the best choices to make for the following settings defining a color:

• Print As
• Model
• Overprint
• Color values

[LinSims]

Oh, yes, and if you're creating a tint based on another color:

• Should it be Overprint or Knockout?
• If you change the original color the tint is based on, does the tint update?

[Bob_Niland]

I last looked at this 10 years ago ANSI Z535.1 Safety Colors in Frame 

The ANSI spec has been updated at least once since then, and harmonized with IEC, so they may have more specific, perhaps obligatory, advice for authors of safety materials.

FM has no color management to speak of: no way to specify color spaces, transforms or profiles, no support beyond 8bits/primary RGB (and CMYK, other than in EPS, gets wrecked by Windows), no support for emerging new graphics file formats (but then, just adding HEIF to Photoshop was a pain). I have no idea what the strategy is for future FM color model support.

The apparent mis-behavior of Don't Print is interesting, but I've never used it, as Color Views does the same thing more conveniently, and it does work.

I'm wondering if Don't Print, Overprint & Knock-Out only matter in separation output.

Publishers today seem to be fine with RGB. Lulu, for example, even specifies it.

For PDFs on-line, with expected convenience printing on random platforms, sRGB is likely the way to go, keeping in kind that the primary values you enter for FM colors are uncalibrated and untagged.

My practice is to use tagged EPS where suitable, and otherwise use sRGB values, and then tag colors in post for sRGB IEC61966-2.1 if it matters (Acrobat DC/Pro » Print Production »  Convert Colors).

[LinSims]

*woof* That thread is packed with information and totally over my head.

I've decided to just set everything to Process/Overprint. Text and graphic elements created with Frame are Black, and our company's main colors of blue and grey. The original model to define the colors is RGB so I can use the Hex input field.

Everything else are graphics created in Visio and output to either SVG or PDF.

Now if there were just an easy way to rename colors that could be imported into all the documents as they come up for revision. Oh, well. BFME(1) works.

(1) Brute Force Massive Egnorance (yes, the typo is deliberate)

[Matt-Tech Comm Tools]

The short answer is that RGB is for emitted light (projectors, displays) and CMYK is for reflected light, which is printing on a CMYK printer, including inkjet, color copiers, and commercial printers.

Because the CMYK gamut (range) is smaller than the RGB range, if you specify a bright RGB color, you may not get what you expect out of a CMYK printer.

If you are happy with a CMYK color, it should display (close to) the same on a display and out of a printer.

Other things mentioned:

HLS (and HSL) and hex convert directly into RGB colors, so the same applies to them.

Tint won't impact output.

Spot will only be used by a commercial printer, and the value assigned in Fm is irrelevant, as the printer pours the specific ink color into the press, no matter what you call it.

Bob's right that Overprint and Knockout have to do with color separation for a commercial printer, and I've always been confused by the "Don't Print" option as well 😉

-Matt

[LinSims]

I used RGB mode to input the Hex numbers and when I was finished I changed it to CMYK since that appears to be what Frame wants. (Except for 4 colors that are tints based on Black set to 5%, 20%, 50%, and 80%, because that's what we use.)

If I understand correctly, doing it this way means that the PDF will look good on screen, and it should print correctly. 

[Bob_Niland]

Internally, FM apparently preserves either RGB or CYMK. But since FM is now a Windows-only app, it's subject to the Windows APIs on output, which as you can see from the Dove Isaacs remark on that older thread, is RGB only (unless it's changed in the last decade).

So RGB is the safe bet, and if you need CMYK, it's apt to take some work to ensure it survives to the print shop.

Any colors raise the issue of what R, G & B are when the user sees them (wavelength of primaries, etc).

Tints, and heck, R,G&B levels, further raise the issue of gamma to the client device (and/or dot gain & such at the print shop). Lacking real color management, this is all something of a dice roll in FM. Just getting supposedly identical imported object and FM colors to match for a single workflow can be challenging.

Adobe likely has nice color management libraries for InDesign, Photoshop, Illustrator, etc. Whether FM will be able to leverage them isn't something I can guess at. Personally, I'd place a higher priority on Unicode-SMP and spot-Xref support.

[Matt-Tech Comm Tools]

Hi Bob, it's changed in the last decade. It was actually Windows that didn't support the CMYK workflow (until, perhaps, Win7?)

[Bob_Niland]

We were already 2 years into Win7 when Dove made his remarks, and might have come in with Vista, so unless it changed in Windows 10, it's still an RGB engine that now accepts CMYK at the API.

[Matt-Tech Comm Tools]

All I know is that having been a commercial print person by trade, I was saddened by the lack of CMYK circa 2000. 

I was then later grateful when true CMYK support was added to the product.

Not sure what we're debating here, but per the 2019 online help:

By default, FrameMaker publishes CMYK values when printing or saving as Adobe PDF. If you opt to use RGB values while saving as a PDF, FrameMaker converts color values to RGB and creates separations in equivalent RGB values. EPS graphics, however, are separated according to the color values specified within the EPS graphic itself.

https://help.adobe.com/en_US/framemaker/2019/using/using-framemaker-2019/user-guide/frm_graphics_gr-...

[Bob_Niland]

Matt: Not sure what we're debating here…

We might not be. If my untested apprehension of the Windows situation is correct, these two workflows would be at risk of non-matching results in PDF & in print:
1. CMYK EPS » FM » PDF
2. FM object with same CMYK values  » PDF
In #1, the CMYK values are simply preserved. In #2, there may be risk of Windows converting the CMYK to some internal RGB model, then back to CMYK.

CMYK⇌RGB is not, and cannot be a fully reversible process, if only because in 32-bit spaces one is 32-bit, and the other is using only 24 bits.

[Matt-Tech Comm Tools]

Hi Bob, I agree with you that colors and images defined with an inappropriate model tend to convert in ways one might not want, especially when moving RGB images to the smaller CMYK gamut.

Fortunately, most stuff these days doesn't go the commercial print route. It seems "print" more often means printing on one's local device, and quality standards on laser paper are less than when print meant full-blown commercial presses.

Translation: Regardless of what FrameMaker is doing, you and I are in the minority of folks that are interested in the mechanics. It's probably a good thing that PDFs seem to be provided "as-is" and most folks are satisfied with whatever output they get.

At one point it was frustrating that the Mac version of Fm could produce color separations, but the Win version could not (and I can't recall ever using UNIX to do separations).

Dov called me up about it and we had a long talk. When Windows finally got their act together, the Win version of Fm ultimately separating defined CMYK colors in Fm to  separations correctly (easily verified using PDF color separation tools) as well as properly producing separations of CMYK images placed in Fm.

Of course, RGB and other colors still get "muddy" when output to CMYK devices or separations, and the same is true for images stored in RGB and other closely related color models.