[Webkit-unassigned] [Bug 11644] Absolute lengths assume 96.0 DPI

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=11644





------- Comment #15 from robburns1 at mac.com  2008-06-25 11:58 PDT -------
Resolution independence isn't really here yet anyway, so the difference is size
is not something that is directly fixed by resolution independence nor involved
with anything you're seeing today. But I do think this could be fixed once
resolution independence does arrive.

Consider this:

A 96dpi screen right now treats 1 CSS inch as 1 physical inch. Or in the
WebView, 1 physical inch is 96 units (CSS pixels)

However, in NSView coordinates that 1 inch is 72 units wide 72 or points. On a
96dpi screen then (without resolution independence), 1 inch is 0.75" measured
with a physical ruler. In other words the base zoom of the screen is 75%.

So the NSView one inch wide cannot both be 72 units and 96 units at the same
time. The way to think about this is the following:

 * WebView has an internal zoom factor set so that it is 133% larger than the
OS zoom factor.
 * With resolution independence the OS will scale the display according to the
users needs (ideally with user defaults permitting adjustments)
 * on modern displays (e.g., 111 dpi) the OS scales the output to about 65% of
actual size
 * WebKit scales its inner-application output to 133%
 * together that's about 85.45% of actual size (so the comment #12 example 8cm
becomes 6.8 cm when measured with a physical ruler on the display)

So in order to fit in with upcoming resolution independence on Mac OS X (and
presumably other OSs I"m less familiar with), a WebView simply needs to add a
method to set and get its base zoom factor. By default it should be 1.33x so as
to not break web sites (as Dave points out). However, other applications may
want to set it to 1. When setting the factor to another value an affine
transformation is set on the WebView to scale it accordingly. Internally this
could only scale when the value is set to something other than 1.33x so as to
not cause any performance hit for mainstream web use (the magic of OOP and
opaque methods). Eventually, though when resolution independence becomes more
widespread and users start widely varying the base zoom of their displays, it
may not at all seem unusual for WebKit to display using a zoom of 1x instead of
1.33x.

However, it doesn't seem like a good idea to leave something as central as
WebView as incompatible with the resolution independence of the rest of the OS.

Are there any problems caused by this solution that I have missed?


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.