Re: Progress update on adjustment database

> 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 <[email protected]> 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
>