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

Re: text to path conversion API proposal

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 25 Oct 2011 20:59:42 -0700
Message-ID: <CAGN7qDAX7YQwq-of+MDr3QqBf1v1tagH18OVcWoyfXX07RGMnA@mail.gmail.com>
To: Dirk Schulze <vbs85@gmx.de>
Cc: Cameron McCormack <cam@mcc.id.au>, www-svg@w3.org
Hi Dirk,

I asked around and it seems like FreeType should be able to create outlines
for you. Of course, to have a complete match, you'd also have use FreeType
to render text to the screen.
>From reading the chrome wiki, it looks like you already compile it as part
of skia but it is currently unused.

Do you have any plans to go with that library instead of the OS?

Rik

On Sat, Oct 22, 2011 at 11:22 PM, Dirk Schulze <vbs85@gmx.de> wrote:

>
>
> 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 Wednesday, 26 October 2011 04:14:32 GMT

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