Re: text to path conversion API proposal

Hi John,

On 23/10/11 9:15 PM, John Daggett wrote:
> 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.

Are you talking about text-to-path like SVG's <textPath>, or 
text-to-outlines?  The proposal is just about the latter, so that 
effects beyond what SVG defines for <textPath> can be achieved through 
script.

My thinking is just that if the implementation already has to perform 
text-on-a-path due to <textPath>, then I don't see why I shouldn't be 
able to get the path output from that as well as for regular on-a-line text.

For example if I had

   <text>abc def</text>
   <text>ghi <textPath d="...">jkl</textPath> mno</text>

I wouldn't want to unnecessarily restrict the API so that it could 
return outline paths for the first <text> elements but not for the second.

I agree that getting the outlines for <textPath> affected text isn't as 
useful for my use case here, so if there are indeed good reasons for 
leaving that out, I can live with that.

Received on Monday, 24 October 2011 22:21:31 UTC