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

Thu Jun 26 12:30:07 PDT 2008

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

------- Comment #24 from robburns1 at mac.com  2008-06-26 12:30 PDT -------
Much of this bug discusses resolution independence. I apologize if I'm
misinterpreting this, but the resolution independence team at Apple says that
applications using an NSView should treat the units of the NSView as points. So
72 points equals one inch (again keep in mind that with resolution independence
this has got nothing to do with DPI at this point which is handled at a
different level separate from WebKit in a resolution independent world or a
resolution independent redefined world).

(In reply to comment #23)
> I also think you're making assumptions about how resolution independence is
> going to work in WebKit on OS X.  Our own thinking about it was that the CSS
> pixel would scale.  In other words as the view scale changes, so does the CSS
> pixel scale.  The ratio of 96dpi would still be preserved (thus absolute units
> would scale as well).  Given that information, maybe you can clarify what you
> want.

 Yes, I understand that the units will scale as well. However, the treatment of
WebView units as 75% of a point instead of as 1 point means that the scale of
WebViews is different than all other NSViews (and all other views) on the
system. So when you draw a ruler using CSS units it will be a different size
than the ruler drawn in an NSView using NSView units. It creates an
inconsistency between apps that is jarring to users and unnecessary. Having
said that I do understand that the scale of text and such in webpages is such
that web authors are already compensating for this difference so that authors
might use smaller fonts in web pages than in other pages because they get
scaled up by systems already (due to IE most likely).

(In reply to comment #21)
> Then I recommend filing a seperate bug. It seems like you are changing the
> original purpose of this bug. I intended it to be about asking for 1cm and
> getting 1cm on the output medium, not what you seem to want, which is asking
> for 1cm and getting the same result as other on-screen NSViews would produce if
> asked for the same. You're not bothered if it's 1cm or some other scaled value,
> I gather?

I'm a bit uneasy with bringing up this example, but it seems apt here. What
about the case of projection media in a large conference halls or television
media in someone's home theater. Here even more than computer displays users
prefer to have things scaled at other than 100%. Isn't it better that one inch
in InDesign is equal to one inch in Safari (or another WebKit application)? Why
should the WebKit application always maintain a 100% scale no matter how the
user changes her preferences.

> 
> I envisage something like this:
> 
> [webView scaleForInternet] -> sets WebKit to 96 DPI
> [webView scaleForDesktop] -> sets WebKit to 72 DPI  (this is what you want,
> Robert)
> [webView scaleForMainDisplay] -> sets WebKit to DPI of main display
> [webView scaleToCustomValue:133.33] -> for 17" MBPs
> [webView scaleToCustomValue:160.0] -> for iPhones
> 

Just to clarify what I want has got nothing to do with DPI at all. I'm pushing
for better understanding of resolution independence and for more consistent
implementation of resolution independence. Resolution independence implies that
pixels dependent units are not used at all. By defining a pixel as 1/96 of an
inch (which CSS 2 does) even a pixel is now a resolution independent unit
(because it is not a pixel at all anymore but a unit that is always in the same
ration with an inch).

I think one has to consider what a truly resolution independent device will
look like from a developer and web authoring point of view and think backwards
to where we are now (which is what I think the resolution independence team at
apple is doing).

In that world every view is measured in points as floats (or inches or mm or
cm, etc). Only low-level developers and those using OpenGL need to ever concern
themselves with pixels and device resolution.  Once were at that point, it
doesn't concern any of us (as webkit developers or as web site developers) what
the resolution of a display is because we're now firmly in the resolution
independent world (everything is in terms of absolute units even pixels are
absolutely 1/96 of an inch).

Ideally similar applications should display their content at the same scale
(whatever the OS default is or whatever the user selects). The scale no longer
changes as the bit resolution of the screen increases. If a user likes a 133dpi
17" display at 70% of full scale, then when the user switches to a 500dpi 17"
display they will likely continue to want the scale at 70% of full (though the
users preferences may be effected in subtle ways by the drastically increased
resolution; they're more likely concerned about the obvious screen real estate
than the subtlety of the resolution).

Obviously apps such as Google Earth will not be at 70% of full scale (where one
mile equals 0.7 miles :-). But for like applications, that deal with NSRulers
for example, should all be consistently scaled (or it disorients users).

The issue Nick raises on the scale on the screen is then up to the user. If
they want their display at 100% scale, then they will set it at 100% scale. In
that circumstance a physical ruler held up to an NSRuler will match. The same
physical ruler held up to an NSRuler accompanying a WebView will not match
(since a WebView currently does not follow the resolution independence team's
guidelines on resolution independence). However, the WebView difference aside,
it is really up to the user how they want the display scaled (once we're fully
resolution independent). It should not be up to the WebView to maintain 1 inch
equals to 1 inch as the user scales the rest of the display in a vastly
different scale (like to 50% or 25%, 300% or so on). So fixing the bug I
thought this was about is completely at odds with fixing the bug Nick says this
is about.

What I want to see is better adherence to resolution independence. What the
other approach does is disregard the users preferences for on screen scale and
maintains WebViews at 100% even as the scale of everything around it shrinks or
grows drastically. That would be the wrong approach in my opinion.

How to get authors to stop authoring to IE inappropriate scaling precedence is
a completely separate problem, though a solution to that too improves
resolution and device independence because it makes it easier to create output
that works with the same stylesheet declarations whether on high resolution
printer or high-resolution display.

-- 
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.