Re: Progress update on adjustment database

[Craig White]

> Perhaps the following?
> (1) If glyph A is in the 'cmap' table, and glyph B is not, prefer
>     glyph A.
> (2) If one glyph needs X lookups and another glyph needs Y, and X < Y,
>     prefer glyph X.
> I'm not sure whether (2) makes sense, though.
> Can you give one or more examples for such cases?

To repeat what I said in an email that I accidentally didn't send to the mailing list: 

> 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.  I want to have a reason for the rule that I choose before I choose a rule for such cases.  (1) seems to generally make sense because the cmap table is more "direct".

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.

- properly address the 'salt' table and similar cases in the glyph alternative finding algorithm.

- Test everything more thoroughly.

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.

> To help people understand the non-trivial algorithm I

> suggest that you add a big comment that shows it working step by step
> for an example font, using a reduced set of features and glyphs.

This comment has been added.

On Tue, Oct 3, 2023 at 7:04 AM Werner LEMBERG <wl@gnu.org> wrote:

> > OK.  I think it is a bad side effect of the current auto-hinting
> > algorithm that there are different approaches.
>
> I just want to clarify: you understood that the reason I used
> different approaches for each letter was to compare the approaches?
> My intent is to use one of those approaches as a universal algorithm
> for all characters with tildes.  So every character would just have
> a boolean flag for whether to apply tilde hinting or not.

Ah, I was confused, sorry – I thought that you get such varying
results for a single algorithm.  Sometimes it happens (not taking your
current work into account) that blue zones affect the hinting of
accents in a bad way, and I thought this were such cases.

> Also, did you see my question about a glyph mapping to multiple
> characters?

I missed it, sorry again.  You write:

> It's possible that 2 characters in the adjustment database could map
> to the same glyph, which will create 2 entries in the reverse
> character map with the same glyph as a key.  In this case, the
> character that glyph maps to is decided arbitrarily based on which
> one the binary search chooses and which order qsort puts them in.
> What should be done in these cases?

Perhaps the following?

(1) If glyph A is in the 'cmap' table, and glyph B is not, prefer
    glyph A.

(2) If one glyph needs X lookups and another glyph needs Y, and X < Y,
    prefer glyph X.

I'm not sure whether (2) makes sense, though.

Can you give one or more examples for such cases?


    Werner