- 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