[HarfBuzz] handling of variation selectors
behdad at behdad.org
Wed Jul 3 09:03:12 PDT 2013
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
> 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?
More information about the HarfBuzz