Internally, HarfBuzz uses a structure called a shape plan to
track its decisions about how to shape the contents of a
hb_shape() function builds up the shape plan by
examining segment properties and by inspecting the contents of
This process can involve some decision-making and
trade-offs — for example, HarfBuzz inspects the GSUB and GPOS
lookups for the script and language tags set on the segment
properties, but it falls back on the lookups under the
DFLT tag (and sometimes other common tags)
if there are actually no lookups for the tag requested.
HarfBuzz also includes some work-arounds for handling well-known older font conventions that do not follow OpenType or Unicode specifications, for buggy system fonts, and for peculiarities of Microsoft Uniscribe. All of that means that a shape plan, while not something that you should edit directly in client code, still might be an object that you want to inspect. Furthermore, if resources are tight, you might want to cache the shape plan that HarfBuzz builds for your buffer and font, so that you do not have to rebuild it for every shaping call.
You can create a cacheable shape plan with
user_features, num_user_features, shaper_list), where
face is a face object (not a font object,
props is an
user_features is an array of
hb_feature_ts (with length
shaper_list is a list of shapers to try.
Shape plans are objects in HarfBuzz, so there are
reference-counting functions and user-data attachment functions
increases the reference count on a shape plan, while
the reference count, destroying the shape plan when the last
reference is dropped.
You can attach user data to a shaper (with a key) using the
function, optionally supplying a
callback to use. You can then fetch the user data attached to a
shape plan with