Re: proposal for text layout with positioned glyphs, anchoring and bidirectionality

Cameron McCormack wrote:

> SVG text with positioned glyphs, anchoring and bidirectionality is
> greatly non-interoperable and somewhat underspecified.  We have
> discussed some aspects of this in a couple of threads on the WG mailing
> list over the last week or so:
> 
>   http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0062.html
>   http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0082.html
> 
> I want to make a proposal for defining text layout behaviour in these
> cases.  Comments and suggestions (particularly any suggested
> simplifications) are welcome.
> 
>   http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_layout

I think there's a fundamental problem with this feature and the way it
was originally designed. It really should have been veto'd long ago
because there's no way to make this work correctly for complex scripts
and it's based on the naive model of text layout where all characters
map to a single glyph and are placed sequentially along a run of
text.

The key problem is that you're attempting to map *glyph* advances to a
string of *characters*. Text layout typically involves taking a string
of characters and turning it into an array of glyphs with associated
positions (i.e. *both* x and y advances).  For characters in the ASCII
range, where there's generally a one-to-one correspondance between
glyph and character but once you include support for complex scripts
(e.g. Arabic, Devanagari, Thai) that is no longer true. Likewise, base
characters with combining characters produce similar problems. 
Consider the case of 'A' followed by combining-ring (U+030A).  A
layout engine might resolve this to two glyphs, one for the 'A' and
one for the ring, or it might produce a single glyph if the font only
contains glyphs for precomposed codepoints. Which one it chooses will
be dependent on the font used.  Ligatures and any sort of contextual
alternates (see CSS3 Fonts for more details) present similar problems,
whether the layout engine uses a single glyph or multiple glyphs is
based on the combination of CSS attributes and available font features.

So I would say any feature in SVG like this needs to refer to
clusters, not glyphs, at a minimum.  I would actually suggest not
trying to "solve" the internationalization problems with this feature
since they are basically intractable given the model used.  If the SVG
group doesn't want to deprecate this feature, then I'd say it would be
best to put a warning note that this feature will break in the
presence of complex layout, rather than trying to define it in a way
that overrides the results of complex layout.  The latter is hard and
in the end, probably a fruitless effort.

Regards,

John Daggett
Mozilla Japan

Received on Wednesday, 22 June 2011 02:37:43 UTC