Add hb_ot_layout_lookup_collect_glyph_alternates()
#5367
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To collect all glyph mapping from SingleSubst or AlternateSubst lookups in one call. Needed by FreeType autohinter for performance. New API: +hb_ot_layout_lookup_collect_glyph_alternates()
lemzwerg
reviewed
Jun 16, 2025
src/hb-ot-layout.cc
Outdated
| * will encode those mappings in a certain encoding: | ||
| * If G is the glyph id, and A0, A1, ..., A(n-1) are the alternate glyph ids, | ||
| * the mapping will contain the following entries: (G + (i << 24)) -> Ai | ||
| * for i = 0, 1, ..., n-1. |
There was a problem hiding this comment.
Nice! However, what I really want is the ability to iterate over all lookup indices, using the same hb_map_t object for each call so that HarfBuzz collects the data cumulatively (i.e., the mapping argument of hb_ot_layout_lookup_collect_glyph_alternates should be of type INOUT).
What about the following scheme: If glyph G has alternates A1, A2, ..., A(n), use the following mapping:
G -> N << 24
G + (1 << 24) -> A1
G + (2 << 24) -> A2
...
G + (N << 24) -> A(n)
Now assume three lookup tables X, Y, and Z, with the following data.
X: G -> G1 (SingleSubst)
Y: G -> G2 (SingleSubst)
Z: G -> G3, G4 (AlternateSubst)
After calling hb_ot_layout_lookup_collect_glyph_alternates on X, the mapping would contain
G -> G1
after calling the function again on Y, the mapping becomes
G -> 2 << 24
G + (1 << 24) -> G1
G + (2 << 24) -> G2
and after calling on Z we have
G -> 4 << 24
G + (1 << 24) -> G1
G + (2 << 24) -> G2
G + (3 << 24) -> G3
G + (4 << 24) -> G4
After processing all lookups I could then iterate over the mapping, ignoring all mapping keys larger than or equal to 1<<24, which I would only look up on demand.
Such a scheme, however, would only fly if both keys and values of the mapping are 64bit integers – it would be tedious otherwise to handle an 'overflow' of alternates. Of course, for current FreeType it would work just fine if we used the lower 16 bits for glyph indices and the upper 16 bits for enumerating alternatives...
There was a problem hiding this comment.
Correction: this scheme is better.
G -> A1 + (N << 24)
G + (1 << 24) -> A2
G + (2 << 24) -> A3
...
G + ((N-1) << 24) -> A(n)
There was a problem hiding this comment.
I'm going to implement this using two separate maps: one mapping gid to number of alternates. Another, mapping gid to all it's alternates using the proposed encoding of mine. That should address your concerns.
I think I want to stick with 24bit gids and 256 alternates per gid. The extra code to collect more variations of glyphs with more than 256 alternates is about 30 lines of code I think... But also something that I think can completely be ignored.
There was a problem hiding this comment.
OK, and yes, I agree that the case of having more than 256 alternates could either be ignored (with a warning, say) or implemented in a way that doesn't have to be efficient.
However, it's still not clear to me how I should use your suggested new function. Could you please provide some pseudo-code how iterating over all lookup tables would look like to construct the reverse cmap table?
There was a problem hiding this comment.
In pseudocode:
lookups = hb_set_create();
for feature_tag in requested_features:
add feature_tag's lookups to lookups
glyph_alternates_count = hb_map_create();
glyph_alternates = hb_map_create();
for lookup_index in lookups:
hb_ot_layout_lookup_collect_glyph_alternates(face, lookup_index, glyph_alternates_count, glyph_alternates);
for gid, count in glyph_alternates_count:
for (unsigned i = 0; i < count; i++)
{
hb_codepoint_t key = gid | (i << 24);
hb_codepoint_t alternate = glyph_alternates.get(key);
printf("gid %u alternate %u\n", gid, alternate);
}
There was a problem hiding this comment.
You combine that with cmap and you get your reverse cmap.
|
I pushed a new change, which is now causing gcc-14 warnings that I think are spurious. We've seen similar warnings before from gcc. Clang is happy with this code. |
|
Do you want to have this for the next release? |
|
I'll see if I can finish it before Monday. But I have notes re VARC and hvgl to write (in a doc)... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.