face index vs instance index, and where they apply

[matthiasclasen]

In pango tests, I recently noticed that we happily pass 262144 as index to hb_face_create, and get it back from hb_face_get_index().

But hb doesn't seem to do anything with it, since it is not actually a face index, it is a shifted instance id that we've gotten from fontconfig's FC_INDEX field, which is directly populated from freetype's index value.

I think some documentation would be in order on face index vs instance index, what can be passed where and what will be accepted.

As it is currently, it seems unclear if passing 262144 to hb_face_create will apply instance coordinates or not. Maybe >16bit face index should be an error ?

[behdad]

A few different things here:

• The mixing of face index and named-instance index into one number is just a fontconfig thing. It doesn't come from freetype directly even. So I don't think it belongs in our documentation.

• The fact that HB ignores it, instead of failing to load the face, also has some historical background: for faces in a mac dfont resource, freetype sets face index to index within dfont while the face exposed is a regular ttf. If HB was to fail with non-zero face-index, we would be failing such faces.

• Another point is that when you call hb_face_set_index() HB does no validation whatsoever. setter/getter's are always paired in HB. Value is only used lazily when any loading happens.

Now, what I suggest we do, is that when loading a TTC, we mask and only use the lower 16bit of the index. That way you can pass FC_INDEX intact and HB uses the part it needs, and if you get it back from HB you can still use the top bits for instance index setting. We would document this in the API.

[matthiasclasen]

Now, what I suggest we do, is that when loading a TTC, we mask and only use the lower 16bit of the index. That way you can pass FC_INDEX intact and HB uses the part it needs, and if you get it back from HB you can still use the top bits for instance index setting. We would document this in the API.

Sounds good to me.

[tinywrkb]

This seems to fix an issue affecting variable OTC Noto CJK fonts, or at least with the Noto Sans CJK OTC font.

For example, running LC_MESSAGES=zh_CN.UTF-8 gedit gives me placeholders instead of the CJK glyphs.
Similar problem with Fcitx5, which I believe uses Pango directly without going through a widget toolkit.

Cherry-picking this on top of 3.0.0, solves the problem.