Re: [webkit-dev] Accept- & Content-Resolution headers proposal

Heh.

DPI is a useless measure of resolution, unless it is based on an
expected distance to the screen.

Take a projector: maybe 10-20DPI, but viewed from 3-20 meters.

Take the OLPC screen: 200DPI, 1200x900, 7.5" diagonal.  But 8 year old
kids are much smaller than we are, so they will be somewhat closer to
the screen.  Still effectively a bit higher resolution than most
people's big laptops, but not radically.  As it stands now, we have to
use Gecko's new scaling features to have decent behavior.

If you are going to deal with this, note that the *number of pixels*,
and the *angular resolution* are the parameters needed to actually
choose a style sheet reasonably. DPI by itself is useless. You just
aren't going to get as much on a high resolution, but very small screen
as you do on a big one with 4-10x the number of pixels.  And you may
need to do very different layout and font choices.
                                 - Jim


On Thu, 2007-06-07 at 15:29 +0000, Peter Speck wrote:
> 
> 
> 
> Hi,
> 
> > Accept-Resolution: 116.66 dpi
> > ...
> > In this instance, the 144 DPI stylesheet would be returned, because  
> > it is the next size up, with a header:
> >
> > Content-Resolution: 144 dpi
> >
> > The client would thus know there was a resolution mis-match and  
> > (optionally) perform a correction on the CSS values.
> > (the mechanism assumes higher is better, and scaling down is  
> > preferable to scaling up from 72 dpi. Apple's iPhone has a screen  
> > resolution of 160dpi, and so would get the 288dpi stylesheet, even  
> > though the 144 is a closer match, and the laptop with a web page  
> > zoom of 200% would request 233.33 dpi)
> 
> Why force a "next size up" if most UAs prefer a dpi which is "close  
> enough"?
> 
> All the other Accept-XXX headers (except Accept-Ranges) uses a  
> wildcard if other values are accepted, e.g. (RFC 2616)
>    section 14.2:  Accept-Charset: iso-8859-5, *
>    section 14.3:  Accept-Encoding: gzip, *
>    section 14.4:  Accept-Language: da, en, *
> 
> All 3 supports adding a "quality value which represents the user's  
> preference for that charset/...".  Could this be used to allow the UA  
> to tell the server if it wants a "higher up" or "closest"?
> 
> 
> I assume this would be used too when printing a web-page, so the  
> printed output can use high-resultion images.  (I've implemented a  
> page which uses high-resolution GIFs for icons, and it is a pita to  
> maintain).
> 
> But how are the browser going to know which files it should re- 
> request when printing the page? All, or only those with a "Content- 
> Resolution"?
> 
> > • A "dpcm" (dots per centimetre) parameter could also be understood  
> > by both ends and converted as necessary.
> 
> As a web-server implementor, I would prefer keeping the standard as  
> simple as possible (i.e. KISS), especially with options almost no  
> browsers are going to use. Your scheme for selecting the proper css  
> file works spendid with dpcm values converted to dpi.  If a webserver  
> wants to support .css files named using dpcm, e.g. "default. 
> 30dpcm.css", that's fine, but don't make the protocol more complex.  
> Continuing with this, I would remove "dpi" from the header value, and  
> simply define both headers value to be dpi.
> 
> ----
>     - Peter Speck
> 
> 
> 
-- 
Jim Gettys
One Laptop Per Child

Received on Thursday, 7 June 2007 18:06:38 UTC