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

[Rob Burns]

On Jun 7, 2007, at 8:27 AM, Nicholas Shanks wrote:

> It has been mentioned on the Safari WebKit development mailing list  
> that a HTTP header which specified a document's target resolution  
> would be useful to allow clients to negotiate for high-res or low- 
> res artwork and CSS referring to such (background-image, and the  
> like), depending on their screen pixels, printer resolution, etc.
> I would like to propose this to the Working Group.
> My ideas are as follows:
>
>
> The client (a laptop, say) requests -
>
> GET /style/default HTTP/1.2
> Host: example.com
> Accept-Content: text/css, text/dsssl, text/xsl
> Accept-Resolution: 116.66 dpi
>
>
> The server has the following to choose from:
>
> default.72dpi.css
> default.144dpi.css
> default.288dpi.css
> default.2400dpi.css
>
>
> 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)
>
>
> Furthermore:
>
> • Images served with a Content-Resolution header could have their  
> resolution trusted (most web browsers today display one pixel on  
> screen per pixel in the bitmap, and ignore the image's internal  
> resolution parameter, if one exists). If they don't match, probably  
> best to use the image's internal one. There could also be a special  
> "Content-Resolution: auto-adjust" header meaning that the server  
> doesn't know the resolution at content-negotiation time, but wants  
> the client to scale it according to the image's internal value  
> anyway, and not do a pixel-to-pixel mapping.
>
> • A "dpcm" (dots per centimetre) parameter could also be understood  
> by both ends and converted as necessary.
>
>
> What do people think? I've only spent an hour or so pondering this,  
> so it won't be bulletproof yet.
>

That's a responsive proposal process. Thanks for picking up on that.  
Let me just add a few of my own thoughts on how I think this should  
work.  Imagine three different clients all loading the same document  
over http. Also imagine that all dimensions are specified in physical  
dimensions (pixels complicate things and they're a moving target in  
terms of software interpretation)..

* The document includes an image with dimensions 6 inches by 4 inches.
* The clients are
     - 1200 DPI printer printing via url request at 100% zoom
     - Firefox on a 96dpi display at 67% zoom
     - Safari on an iPhone with 160dpi display at 50% zoom


Each cleint calculates the resolution based on its current zoom (in  
other words base magnification) level (clients could get more  
sophisticated and request based on expected zoom level if it expects  
to change while displaying the image; but that should probably be  
left out of the spec). Following your suggestion, each client always  
rounds up to the next integer value and returns the pixel dimensions  
(both width and height). So for each client

     - 4 inches at 100% on a 1200 dpi display equates to 4800 pixels
     - 6 inches at 100% on a 1200 dpi display equates to 7200 pixels

     - 4 inches at 67% on a 96 dpi display equates to 258 pixels
     - 6 inches at 67% on a 96 dpi display equates to 386 pixels

     - 4 inches at 50% on a 160 dpi display equates to 320 pixels
     - 6 inches at 50% on a 160 dpi display equates to 480 pixels

Basically each client multiplies its device resolution by its base  
zoom level and returns its effective ppi resolution.

So I think the content negotiation should look more like (for the  
iPhone for example):

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 80 ppi


So for resolution independence we want authors to specify dimensions  
in absolute (physical) units. However content negotiation of bitmap  
related content should be based on ppi. If the display is stretched  
in any way perhaps the protocol should allow for two ppi dimensions  
to reflect the different horizontal and vertical ppi resolutions.

Hope this is clear.

Take care,
Rob