[HarfBuzz] handling of variation selectors

[Jonathan Kew]

On 3/7/13 17:03, Behdad Esfahbod wrote:
> On 13-07-03 06:21 AM, Jonathan Kew wrote:
>> On 3/7/13 00:51, Behdad Esfahbod wrote:
>>> On 13-07-02 09:58 AM, Jonathan Kew wrote:
>>>>
>>>> This will work fine for fonts that actually expect to handle VS codes in this
>>>> way. The trouble is that in many cases, the VS codepoint will -not- be mapped
>>>> to a suitable glyph code by the cmap; it will simply map to the .notdef glyph,
>>>> which will then appear as a box or similar unwanted artifact in the output.
>>>> (It would also -block- GSUB/GPOS rules from applying as expected to the base
>>>> and any following glyphs.)
>>>>
>>>> So in the case where the font does not actually map the VS codepoint to a
>>>> glyph, we should simply delete it from the buffer.
>>>
>>> My expectation was that even such .notdef will be marked default-ignorable and
>>> hence 1) not block GSUB/GPOS, and 2) be removed after shaping is done.  So,
>>> why is that not working?
>>>
>>
>> Argh -- I figured it out, after looking in all the wrong places for the
>> problem.....
>>
>> The issue arose in a testcase we have in the Gecko tree that uses a "toy" test
>> font that happens to lack a <space> glyph. And therefore
>> hb_ot_hide_default_ignorables(), which relies on having a <space> glyph
>> available, doesn't do anything to hide the VS in this testcase, and so our
>> test fails.
>
> Ok, that explains...
>
>> So I think we can safely ignore this, given that it's such an artificial
>> testcase; no need to hack around it in harfbuzz, we'll just fix our test.
>
> Should we remove the glyph if space is not available?

I suppose we could - or maybe we could just unconditionally remove 
instead of replace it. (Though that would be marginally less efficient 
in many cases, I expect. OTOH, it would make subsequent operations such 
as painting the text do less work.)

No strong opinion here, though. If you want to just leave it as is, I 
think that's OK too.

JK