Simplify the API by returning only feature tags. The users of this API
would be interested only in feature enabled by default and whether the
feature is globally or partially enabled wouldn’t be of much interest in
that case. For user features, the user of the API already have full
access to them.
This should get the features on a shape plan after executing it.
Initially I wanted to return an array of tags, but then there can be
user features that are not enabled globally, so I thought returning
hb_feature_t with value and range would be better. There is a TODO since
I couldn’t figure out how to get the value and range from the feature
mask. But also it may be overkill and a simple boolean indicating wither
it is a global feature or not would be enough.
I wounder also what should happen to non-user features that are applied
selectively, like init or medi, does ot make sense to indicate whether
they are global or not?
This is inspired by the discussion in:
https://github.com/fontforge/fontforge/pull/5522#pullrequestreview-2574321449,
but it might be useful to other HarfBuzz users.
As extensively discussed and documented in #1484, Core Text does
not operate in 96 DPI. Core Text doesn't actually have a concept of
DPI internally, as it doesn't rasterize anything by itself, it just
generates vector paths that get passed along to Core Graphics.
In practice this means Core Text operates in the classical macOS
logical DPI of 72, with one typographic point corresponding to one
point in the Core Graphics coordinate system, which for a normal
bitmap context then corresponds to one pixel -- or two pixels for
a "retina" context with a 2x scale transform.
As of f401f85a5a, we no longer apply
any assumptions in HB about the target DPI being different than the
72 DPI used by CT, for example to account for the Web's standard of
96 DPI, so let's remove the documentation that still indicated this
was necessary.
New API:
+hb_get_table_tags_func_t
+hb_face_set_get_table_tags_func()
Towards fixing https://github.com/harfbuzz/harfbuzz/issues/4821
To be implemented by face-builder, FreeType, and CoreText backends.
We previously marked it as deprecated in the documentation but didn’t
actually deprecate it in code. Now the only known users have migrated to
draw_glyph(), lets deprecate o=it for good.
