> OK. Minor nit: Please avoid overlong git commit messages (i.e., not > longer than 78 characters). And there should be an empty line after > the first line to help tools like `gitk` to properly display git > commits. [Overlong lines should be avoided in the C code, too, both > for comments and code.] > Excellent! I think it would also be beneficial if you could mention > your findings in either a git comment or in the code itself, together > with some real-world examples of such quirks (i.e., font name, font > version, glyph name, reason why it fails, etc., etc.)
Will do, thanks. I need some help figuring out how to handle the type 3 lookups. I need to do 2 things: - Figure out which features contain type 3 lookups - Determine the number of variations the feature contains For the second one, this function seems relevant: https://harfbuzz.github.io/harfbuzz-hb-ot-layout.html#hb-ot-layout-feature-with-variations-get-lookups But this returns a list of lookups if you already know the variation index, when I want to know the range of possible variation indices. hb_ot_layout_lookup_get_glyph_alternates also looks useful and could partially solve the problem. With this function, I can handle the type 3 lookup cases in isolation, only finding the glyphs directly resulting from the feature and no further transformations. Also, can I have some advice on testing the code? How should I make these changes bulletproof? On Mon, Oct 16, 2023 at 11:58 PM Werner LEMBERG <w...@gnu.org> wrote: > > >> I simply noticed that it's possible for 2 characters to map to the > >> same glyph, which means that a glyph would map to 2 characters. I > >> don't have any examples in mind for when this would actually > >> happen. I was planning on either ignoring the situation to let it > >> be resolved arbitrarily, or removing both entries. > > > > The situation is resolved arbitrarily for now. > > OK. Minor nit: Please avoid overlong git commit messages (i.e., not > longer than 78 characters). And there should be an empty line after > the first line to help tools like `gitk` to properly display git > commits. [Overlong lines should be avoided in the C code, too, both > for comments and code.] > > > Also: what else needs to be done for the project to be complete and > > ready to become a part of freetype? The remaining tasks I can think > > of are: > > > > - Fill in, or find someone to fill in the rest of the adjustment > > database. > > This is certainly helpful. However, it doesn't need to be complete > right now, but it should cover a good share of languages that use the > Latin script. BTW, please add a comment to the `adjustment_database` > array, explaining the format. > > > - properly address the 'salt' table and similar cases in the glyph > > alternative finding algorithm. > > - Test everything more thoroughly. > > Sounds good, thanks. I also request you to produce a 'final' GSoC > tree with cleaned-up commit messages, as mentioned in other e-mails to > this list to other GSoC participants. > > > At this point, I know that the segment removal + vertical stretch is > > definitely the best approach, and the latest commit applies that to > > all the characters with tildes rather than a comparison of > > approaches. I previously thought that it caused some regressions, > > but I now know that the examples I had were just preexisting quirks > > in either the font or the autohinter. > > Excellent! I think it would also be beneficial if you could mention > your findings in either a git comment or in the code itself, together > with some real-world examples of such quirks (i.e., font name, font > version, glyph name, reason why it fails, etc., etc.) > > > Werner >
