W3C home > Mailing lists > Public > www-style@w3.org > March 2008

Re: [CSS21] [css3-values] px and device pixels

From: Brad Kemper <brkemper@comcast.net>
Date: Sat, 22 Mar 2008 10:24:56 -0700
Message-Id: <34431033-127D-4112-B059-79AA65668071@comcast.net>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org
To: Andrew Fedoniouk <news@terrainformatica.com>


On Mar 22, 2008, at 12:43 AM, Andrew Fedoniouk wrote:
> fantasai wrote:
>> I always thought it was in the spec, but it seems to be an unwritten
>> assumption, that CSS 'px' units should map to a whole number of  
>> device
>> pixels. The examples in the spec all assume rounding to a whole  
>> number
>> of device pixels. And while I don't think we should absolutely  
>> require
>> this (I know on printers defining "device pixel" is not  
>> straightforward),
>> I think it should be recommended as something to aim for.
>> Proposed change:
>> Replace
>>   "the user agent should rescale pixel values"
>> with
>>   "the user agent should rescale pixel units to a different whole  
>> number
>>   of device pixels"
>
> That is not feasible I think. The train have left the station already.
>
> (CSS px happens to be equal 1/96 of inch[1]. So it is not a  
> physical unit but rather logical one. The same ratio is observed  
> for HTML pixel units in all major UAs)

That's only "If the pixel density of the output device is very  
different from that of a typical computer display" though. If I have  
a 72 dpi monitor (computer display), then it will be 1/72 of an inch,  
AFAIK. A one pixel width border would not color in 3/4 of a pixel in  
my 72 dpi monitor, which is what Fantasai's point was, if I  
understand it correctly.


> <table width="800"> and <div style="width:800px"> fit almost  
> exactly on
> printing paper of letter format (8.5in == 816px). All UA's print  
> html this way.

But that's because of a "fit to width" option of the printing dialog  
box, isn't it? At 96 pixels per inch, 800 pixels would be 8.33  
inches, but Internet Explorer (or maybe all Windows apps, I'm not  
sure) defaults to .75 inch margins (outrageously enormous margins, if  
you ask me, considering average people never change settings like  
that), meaning that everything must get squeezed into 7 inches on an  
8.5x11 sheet of paper. Even without those defaults, I don't think  
many people have their margins set up to be 1/3 inch or less on the  
sides.

> If to rescale pixel units then it means width:800px should be rendered
> differently on user's printer. How it supposed to work?

I don't think so. Very few office printers are 96 dpi, so some form  
of scaling is already going on, and I think this is the "rescaling"  
that fantasai refers to. The printer in my office is 9600 dpi, but my  
1px (in CSS) lines are not printed using single device pixels (a  
hundred times smaller than screen pixels), but rather are scaled to  
"about 0.20 mm".  When fantasai says ""the user agent should rescale  
pixel units to a different whole number of device pixels", she really  
seems to be repeated the text in the link you included that says "On  
a 300 dots-per-inch (dpi) printer, that may be rounded up to 3 dots  
(0.25 mm); on a 600 dpi printer, it can be rounded to 5 dots." In  
other words it would not be some fraction of a device pixel.

(Re)scaled to .2 mm = .008 inch
.008 inch * 600 dpi = 4.8 device pixels
Rounded to nearest whole number = 5 device pixels (dots)

>> OR
>> Insert before
>>   "It is recommended that the reference pixel be..."
>> the sentence
>>   "It is recommended that the pixel unit refer to the whole number of
>>   device pixels that best approximates the reference pixel."
>
> I'd suggest to introduce new length unit - physical pixel
> - that is "naked" number (without any special unit designator).

That would result in thicknesses that are vastly different when  
printed than they are on screen (about a hundred times smaller in my  
case). As an author, I can't see much use for that.

>
> [1] http://www.w3.org/TR/CSS21/syndata.html#length-units
>
> -- 
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>
Received on Saturday, 22 March 2008 17:25:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:02 GMT