W3C home > Mailing lists > Public > www-style@w3.org > August 2011

RE: background-print

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>
Message-ID: <02e601cc58e4$dc8ede00$95ac9a00$@tykodi.com>

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.

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.


Best Regards,

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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:56 UTC