W3C home > Mailing lists > Public > www-svg@w3.org > October 2011

Re: text to path conversion API proposal

From: Dirk Schulze <vbs85@gmx.de>
Date: Sun, 23 Oct 2011 08:22:38 +0200
Cc: Cameron McCormack <cam@mcc.id.au>, www-svg@w3.org
Message-Id: <FD3B25FF-9147-4DBD-9177-866D861D40F9@gmx.de>
To: Rik Cabanier <cabanier@gmail.com>


> I agree that it is hard, but it's not impossible. We (= Adobe) can do it for almost all font types (except maybe bitmap fonts which are not used very often). 
> 
> Doesn't WebKit rely on the OS for font layout. The hard part for you would be to match your calculated outlines with the OS's.
At first it is correct: We rely to the different implementations, Qt, GTK/Cairo, GDI and so on. At least for all fonts but SVG Fonts. Creating an infrastructure to get path data from single glyphs is possible, but we don't get reliable from all platforms and some may not provide information at all. For instance Qt had bigger problems with calculating the font stroke outline in the past.

And I'm pretty sure that we will never get same path results across platforms. But I assume that platform independent results are needed by web developers who want to use this feature. Or is that not so important? On WebKit I can just guarantee that for SVG Fonts, because the path data of every glyph is already known and independent of the various WebKit ports.

Should the path data of every single glyph include all transformations (scaling, rotating, stretching)? I think that this makes most sense. In which userspace are the information provided? In the userspace of the <text> element?
  // Return an SVGPathSegList representing the entire geometry of the text content element,
  // including glyphs and decorations.
Why should the path data include text decorations like underline, line-through and overline? Can't web developers add these data them self? I would expect that the normal glyph data (with font styles) are more important.

Dirk

> 
> Rik
> 
> On Fri, Oct 21, 2011 at 2:59 PM, Dirk Schulze <vbs85@gmx.de> wrote:
> This should work independent of the used font / font type? WOFF, SVG Fonts, OpenType,... for all types? Should this work with texts on paths as well? What do you expect for benefits, when do we need that? I know that Gecko supports it for HTML Canvas, but I never saw an example that uses that. I should mention that it would be very hard to implement it in WebKit and some ports may never be able to use that. How do you determine the path segments of a glyph? It must be transformed to SVG Path syntax somehow and I am not sure how we get similar results across implementations for SVGPathSegList.
> 
> Greetings
> Dirk
> 
> Am 21.10.2011 um 20:18 schrieb Cameron McCormack:
> 
> > I started writing up a proposal for an SVG text to path conversion API:
> >
> > http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_to_path_API
> >
> > Comments welcome.
> >
> 
> 
> 
Received on Sunday, 23 October 2011 06:23:42 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:49 GMT