- From: Paul Tykodi <ptykodi@tykodi.com>
- Date: Fri, 12 Aug 2011 07:42:05 -0400
- To: <www-style@w3.org>
- Cc: "'Mikko Rantalainen'" <mikko.rantalainen@peda.net>
Hi, I have been reading this thread since it began back in February of this year and I believe the direction the discussion is beginning to take could be defined as follows: CSS should consider developing a print job ticket option Purpose: Provide a mechanism for authors to express their wishes regarding printing Implementation: UA's would have a mechanism to manage author intent as they parsed the DOM. As far as I know, there would be no reason for a UA to expose all the print job ticket values through the UA GUI. The options exposed, which could be overridden through the GUI, could be left to all UA developers to determine. I believe that the only things that CSS would need to publish as a standard would be the suggested method for an author to declare they planned to use the print job ticket option and then the job ticket values themselves. The IEEE-ISTO Printer Working Group (PWG) Semantic Model Working Group has already published a print related job ticket format as a PWG standard. There is a corresponding XML schema to go with it as well. http://www.pwg.org/mfd/index.html If you would like some input from the PWG, regarding the elements from the existing specification that might form the basis of a CSS defined UA appropriate print job ticket, please let me know. Thanks. Best Regards, /Paul -- Paul Tykodi Principal Consultant TCS - Tykodi Consulting Services LLC Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP Working Group 2011-08-12 04:12 EDT Mikko Rantalainen: >2011-08-11 18:36 EEST: Tab Atkins Jr.: >> It's the color-adjustment that really clinches the fact that we can't >> solve this solely by fiddling with 'background'. This really is a >> separate control with unique behavior, and has to be addressed with >> its own property (or some other entity, like an @-rule). I still >> suggest: >> >> printer-safe-colors: _prefer_ | avoid; >> >> The "prefer" value biases the UA toward suppressing backgrounds and >> adjusting text colors so as to save ink. The "avoid" value biases the >> UA against that. The user still has the ultimate choice; this is just >> a suggestion, moreso than most other properties. > >I find this property name and the suggested values to really hard to > understand (my mother language is Finnish). > > As far as I understand, the intent for this property is to declare if the > content author has designed the color scheme to be sane for printing > on a normal paper using normal printer using normal inks (that is, the > less white the resulting page is, the more expensive the actual > printing is). > > The name "printer-safe-colors" does sound more like "adjust the page > colors to fit in printer's gamut because this page contains wide gamut > colors" instead of "the UA should adjust colors to decrease ink usage" > (see "Perceptual rendering intent" below). > > How about: > > printer-colors: auto | economy | exact; > printer-colors: auto | economy | absolute | relative | perceptual > | saturation; > > Here the values have following meanings: > > auto: allow UA to decide (e.g. "economy" for normal printer, "exact" > for print to file, and in both cases include user override in print dialog) > > economy: the UA should adjust page colors to minimize ink usage. > The resulting page rendering may use incorrect colors. > > exact: the UA should trust the colors specified in by the CSS > (computed value after normal cascading of UA, author and user > style sheets). > > absolute: similar to exact but with additional knowledge that if > color management is used, "Absolute colorimetric" rendering intent > should be used. > > relative: similar to exact but with additional knowledge that if color > management is used, "Relative colorimetric" rendering intent should be > used. > > perceptual: similar to exact but with additional knowledge that if color > management is used, "Perceptual" rendering intent should be used. > > saturation: similar to exact but with additional knowledge that if color > management is used, "Saturation" rendering intent should be used. > > If you're not familiar with rendering intents, here's pretty good summary > for real world usage: > http://blog.lexjet.com/2010/12/20/how-to-find-the-right-rendering-intent/ > > And here's a pretty readable introduction about what really happens: > http://www.signindustry.com/digital/articles/2007-05-01-SGIA-Shell-RenderingIntents.php3 > > I think I'd prefer the second variant (with no "exact" but with direct control > of rendering intents). This is because the rendering intent really should > depend on the content of the document, not on printer type or quality. Of > course, if the intent is to save ink ("economy") then the color quality is of > no issue. Technically "exact" should mean "Absolute colorimetric" but the > result is seldom what the user wants even if used had correctly color > managed and calibrated equipment. > > In the end, it might make sense to use following property: > > color-management: auto | economy | absolute | relative | perceptual > | saturation; > > This is because color management is not special only to printing (for example, > the "economy" value would make sense even for screen usage in case of > mobile AMOLED displays where using darker colors will conserve battery). > > -- > Mikko
Received on Friday, 12 August 2011 11:42:32 UTC