[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