[HarfBuzz] HarfBuzz API design
behdad at behdad.org
Wed Aug 19 13:13:53 PDT 2009
On 08/19/2009 04:04 PM, Adam Twardoch wrote:
> But surely there needs to be a way to trace which glyphs relate to which
> character codes, which can of course be an n:m relationship. When the
> user moves around the rendered text with a text cursor and decides to
> delete some glyphs, select them or change them, the client needs to make
> sure to sync the operations that it does in its own text buffer with the
> rendering -- especially regarding the size of the selection and/or
> position of the cursor?
That mapping is kept in the "cluster" member of the glyph info. It's the
Uniscribed-like mapping. The way it works is:
- User sets any value they want for the cluster member of the input buffer
for each input character,
- hb_shape() keeps those cluster values as the characters are converted to
glyphs. Whenever multiple glyphs are merged to produce one or more glyphs,
the cluster value of the first glyph is copied to all the output glyphs.
The user then can query the cluster value of the output glyphs to see which
glyphs correspond to what part of the text. This is how Pango tracks all
those things for example.
Now, the hb_buffer_add_utfX() APIs use the offset input input the text array
as the cluster value, but if different values are desirable, user can change
them before passing to hb_shape().
> Does HarfBuzz provide access to the cursor position information that can
> optionally be stored in the GDEF table?
Right now there is OpenType-specific API for that in hb-ot-layout.h, yes:
/* Ligature caret positions */
hb_ot_layout_get_lig_carets (hb_face_t *face,
unsigned int *caret_count /* IN/OUT */,
int *caret_array /* OUT */);
I'm waiting to see what other systems provide before adding a backend-agnostic
API for that.
> Behdad Esfahbod wrote:
>> On 08/19/2009 03:16 PM, Ed Trager wrote:
>>> Hi, everyone,
>>>> I don't have much to say about the actual font-related parts of the
>>>> proposal. But I do think it's perhaps a bad idea to reuse the same
>>>> buffer for text input and glyph output. Is memory that tight? Might a
>>>> user not want to be able to query the text back out even after
>>> I was wondering about this too : When selecting or highlighting shaped
>>> text (to copy/paste/do something else to it) surely a shaper like
>>> HarfBuzz needs to provide convenient access / mapping back to the
>>> underlying Unicode text ?
>> A shaper just converts text to glyphs, giving back the cluster mapping too.
>> The rest is done by the client. The client sure has the text somewhere
>> already. there's no point in keeping a separate copy by HarfBuzz.
>>> - Ed
>> HarfBuzz mailing list
>> HarfBuzz at lists.freedesktop.org
More information about the HarfBuzz