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

Re: Making pt a non-physical unit

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 05 Jan 2010 13:01:50 -0500
Message-ID: <4B437E8E.2030809@mit.edu>
To: rfink@readableweb.com
CC: robert@ocallahan.org, "'www-style'" <www-style@w3.org>
On 1/5/10 11:15 AM, Richard Fink wrote:
> My assumption is based on that information not being utilized.

Xorg utilizes it in my experience.  See my reply to Ambrose in this 
thread, and the quoted parts of the log there.

Now it's possible that I'm just lucky with my monitors and they actually 
send EDID information, I suppose.

> For example, it doesn't make a lot of sense to me that I, as a web developer, can use JavaScript to query the screen resolution and - in IE8 and FF 3.6 - the logical pixel size but I can't query for the true physical dimensions of the display. Why not, if it's available?

In the case of Firefox, simply because we never implemented this, at 
least in web-exposed APIs.  There are internal APIs for querying just 
such information.

Note that you _can_ use CSS to query the physical display size.  For 
example:

   @media (min-device-width: 20in) {
     * { color: green }
   }

This is naturally subject to whatever lies the OS decides to tell the 
browser.  For example, on my Mac the OS reports a DPI of 96 even though 
the actual DPI is closer to 130 (17" screen at 1920x1200).  So as far as 
Firefox can tell the screen is 20" wide and 12.5" tall, whereas it's 
actually closer to 14.5" wide and 9" tall.  And on Linux Firefox just 
asks GDK for screen information (using gdk_screen_width() and the like) 
and uses the reported DPI to get physical sizes (though GDK does also 
offer gdk_screen_width_mm).

The dpi Firefox uses can either be set via preferences, or again queried 
from the OS.  In the Linux case gdk_screen_get_resolution is used, with 
various fallbacks to 96 in cases when it's actually less than 96 and the 
like...  On Windows, the logical DPI is currently used (GetDeviceCaps 
with LOGPIXELSY).  On Mac 96 is used.  On OS/2, DevQueryCaps with 
CAPS_VERTICAL_FONT_RES is used.

> Further, in Windows, the problem of users having their display resolution set to something other than the "native" resolution of the display

How would this affect physical size computations, exactly?

> But if the physical size of the display is and has been known to the OS, this is indeed mysterious.

How so?

> Once again, if this information is available why isn't it being used?

It _is_, in some cases.  If the question is why Mac OS and Windows 
endemically lie about the DPI to all consumers, I suspect that it has to 
do with precisely the sort of issue we're dealing with here: people 
making assumptions about how pt and px are related to each other and 
hence having to maintain a fiction to make those assumptions true.

> This calls for more inquiry, most definitely. Forgive my ignorance but offhand I don't know what an X server is.

<http://en.wikipedia.org/wiki/X_Window_System>, but for the sake of this 
discussion, just think "graphics card driver on a Linux system"; the 
other things X does aren't really relevant here.

> Are you saying that in Gecko, programmers can reliably query Windows for the physical dimensions of the display?

I'm saying that in Gecko, programmers can ask Windows (or whatever OS 
it's running on) for whatever information it chooses to report.  Some 
choose to report correct answers; some choose to deliberately lie...

I'd be interested in how close CSS media queries get to determining the 
actual physical size of your screen on Windows, and will try to remember 
to check when I get back to my Windows box; it seems to me that using 
LOGPIXELSY and dividing the logical height by that (which is what the 
media query code does) should in fact come out close to the physical 
height.  The physical width might be more chancy in cases when 
LOGPIXELSX != LOGPIXELSY.

Hope that helps,
Boris
Received on Tuesday, 5 January 2010 18:07:44 GMT

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