Re: text to path conversion API proposal

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.

Regards,

John Daggett

Received on Monday, 24 October 2011 04:15:50 UTC