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: Sun, 23 Oct 2011 21:44:58 -0400
Message-ID: <CAGN7qDB=ODtx=PHOP9Xkuy5CbEGmUtfSkx_ACPdYybWAmZFuUA@mail.gmail.com>
To: Dirk Schulze <vbs85@gmx.de>
Cc: Cameron McCormack <cam@mcc.id.au>, www-svg@w3.org
On Sun, Oct 23, 2011 at 2:22 AM, 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.
>

It sounds like you need to invest in a cross-platform font rendering library
:-)


>
> 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?
>

I think we need a new API where you can ask the font for a glyph outline. In
that case, the resulting value should not be transformed.

>   // 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.
>

I agree


>
> 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 Monday, 24 October 2011 01:45:27 GMT

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