[HarfBuzz] more complete feature/mask control

Behdad Esfahbod behdad at behdad.org
Fri May 28 15:35:26 PDT 2010


On 05/28/2010 06:32 PM, Jonathan Kew wrote:
> On 28 May 2010, at 22:44, Behdad Esfahbod wrote:
> 
>> Thanks Jonathan,
>>
>> It gives me a starting point.  I'll commit and start working on it.
>>
>> BTW, I realized that in or_masks(), we can't really binary search because:
>>
>>  1) While hb_buffer_add_utf*() set ->cluster to be src index, the user is
>> free to modify those to be some other value they find useful for future
>> retrieval (or use hb_buffer_add() instead).
> 
> Hmm... well, personally I think you should rename the cluster field to be src_index and define that this IS what it means. The user can't change it to be anything else, or the entire feature start/end API is broken anyway.

The start/end API is well-defined: it applies to the characters having
src_index matching (start <= src_index < end).  What src_index really *is* is
up to the user.


>>  2) If ensure_direction() reversed the buffer, ->cluster is not increasing
>> anymore.
> 
> True, we'd have to have two versions of the search, to handle forward or reversed buffers.....
> 
>>
>>  3) Since we also reverse_clusters() in ensure_direction(), the ->cluster
>> array may not even be monotonic.
> 
> ....but this complicates things further, yes.
> 
>>
>> We probably can do something like walking over it once and see if it is
>> monotone and save the result and bsearch if it is.
> 
> Perhaps, but given the factors you've mentioned, I suggest using the "dumb" implementation for now, and we can consider optimizing later.

Yes, as long as it doesn't affect the API, we're good to have a dumb
implementation.  Was just pointing it out.

behdad


> The most common case will in any case be start=0, end=-1, which is optimized via the global_mask so that only one iteration over the buffer is needed for any number of features.
> 
> JK
> 
> 



More information about the HarfBuzz mailing list