W3C home > Mailing lists > Public > www-svg@w3.org > April 2009

Re: units other than pixels very unprecise? (how should 'top' width/height larger than screen be handled?)

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 21 Apr 2009 12:51:25 -0400
Message-ID: <49EDF98D.20406@mit.edu>
To: Ruud Steltenpool <svg@steltenpower.com>
CC: "www-svg@w3.org" <www-svg@w3.org>
Ruud Steltenpool wrote:
> draw a 1x1 (inch) rect, getBBox it for pixel size, use resulting dpi(s) 
> and screen.width/screen.height to calculate physical screen size.
> testbed:
> Vista, Opera+Firefox
> screen that is obviously not the calculated 96 dpi (17.1" 1920x1200)

That's about my screen too.  17.2", 1920x1200.

Simple calculation shows that the actual DPI of that screen is:

   (\sqrt{1920^2 + 1200^2})/17.1 = 132.4

along the diagonal.  A slightly more careful calculation using the 
measured (with a tape measure) screen dimensions gives:

   1920 / 14.625 = 131.282 horizontal DPI
   1200 / 9.125 = 131.5 vertical DPI.

Which is all well and good, but what you're measuring is the dpi the 
browser uses to convert inches to pixels, not the actual screen DPI. 
And at least in Gecko's case, the DPI used is NOT the actual screen DPI. 
  On Windows, it's the return value of GetDeviceCaps(dc, LOGPIXELSY). 
This returns the size of a logica inch (pretty much unrelated to actual 
inches) in pixels.  The default is 96, but it's configurable via Control 
Panel last I checked.

On Mac (where the numbers I got above come from), Gecko always uses 96 
for the screen DPI value.

It turns out that websites actually depend on this behavior; something 
other than 96 typically makes sites that intermix pt and px styles break....

In any case, applying my measuring tape to that "1in" square on my 
screen shows that it's about 3/4 inch on a side.  Which is consistent 
with all of the above.

Received on Tuesday, 21 April 2009 16:52:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:17 UTC