RE: background-print

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