Matthias Clasen

One suggestion: ``` HB_EXTERN hb_bool_t hb_ot_layout_get_font_extents (hb_font_t *font, hb_direction_t direction, hb_tag_t script_tag, hb_tag_t language_tag, hb_font_extents_t *extents); ```

Making it opt-in makes sense to me. It would be good to have tests with the new format to test that things fail cleanly and as expected.

The more radical approach is to switch the docs to use gi-docgen. Thats what the gtk stack and much of gnome has switched to. The advantage is that it gets...

Yeah, one of the main ideas was to force docs to be all introspection based. It can be limiting for the docs, but at the same time it makes the...

I ended up changing things around and instead of calllng hb_font_set_var_named_instance, do the following: ``` hb_ot_var_named_instance_get_design_coords (...) /* override some coords */ hb_font_set_var_coords_design (...) ```

In pango, I am now doing an extra hb_buffer_add() call to add a hyphen, if the line is hyphenated. It removes the trailing context, but otherwise works.

This would be great to have. I'm looking at what to do for opsz in pango, and having harfbuzz just do the right thing would be by far the easiest.

Continued in https://github.com/harfbuzz/harfbuzz/pull/3986

freetype uses quite a bit of harfbuzz api, unfortunately. It is easy to lower the dependency from hb-ft to just hb, by copying a few lines of font setup code,...

> If hb build system can build hb and hb-ft in several stages. it will solve original problem. As Behdad has pointed out before, hb-ft currently lives in the libharfbuzz.so....