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.

-Boris

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:29:40 UTC