This content has been marked as final. Show 20 replies
Thanks Chris. I'll try this, as I have never been able to get a decent print from ID to an RGB considereed device.
InDesign 2.0 and InDesign CS2 cannot print correctly
to a PostScript printer if Printer PostScript Color
Management is chosen. The printed colors are looking
In fact this works very well by Acrobat and by PageMaker.
The harddisk in the printer contains one or more valid
custom ICC output profiles (one is actually enabled).
I can print by ID 2.0 or CS2 if I choose 'Let ID do the
Color Management' and assign the actual ICC profile.
The result is not exactly the same as by Printer PostScript
My solution so far: print anything of importance not
by ID but by Acrobat. Exception: plain black text ...
Best regards --Gernot Hoffmann
I consider PostScript color management to be more trouble than it's worth, in all of its various incarnations. I'd rather wrestle with a ground hog infested with bubonic plague. So I always use the "Let [application] Manage Colors" setting.
Printer PostScript Color Management in the context of
Acrobat and PageMaker is as correct as possible in my
Wanted by InDesign, it's as wrong as possible - inverted
This says simply, that ID's workflow is terribly wrong,
ID 2.0 or ID CS2.
PostScript Color Management uses ICC profiles indirectly
by converting them into color rendering dictionaries.
The calculations are executed inside the printer.
Why should this be inferior to Host Based Color Management ?
It's probably not a matter of preferences or habits.
If host based color management spoils the black generation,
then one can try printer based PostScript CMS.
Maybe it works better, as for my printer (OKI C9600).
Altogether, one has to live with widely 'somewhat limited'
Good for manufacturers of ink and toner and proofing paper,
but normally not an issue for authors of best-selling books.
Best regards --Gernot Hoffmann
PostScript color management depends on the RIP to work correctly and this is completely random. Some RIPs honor CSA's, some ignore them. Some honor RGB CSA's but not CMYK ones. Some will honor CRD's, some only use the internal CRD's. Without ample testing your particular RIP you have no way of knowing if it will work. So I consider it treacherous and a big pain in the rear.
And on top of that, no black point compensation for the conversions.
For other readers: PostScript Color Management
was invented by Adobe.
Mainly the difficulties of black generation were
brought into the discussion by a member of the
Adobe staff years ago, when ICC profile experts
were not even aware of this ugly problem.
I think I could add some information about this
historical discussion, if somebody should be
Best regards --Gernot Hoffmann
Thanks for your posts. I, for one, would be interested in that historical information.
Chris, sorry for some off-topic comments,
Al, I'm referring to
Engineering color at Adobe,
chapter 15 in
Ph.Green, L.Macdonald (Editors)
John Wiley & Sons, 2002
1989/1990 Adobe designed the PostScript Level 2
color concept with CIE-based device independent-colors.
Apple's ColorSync system development was started 1991
and announced 1993.
The International Color Consortium ICC was started in
From these facts it is obvious that Adobe's concept
came very early. There was no need to change it, but some
features were added later.
Dr King emphasizes the importance of handling black in
CMYK workflows. The ICC had overlooked this - profile
to profile conversions in CMYK destroy the original black
generation. There are other design concepts for ICC profiles
which are IMO rather doubtful: mainly the very complex
number and data format system and the definition of the
location of modules by byte offsets. Compared to these
structures, PostScript is simple and readable (ASCII).
All this lead me to the conclusion that PostScript color
management is probably not bad.
'Adobe' is not the same as 'PostScript':
I found, that host based Acrobat CMM for the OKI printer
C9600 lead to severe bugs for the black generation.
This is described here in chapter 1:
Then I changed he strategy systematically: everything
printer based by PostScript. ICC profiles are downloaded
to the harddisk. Color Rendering Dictionaries (output)
and CSAs (input) are calculated in the printer.
If the printer is equipped with genuine Adobe PostScript 3
('level' no more used) then one can expect that it works
correctly. It is OK for Acrobat and PageMaker but not
for InDesign (tested for CS2 and Acrobat7).
Best regards --Gernot Hoffmann
"print as bitmap" button is unavailable for me in CS3 through multiple iterations of settings.
Can someone please clue me in on how to get that button un-grayed.
If it's grayed out, you're printing to a PostScript device, which as I mentioned in the initial post is not applicable to this conversation.
Thank you Chris.
The bitmap option is only applicable to non-PostScript printers. I'm a little baffled by the workflow implementations of a RIP that disallowed prematched data from arriving at the RIP as if the RIP can actually do everything we'd ever want to do in terms of color management. Is this a PostScript 3 RIP or other?
Sorry Chris, I deleted part of my post while you were posting.
I was in error.
I can do application managed output with InDesign by sending composite RGB.
By prematched data, I take your meaning to be source space?
Yes, the z3100ps is a postscript 3 rip, however, HP takes great pains to hide the fact that the internal postscript RIP version of their printer will only accept, create and convert to RGB.
Once again, I'm sorry for my confusion.
Sorry when I say "prematched" I mean: application producing print job has normalized all color spaces to the device output space (the device output space being the color space/profile for the device you're printing to).
So for the HP printer with RIP I'd expect that to be a CMYK profile. That they only give you an option to normalize to RGB is in my view a problem, unless that is the device output space.
Anyway, I should better qualify that the bug this topic is originally about, is with respect to non-PostScript devices, rather than RGB output devices as I stated. That would have made things more clear.
And as a qualifier to the statement that I think it's a problem for the HP internal RIP to only accept RGB:
1. If that RGB space is defined with an RGB output device profile for the printer, then it's probably fine.
2. If that RGB space is supposed to be some intermediate space, then this is a problem. For most workflows it's a small problem. But a problem nevertheless. What intermediate space should you use? There's either an issue with the gamut of that intermediate space: sRGB too small for example, and ProPhoto RGB maybe too big if the output bit depth is only 8bpc.
So, kind of an odd arrangement.
Yes, RGB space is defined with an RGB output device profile.
I believe there is also the intermediate space in the device driver called sRGB_A.icc under library/Printers/Profiles.
Not being sure of the signal path heirachy, I don't know if this is a default space, or an intermediate space through which the driver bases its ink limit settings. I believe this space is only accessible on a non postscript Epson driver for instance, by hacking it out with hexedit. Now I may be completely wrong on the above. If so please disregard.
I'm sorry if this turned into a hijack of your original post.
Your CS3 non-postscript workaround is very important, and deserves to be distinct from my concerns.
I'll post another thread about the internal RIP hierarchy of the HP.
I am trying to print from InDesign CS3 to an Epson Stylus Photo 1400 (on Mac OS X 10.5.4). I have used this printer before with XP and CS2... beautiful prints, with minimal printer setup... never had to install new drivers. Now my colors are very dull, reds tend to be brown, blues are washed out. I went through a scheme of customer service tips with Epson's support by phone. I cleaned the printer heads, etc.
I think it is a problem with InDesign and the color management. I am have minimal comprehension of ICC Profiles and InDesign's color settings. I know I fiddled around with the Edit>Color Settings a while back based on internet support information. I have printed multiple versions using "ColorSync" and "Epson Color Controls" while disabling color management. The last and final step I took was using the "Print as Bitmap" option.... this yielded the same results. I then tried to print a high quality PDF... nothing different.
One thing that Epson support had me do: print a photo from previewer. The quality was much better than what I see now, but still not what I remember when I used my PC.
With "Print as Bitmap" selected you should be able to get the exact same results as printing from PS if you paper profile and printer driver setting are exactly the same. "Print as Bitmap" with IDCS3 should force it to printing exactly the same as IDCS2 did.
The problem with IDCS3 (and also IDCS4) is that the monitor profile is being introduced into the RGB printflow. Canon drivers with "Fast Graphic Process" selected bypass the Apple printing processes and the monitor profile is not being introduced.
So is it a Apple or Adobe problem, I don't know.
THANK YOU, DYP!
Choosing "Print As Bitmap" in InDesign CS3 totally made my RGB printouts from InDesign Cs3 EXACTLY the same as from Photoshop CS3!
I made my ICC profiles for scanner and printer using Monaco EZ-Color, possibly the lowest level profile-generator out there. I'm now considering buying the X-Rite i1XTreme system for making super-accurate ICC profiles for my monitors, scanner, and printers (including PS-driven CMYK proofers). But for now, this solution at least gets me consistent internally with CS3. :-)
I'd evaluate colormunki design or photo as well, just because that software is building such great profiles from very minimal numbers of patches. it's actually kinda surprising how good of a job its doing. for certain printers/media combinations, i've found the eye one match software produces profiles that do odd things (clobbered shadow detail being one of them). *shrug*