<br><br><div class="gmail_quote">On Tue, Dec 20, 2011 at 4:36 PM, Patrick Noffke <span dir="ltr"><<a href="mailto:patrick.noffke@gmail.com">patrick.noffke@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div class="h5">On Tue, Dec 20, 2011 at 2:51 PM, Patrick Noffke <span dir="ltr"><<a href="mailto:patrick.noffke@gmail.com" target="_blank">patrick.noffke@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Tue, Dec 20, 2011 at 1:07 PM, Jean Ghali <span dir="ltr"><<a href="mailto:jghali@libertysurf.fr" target="_blank">jghali@libertysurf.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
----- "Patrick Noffke" <<a href="mailto:patrick.noffke@gmail.com" target="_blank">patrick.noffke@gmail.com</a>> a écrit :<br>
<div>><br>
> I expect all colors to use the profile to convert to CMYK, but for<br>
> RGB<br>
> colors when R=G=B, it is only using black. I don't think this is the<br>
> correct behavior.<br>
<br>
</div>The behavior here is explained by quality considerations. When using vector objects with r=g=b, icc conversions does not work well when document is targetted to be printed on a press (digital or not). In those case, icc base cmyk conversion will usually produce a separation using all 4 cmyk channels and this is the problem :<br>
- such color has very bad colorimetric stability on press : unless the color is very dark, any shift on a single color will trigger the gray to be shifted. As the shift depends on the ink percentage, the result will also be a poor gray balances.<br>
- using all 4 cmyk colors for grays on text and lines will deteriorate output quality by making text and lines look more 'fat' than they should be. Any ink registration problem will make the problem even worse.<br>
- such a document will need better ink registration and cause higher make-ready times if printed on traditional press, those higher make-ready times will however not really improve printed quality in this case<br>
- higher make-ready times will cause higher production costs<br>
<br>
Conclusion : in most case, traditional icc conversion is to be avoided for gray color with r=g=b. Scribus behavior has been implemented in view of those practical considerations. Preflight tools such as Pitstop implements similar handling of rgb grays btw.<br>
<br></blockquote><div><br></div></div><div>Thank you for the explanation. That all makes sense, but it seems like a band-aid to account for some users' ignorance. The correct way to fix those problems is to use a CMYK color (with only black set to non-zero). But for those same users that want to create RGB colors that are near gray and very similar to each other, they will not get the colors they expect when they go to press, and they likely will not understand why.</div>
<div><br></div><div>Can you please tell me how RGB images are treated, when a printer ICC profile is assigned to the output intent, and an RGB ICC profile is assigned to the RGB images? Does Scribus do the color conversion when creating a PDF/X-3 document, and store the images as CMYK, or store the (RGB) profile in the PDF and associate it with the RGB images? If the latter, then it is up to the printer to do the CMYK separations, and hopefully they do them correctly.</div>
<div><br></div></div></blockquote><div><br></div></div></div><div>A colleague of mine has Illustrator, InDesign, Photoshop, and Acrobat. We did the same experiment in Illustrator and InDesign. We created an RGB rectangle with R=G=B=128, and another rectangle with R=128, G=129, B=128. If we had the CMYK ICC profile assigned for the output intent when we exported to PDF/X-3, it converted both rectangles to 4-color CMYK values (approximately C = 0.25, M = 0.19, Y = 0.19, K = 0.45 -- this was the profile I created with a lot of GCR).</div>
<div><br></div><div>One thing that tripped us up was that, in Illustrator, if we had the image mode set to CMYK, then once we created a rectangle, the color was instantly converted to CMYK using the currently assigned profile -- even if we used the RGB color tool for that element to set it to (128, 128, 128). Then when we changed the profile, the CMYK values weren't changing, which was what tripped us up. The image had to be in RGB mode, if we wanted to change the output profile prior to exporting to PDF/X-3.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div></font></span></div></blockquote><div><br></div><div>Another reason why I think this is incorrect behavior is with respect to gradients. If you create a rectangle with Black R=G=B=0 on the ends, and a dark red (for example), with R=75, G= 45, B=45 in the middle, then when you make the PDF, the black ends will get K only, and the middle will have 4-color, with the CMYK coverage depending on the output intent (for the SWOPcoated5_240 TAC profile, the middle red CMYK is (40%, 70%, 36%, 76%)). If you want to print this on a high-quality device, which is capable of handling high TAC levels, the black ends will be too light from what the author intends. Or to put it another way, if you work with RGB colors, to get a nice saturated black on a high quality device, you have to create a color like R=0, G=1, B=0.</div>
<div><br></div><div>What do others think? I'm happy to file a bug report (with a patch), if you think it makes sense to change the behavior.</div><div><br></div><div>Thanks,</div><div>Patrick</div></div>