- From: Michael Day <mikeday@yeslogic.com>
- Date: Tue, 21 Aug 2012 13:15:07 +1000
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: whatwg@lists.whatwg.org
Hi Rik, > Yes, that is one way of implementing it. This is not specific to arcTo; > this happens with all drawing operators. It is not quite the same with other drawing operators, for example: ctx.setTransform(...T1...); ctx.lineTo(100, 100); ctx.setTransform(...T2...); ctx.lineTo(100, 100); This will draw a line from T1*(100,100) to T2*(100,100), and these points can be calculated immediately in absolute canvas coordinates, there is no need to apply any inverse transformations. For arcTo, it's much less obvious how the arc should be generated from the three control points, when the first control point is transformed by a different matrix to the last two; in this case you cannot just remember the three points in absolute canvas coordinates, but the specification does not clarify this. > I don't know. It just depends how they implemented in. They might apply > the CTM to all the coordinates or keep the coordinates and pass them > along with the CTM to the drawing system. In our case we are rendering to PDF, which cannot change the transformation matrix halfway through a path. Even if it could, it does not support arc primitives. But anyway, regardless of the exact details of how the browsers implement it, there is the question of how to describe the algorithm to someone such that it can be "implemented" with pencil and paper. Currently it is very non-obvious how arcTo should work when a new transform has been applied since the last drawing command. Best regards, Michael
Received on Tuesday, 21 August 2012 03:15:37 UTC