- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 21 Oct 2011 15:18:00 -0400
- To: Dirk Schulze <vbs85@gmx.de>
- CC: www-svg@w3.org
Thanks for the questions, Dirk.
On 21/10/11 2:59 PM, Dirk Schulze wrote:
> This should work independent of the used font / font type? WOFF, SVG
> Fonts, OpenType,... for all types?
Good question. Obviously for complex glyph SVG Fonts you have more than
just an outline, so this API is inadequate for that. But otherwise, I
would expect this to work for any outline font format.
> Should this work with texts on paths as well?
Yes.
> What do you expect for benefits, when do we need that?
So that authors can use script to perform their own processing and
effects on text. In writing a demo to do some warping of text along a
path, I needed the path data for the text. I instead had to open
Inkscape, convert my text to a path, and embed the path data in my
document. That's not going to work for text chosen at run time.
> I know that Gecko supports it for HTML Canvas, but I never saw an
> example that uses that.
You can do ctx.mozPathText("Some text") to set the current path to be
the outline of the text, but I don't know that you can get the path data
back out again can you?
> I should mention that it would be very hard to implement it in WebKit
> and some ports may never be able to use that.
Details of the difficulties would be useful.
> How do you determine the path segments of a glyph?
Whether you would be required to return the exact same path segments for
the same font and text across implementations is a good question. It's
a similar issue to what normalizedPathSegList should return.
> It must be transformed to SVG Path syntax somehow and I am not sure
> how we get similar results across implementations for
> SVGPathSegList.
You are right that there is a risk there of sites ending up depending on
particular path data coming out of the API for a given font.
Received on Friday, 21 October 2011 19:19:04 UTC