Re: Progress update on adjustment database

[Craig White]

> 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 <wl@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