[whatwg] Canvas "coordinate space units"

[Ian Hickson]

On Wed, 14 Jul 2010, David Flanagan wrote:
>
> I'm confused by the term "coordinate space units" as applied to the 
> canvas spec.  It does not seem to be defined.

It seems self-explanatory... it refers to the units used by the coordinate 
space. What is ambiguous? The coordinate space is defined earlier; its 
size is defined near the top of the <canvas> section, and its direction is 
defined near the top of the '2d' section.


> It is used in the definition of the translate() method, for example, and 
> seems to imply that coordinate space units are affected by scale() 
> operations.

Nothing is implied in the spec; if something isn't said explicitly, then 
it isn't said and doesn't apply. All that translate() does is change the 
transformation matrix.

> Are "coordinate space units" affected by scaling or not?

No.


> Are lineWidths supposed to be scaled?

Yes ("the stroke must itself also be subjected to the current 
transformation matrix").


> Are shadow offset supposed to be scaled?

No.


> I think a clearer definition of coordinate spaces would be helpful. 
> Maybe "device space" for the underlying pixmap, "canvas space" for the 
> coordinates defined by the width and height attributes of the canvas, 
> and "user space" for the space defined by the current transformation 
> matrix?

They are "device pixels", "coordinate space", and "coordinates to which 
the current transformation matrix is applied" respectively.


On Wed, 14 Jul 2010, David Flanagan wrote:
> 
> As an aside, do you think any implementations actually do that?  It 
> seems to me that it would cause real problems with drawImage(): images 
> would look bad compared to drawn graphics...

Only if they were low-resolution images.


On Thu, 15 Jul 2010, Philip Taylor wrote:
> 
> (I don't think it's clear exactly *how* the stroke will be scaled, or 
> rotated or translated or skewed etc - I'd like it more if everything was 
> specified in precise geometric algorithms, rather than fluffy prose, but 
> it seems like implementations interoperate anyway and test cases can 
> tell when they get it wrong so there's probably not much practical 
> benefit in rewriting everything much more precisely.)

Yeah. Agreed on both counts.


On Thu, 15 Jul 2010, Aryeh Gregor wrote:
> 
> Ideally, we shouldn't be relying on test-cases here.  If it can be 
> specified more precisely, it should be, if someone is willing and able 
> to write the text.  It's already been pointed out that some browsers 
> aren't interoperable on some points.

I generally try to tighten it up when they don't.

It would probably be a lot of work to rewrite this whole section; I'm 
reluctant to do that if there's not a compelling reason to (theoretical 
purity isn't compelling!).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'