[webkit-dev] Accept- & Content-Resolution headers proposal
robburns1 at mac.com
Thu Jun 7 08:29:02 PDT 2007
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:
> 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)
> • 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
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.
More information about the webkit-dev