- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 10 May 2008 00:53:51 +0000 (UTC)
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 much easier. 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 to <canvas>. > 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. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 9 May 2008 17:53:51 UTC