[HarfBuzz] Better handling variation selectors

[Jonathan Kew]

On 19/4/13 22:13, Behdad Esfahbod wrote:
> Konstantin has brought up a few interesting issues regarding variation
> selectors.  I'll summarize issues that I think can be improved:
>
>    - Right now we don't handle a sequence of multiple variation selectors in a
> row.  What *is* the best way to handle that?  Ideally the extra ones should
> become visible.  Even a box is better than silently not showing them, right?

No - silently not showing them should be the default behavior, IMO. 
They're default-ignorable.

>
>    - Now, Unicode says only registered variation sequences are valid.  I assume
> we don't want to enforce that?

In principle, it would be correct to enforce it - e.g. by only passing 
the VS to get_glyph if the <char,VS> pair is registered - but I'm not 
sure it's worth the overhead of maintaining the list of registered 
sequences and checking each VS occurrence we encounter.

>
>    - What should HB_BUFFER_FLAG_PRESERVE_DEFAULT_IGNORABLES do to variation
> selectors?  Right now they do not become visible no matter what.  Is it
> relevant whether the variation selector was actually used during glyph lookup
> or not?

Yes, I think it's relevant. A variation selector that was used during 
glyph lookup has (in a sense) become "visible", manifested as a 
particular choice of glyph. I don't think it should -also- appear as a 
separate glyph, even in a "show invisibles" mode. In effect, the <base, 
VS> pair has been ligated - it's just a "ligation" that's handled by the 
cmap instead of GSUB.

Any variation selector that was -not- part of a valid sequence - e.g. if 
there are multiple VS chars after a base - should ideally be preserved 
by PRESERVE_DEFAULT_IGNORABLES.

The remaining question is what to do about a VS that was part of a valid 
sequence, but the font being used didn't handle it. That's a slightly 
different case than a VS used in an invalid way, which represents an 
encoding error in the data. I suppose PRESERVE_DEFAULT_IGNORABLES should 
probably make this case visible as well, though.

>
>    - If the answer to the last question of the previous item is yes, then we
> would new to change get_glyph() API to two separate get_glyph_variation() and
> get_glyph() calls.  But that would be an API and ABI break :(.  Thinking about
> it now, I wish I had done that from the beginning.