W3C home > Mailing lists > Public > www-style@w3.org > June 2010

Re: [CSS21] Issue 149 - px vs. pt

From: David Singer <singer@apple.com>
Date: Tue, 29 Jun 2010 09:56:45 -0700
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-Id: <8A85B5B9-D452-40A5-8EE8-030ADE11D0C8@apple.com>
To: Brad Kemper <brad.kemper@gmail.com>
The problem comes when you have a device with say 300dpi.  If you want 96 px/in, and CSS pixels are an integer number of device pixels, then you have to pick 3:1 for that ratio, which results in a CSS inch being 288 (3*96) device pixels, which is about 4% short of a true inch.  Basically, something has to give:
* 96 CSS px/in
* integer relationship
* true measurements

If you anchor in true measurements, and the 96 px/in is inviolable, then it has to be the integer relationship that gives.  I think in print media in particular, people expect inches to be inches, not 4% wrong.

If this bothers you, then go the 'reference pixel' anchor route, whereupon the first two hold and the third does not.

(Note that when you go the 'reference pixel' anchor route, it might be because there is no reasonable definition of true measurements for this device -- think of projection eye-glasses, for example).


On Jun 29, 2010, at 9:33 , Brad Kemper wrote:

> 
> On Jun 28, 2010, at 10:32 PM, fantasai wrote:
> 
>> On 06/17/2010 01:06 PM, fantasai wrote:
>>> 
>>> Ok, here's the new paragraph:
>>> 
>>> | For a CSS device, these dimensions are either anchored (i) by
>>> | relating the physical units to their physical measurements, or
>>> | (ii) by relating the pixel unit to the <i>reference pixel</i>.
>>> | For print media and similar high-resolution devices, the anchor
>>> | unit should be one of the standard physical units (inches,
>>> | centimeters, etc). For lower-resolution devices, and devices
>>> | with unusual viewing distances, it is recommended instead that
>>> | the anchor unit be the pixel unit. For such devices it is
>>> | recommended that the pixel unit refer to the whole number of
>>> | device pixels that best approximates the reference pixel.
>> 
>> David Singer pointed out that it would help to point out
>> that the new definition means px units might not map to
>> an integer number of device pixels, so I've added the
>> following two notes after this paragraph:
>> 
>> | <p class="note"Note that if the anchor unit is the pixel unit,
>> | the physical units might not match their physical measurements.
>> | Alternatively if the anchor unit is a physical unit, the pixel
>> | unit might not map to a whole number of device pixels.
>> |
>> | <p class="note">Note that this definition of the pixel unit and
>> | the physical units differs from previous versions of CSS. In
>> | particular, in previous versions of CSS the pixel unit and the
>> | physical units were not related by a fixed ratio: the physical
>> | units were always tied to their physical measurements while the
>> | pixel unit would vary to most closely match the reference pixel.
>> | (This change was made because too much existing content relies
>> | on the assumption of 96dpi, and breaking that assumption breaks
>> | the content.)
> 
> Hmm. I had begun thinking of the px unit as more or less being equal to 1/96 of a physical inch, rounded to the nearest physical pixel, and then a CSS inch is 96 of those (not including scaling & zooming). Are there cases other than downscaling (aka zooming out) in which the px would not round to pixel? In high res printing, I would think it would be pretty natural to round to the pixel, even more so than on monitors. Maybe we can just say that when downscaling, if the anchor unit is a physical unit the px may not round to a physical pixel.
> 
> Or is it the case that even though the print device may print binary dots with no anti-aliasing, that the px may still be a floating point number of physical pixels (even at 100% scale), so that the print can still be accurate over larger distances?

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Tuesday, 29 June 2010 16:57:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:28 GMT