[HarfBuzz] caching plans with user features

[Jonathan Kew]

On 30/10/13 18:02, Behdad Esfahbod wrote:
> And, is there any interest to be able to create sub-faces that have certain
> feature settings?  That would be more like how CoreText modeled this.

Hmm. Not sure... I'm not feeling any strong need for it at the moment, 
but perhaps some users would find it handy.

A sub-face would only be able to accept global features, though, not 
features with specific ranges. Which suggests that maybe there should be 
an explicit type difference in the API between global and range-specific 
user features. Then hb_face_create_sub_face would take an array of 
hb_global_feature_t, while hb_shape takes an array of hb_range_feature_t.

Another possibility, then, would be to extend hb_shape to take two user 
feature arrays, one for global features and one with ranges; then it 
could always cache plans that have global features, and never those with 
feature ranges, rather than having to look through the feature array to 
determine cacheability.

(It's a pity the simple name hb_feature_t has already been used for the 
version with a range, as I think it would be a better fit for the global 
one:

   // used by create_sub_face and shape APIs
   struct hb_feature_t {
     hb_tag_t     tag;
     unsigned int value;
   }

   // only used by shape API
   struct hb_feature_range_t {
     hb_feature_t feature;
     unsigned int start;
     unsigned int end;
   }

But maybe it's too late to go that way.)

>
> On 13-10-30 03:02 PM, Jonathan Kew wrote:
>> On 30/10/13 14:42, Behdad Esfahbod wrote:
>>> In the mean time, I think we should switch hb-shape / hb-view to cache
>>> their own plan.
>>
>> I considered doing that, but adding it to the engine itself seemed more
>> generally useful - it's likely to benefit many HB clients. (And then doing it
>> in the test tools would be redundant.)
>