[whatwg] Text APIs on <canvas>
ian at hixie.ch
Fri May 9 17:53:51 PDT 2008
On Fri, 9 May 2008, Vladimir Vukicevic wrote:
> On May 5, 2008, at 8:10 PM, Ian Hickson wrote:
> > I have introduced the following APIs:
> > context.font
> I think this should be "textStyle" -- both to match existing fillStyle/
> strokeStyle, and for consistency with the rest of the text functions.
I was about to make this change when Maciej suggested keeping 'font'...
I'll leave this open for now and see what other people think.
> > I haven't provided a way to render text to or along a path, nor a way
> > to do vertical text, nor a way to measure anything but the nominal
> > layout width of text (e.g. there's no way to measure bounding boxes or
> > get baseline metrics). I also haven't provided a way to render
> > document fragments straight to a canvas.
> Rendering text to a path or along a path are both useful operations; why
> were they omitted?
I completely agree that we want those operations.
Specifically, we want two things: rendering text along a path, and
rendering text _to_ a path.
However, with the current API, which has just one active path, it isn't
possible to draw text to a path that is itself drawn around a path. I
think it would be bad to not provide this in a generic way -- we really
just need to introduce path _objects_, at which point this all becomes
Path objects have been requested for other reasons (e.g. so that you can
stamp out different paths without having to reconstruct them each time)
and so my preference would be to delay rendering text along a path and
text to a path until such time as we have Path objects as a primitive.
I would guess that Path objects would be the next thing that we would add
> I don't think the restriction that "putImageData" must only work with
> objects returned by create/get is a good one
This restriction was made because it allows for dramatic (many orders of
magnitude) optimisations. With createImageData(), the use cases for custom
imageData objects should be catered for -- what are the cases where you
would need another solution? (Note that hand-rolling imageData objects is
dangerous since you don't know what resolution the backing store is using,
necessarily, which is something else that createImageData() solves.)
> but it would be good to have some way to mark sections of the spec as
> stable/unstable --
I've gone through and added annotations for each of the canvas sections to
distinguish the stable parts from the unstable parts. Does that work?
> otherwise someone's liable to take a snapshot and implement it, and then
> have it change under them if a portion is still in flux.
In general, the spec is unlikely to change significantly _before_ the
first implemenation. We get more feedback from the first implementation of
anything than from people just looking at the spec. I agree that the first
implementation should know what it's getting itself into, though. :-)
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg