[whatwg] Processing the zoom level - MS extensions to window.screen
chuck at jumis.com
Wed Nov 24 10:26:33 PST 2010
On 11/24/2010 10:23 AM, Boris Zbarsky wrote:
> On 11/24/10 4:13 AM, Charles Pritchard wrote:
>>> Uh... That depends on how your drawing path is set up. If I understand
>>> correctly what you're doing, you have to get the DPI ration (call it
>>> change the canvas width/height by a factor of N, and change all
>>> coordinates in all your drawing calls by a factor of N, right?
>> You're correct, I grab DPI, lets call it xN and yN, I change the canvas
>> width height.
>> Then I run .scale(xN, xY) before my drawing calls. They're completely
>> to the change.
> Ah, I see. I assumed you were actually trying to draw the fonts at
> the right size for the viewer, see, as opposed to doing an image
> upscale of text rendered at a smaller size.
You're right, font sizes do need to be managed separately in most
as scale does not apply to the font size.
>>> My faith in canvas coders is closer to 0.2 (on a 0-1 scale), largely
>>> because it's not quite as mainstream yet, so only the more competent
>>> folks are doing it.
>> I hope you have more respect for other parts of your user base.
> What does this have to do with respect? Canvas coders are just trying
> to get something done, as are browser users.
> Browser users tend to not be experts on browser stuff. Neither do
> canvas coders, for the most part (largely because no one is in a
> position to really be an expert on all the various parts of a browser
> at this point). I certainly don't claim to be one.
> But the upshot is that people make mistakes. If you don't assume they
> will, you come to grief.
Assuming they'll make mistakes is different than having zero faith in
More information about the whatwg