[whatwg] Processing the zoom level - MS extensions to window.screen

[Charles Pritchard]

On 11/24/2010 10:23 AM, Boris Zbarsky wrote:
> On 11/24/10 4:13 AM, Charles Pritchard wrote:
>>>> > And, these aren't great lengths. It's about 6 lines of javascript.
>>> 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 
>>> N),
>>> 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
>> agnostic
>> 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 
implementations
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 
their competence.