Re: [HarfBuzz] HarfBuzz API design



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_bool_t
hb_ot_layout_get_lig_carets (hb_face_t      *face,
                             hb_font_t      *font,
                             hb_codepoint_t  glyph,
                             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


Adam


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
shaping?

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.

behdad

- Ed
_______________________________________________
HarfBuzz mailing list
HarfBuzz lists freedesktop org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]