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 21:04:07 -0700
Message-ID: <CAGN7qDAS_7igkxBc6u+sG9DDLUF8=ZYSJs7R4w4BDuqQxonWpg@mail.gmail.com>
To: John Daggett <jdaggett@mozilla.com>
Cc: www-svg@w3.org, Cameron McCormack <cam@mcc.id.au>
On Sun, Oct 23, 2011 at 9:15 PM, John Daggett <jdaggett@mozilla.com> wrote:

> Rik Cabanier wrote:
> > I have a couple of remarks:
> > 1. It would be better if you can get the outline of each glyph instead
> >    of the outlines of all glyphs. The current approach will cause
> >    problems with filling if glyphs overlap.
> > 2. As a follow-on to this, maybe it would be better if given a string
> >    of text, you define an API that returns the used glyphs with their
> >    positions. Then, using the API of step 1, you can get the outline
> >    of each glyph. You can then decide yourself how you will draw with
> >    these outlines
> > 3. There should be a rule that says that the returned glyph outlines
> >    can be drawn with either evenodd or nonzero fill rules
> I have to strongly agree with Rik here, I think being able to retrieve
> individual unhinted glyph outlines along with positions would be far
> more useful in general.
> Text-to-path implementation is just plain hard.  I've personally seen
> engineers obsess over this feature and all the difficult problems
> associated with it. The real problem is that it's hard to define in such
> a way that implementations will be consistent and consistent in a way
> that designers will prefer.  When text is distorted like this, designers
> invariably want to tweak the placement.  So the question becomes not
> what the "ideal" rendering is but what's the best way to provide hooks
> that allow a designer to easily specify what's ideal *for them*. Having
> an simple API that provides a set of outlines and positions seems a far
> better
> way of satisfying that need.
> > 4. you need to define an API that checks for permissions. Not all
> > fonts allow you to convert to outlines.
> Not quite sure which permissions you're referring to but I'm guessing
> you're thinking about the notorious fsType field of the OS/2 table in
> OpenType fonts [1].  These generally are used to define what is and
> isn't allowed for embedding, they don't imply anything about whether an
> API can *fetch* the outlines or not.  There have been proposals for
> other forms of automated licensing tables but these always suffer from
> the fact that ultimately what is and isn't allowed is determined by the
> actual wording of the EULA and *not* any form of licensing bits.
that's true. Even if a vendor sets the flag, you can still get or manually
create the outlines.
I'm no lawyer, but it seems that if you design an API to get the outlines,
you also need to create an API to query for these bits. It is then up to the
designer to make sure that he's following the rules.

Received on Wednesday, 26 October 2011 04:04:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:26 UTC