API to get list of active features in a buffer?

[khaledhosny]

I think we discussed this before, but asking again in case things have changed 😄. It would be beneficial for some applications (e.g. TruFont, Scribus etc.) to get a list of active features in a HarfBuzz buffer so that they can adjust their UI with what feature are currently active and what is not. Bonus points if it can give the ranges for features like init, medi, etc.

I might give it a try if such API is OK and I can get some pointers where to look.

[khaledhosny]

cc @adrientetar

[adrientetar]

I thought it's probably best not to display those since default enabled features will change as you type a character in a given script making it confusing to the user.

So currently what I do is:

1. Ask for the list of GSUB features with default script and lang i.e. hb_ot_layout_language_get_feature_tags
2. Set them all to False (except kerning defaults to True) in my dictionary of features if they don't have a value set yet

[adrientetar]

Let me know what you think of that. But in any case such API would be useful, I reckon.

[khaledhosny]

Set them all to False (except kerning defaults to True) in my dictionary of features if they don't have a value set yet

This will break features like init etc. as enabling them again will make them global buffer features instead of being selectively enabled based on Unicode character properties.

[behdad]

Currently we have hb_ot_shape_plan_collect_lookups. You can work your way back from lookups to features manually.

I'm not against implementing a collect_features as well. Though currently we don't keep the list of features, but we can collect as needed. The relevant code is already in hb_ot_shape_collect_features in hb-ot-shape.cc, with its only use in that file as well. Just expose it nicely near collect_lookups implementation.

Note that I'm suggesting that we expose the features in an hb_set_t as well. So the order will be lost. Which is what we want since the ordering is complex and we don't want to expose that.

[behdad]

Also, with this implementation you might get things like kern and any other feature that declares fallback will show up as always present even if font doesn't have them.

As for getting features that are applicable to text in buffer, that's beyond what I can think of exposing right now. The lookup-to-feature backmapping one can collect can be used with the messaging API....

[behdad]

I don't think we are going to do anything about this.

[khaledhosny]

Applications like FontGoggles work fine without this.