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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
