On Tue, 25 Dec 2007, Ilmari Heikkinen wrote:
Some comments on the canvas spec, based on my experiences in writing a
SVG renderer and some interaction demos on canvas
(http://glimr.rubyforge.org/cake/canvas.html)
Cool stuff.
I would change the transforms to affect only path segments, fills and
strokes done _after_ the transform. Currently, Firefox and Safari apply
transforms that way, but Opera's transforms also affect the points
created before the transform.
This would make path construction easier and would also make it possible
to emulate pattern-space transforms (to some degree) by applying
transforms after the path creation, but before fill / stroke. Though, it
doesn't quite work, as the transform affects the stroke width as well...
Already done.
...so there is a need for pattern space transformations. Which would be
a transformation matrix applied after creating the stroke/fill geometry,
but before filling in the pattern/gradient. The pattern space transform
matrix should be a property of the pattern object, and the pattern
object could also have #translate, #rotate, #scale, #transform and
#setTransform.
You can do that now by rendering your pattern with a transformation to
another canvas, and then using that canvas as the pattern for your actual
target canvas.
The wording in isPointInPath is confusing. Are isPointInPath coordinates
user-space coordinates or device-space coordinates? Are they coordinates
transformed by the CSS transformation matrix for the canvas tag?
E.g. if there's a one-pixel size square at 10,10 on the canvas, does
isPointInPath(10,10) return true for it? What if the canvas is CSS
scaled to 200% size? How do you find out the CSS matrix?
The new text should make this clearer -- let me know if it's still vague.
There's no getTransform(). I'd go with
ctx.setTransform(ctx.getTransform()) being a no-op, and there being a
way to get the transformation matrix for the canvas surface as well
(i.e. the CSS transformation matrix for the canvas.)
My understanding is that it's not always possible for implementations to
actually obtain the transformation matrix easily (short of caching it
independently of their rendering subsystem).
The goal here being the ability to map mouse coordinates to user-space
and back, along with the ability to align HTML elements and canvas
objects.
Actually for that kind of thing I'd recommend SVG -- media-specific
rendering (e.g. aligning markup with canvases or images) is specifically a
non-goal for HTML5.
Canvas features needed by the SVG renderer:
An SVG renderer is definitely a non-goal for canvas. Just use SVG. :-)
* A text API with: CSS style object as ctx.style (not string), text as path,
text along path [as path], font metrics, text selection path with text
bbox rectangles (for use with isPointInPath.)
Text APIs will be handled at some future point. See:
http://whatwg.org/issues/#graphics-canvas-text
If you don't see your specific needs covered by those e-mails, please send
additional feedback.
[a variety of feature requests]
There are indeed a large number of features that could be added. At this
stage, we should focus on getting interoperability on the existing
featureset. If there are specific features that you would need for
specific purposes (e.g. people have asked for dashed lines for diagrams,
and for text for chart labels) then please do suggest them (along with the
use cases and examples of why it's impossible or at least very hard to do
without the feature), so I can add them to the v3 feature list.
(And views on what Canvas text will be used for:
* Spiffying up HTML titles and leaving the HTML element above the canvas at
zero opacity == selectable spiffy text. Requires exact HTML element
rendering on Canvas.
* Text art. Needs text-as-path and text-along-path.
* Titles for canvas elements. Needs a way to align text vertically and
horizontally (== font metrics and string dimensions.)
* Writing a SVG renderer with selectable text. Needs text-as-path and
text-along-path, and a fast text picking path.)
None of those are really the intended use cases for canvas. :-)
Indeed for most of those, I would recommend using SVG, possibly, in the
future, with XBL.
Cheers,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
