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 22:25:15 -0400
Message-ID: <CAGN7qDDmesjqxwVoXaeT4F27wqe3otv4Vv_pO7KAAp5EaCxSzA@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: www-svg@w3.org
On Sun, Oct 23, 2011 at 12:31 PM, Cameron McCormack <cam@mcc.id.au> wrote:

> On 22/10/11 6:27 PM, 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.
> Hmm, yes, good point.  I guess that complicates the return value a bit.
>  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
> How would the "used glyphs" be returned, or would they not be identified
> beyond just an index into the list of glyphs that was finally laid out?
>  // returns an Array of SVGPoint objects
>  var glyphPositions = textElement.getLayout();
>  var glyphPaths = [];
>  for (var i = 0; i < glyphPositions.length; i++) {
>    glyphPaths.push(textElement.**getGlyphPath(i));
>  }

It would be a new abstraction for a glyph. Not every character of your input
can map to a single glyph (= n-to-m mapping).
The Glyph would point to a singular entry in the font and you would get back
a list of them.

> Not all glyphs are going to be just plain glyph data from the font painted
> at a particular point.  Stretching, rotation, warping due to text-on-a-path
> (if we go down that road), etc. can occur.  I think then the glyph position
> starts to make less sense.  So maybe it is simpler just to have the position
> already accounted for by the returned path.

If you want to do this for text on a path, I agree that a simple x/y won't
work. Maybe a matrix per glyph would do?

>  3. There should be a rule that says that the returned glyph outlines can
>> be drawn with either evenodd or nonzero fill rules
> Do you mean the spec should state that the returned paths must look the
> same if painted with evenodd or nonzero?  Or that it should be author
> controllable?  (The former makes sense to me.)

look the same if painted with evenodd or nonzero.
I believe postscript based fonts already have this rule, but if you need to
generate the outlines yourself (ie truetype), you need to be aware of this.

>  4. you need to define an API that checks for permissions. Not all fonts
>> allow you to convert to outlines.
> For this API, I think this is only something we need to worry about for
> locally installed fonts which are used in the document.  And at first glance
> this seems a more confusing situation wrt font licenses than actual
> publication of documents with embedded or referenced external fonts.
> I am not particularly in favour of building in restrictions to these APIs
> that make them look at fsType values to determine what should be allowed to
> be returned.  But let's discuss this in person next week.
Received on Monday, 24 October 2011 02:25:43 UTC

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