Re: Progress update on adjustment database

[Craig White]

I have a question:

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?

On Tue, Sep 26, 2023 at 11:17 PM Craig White <gerzytet@gmail.com> wrote:

> Thanks.  Do you have meanwhile found an explanation why o-tilde looks

so bad for Times New Roman at 16ppem?

All 4 letters in each row have a different approach:

õ: vertical stretch, no segment removal

ñ: no vertical stretch, segment removal

ã: vertical stretch and segment removal

all other tildes: no changes applied

Actually, I tried the o tilde character again with no adjustments and it looked the same.  In this case, the vertical stretch wasn't enough to fix the issue.

> Sounds good.  Unfortunately, I'm a bit short of time right now; I'll

think about your algorithm within the next few days.  However, please
proceed anyway!

I implemented the algorithm for all glyph variants!  The version I used is different from what I wrote originally to fix some errors.  Here's the current version:

results is now a global set of glyphs instead of an argument to the function.  It initially starts empty

fs is a global set of features, also initially empty

all other definitions are the same

func all_glyphs(codepoint c)

{

    result = result ∪ lookup(c, fs)

    foreach (feature f ∈ (features - fs)) //for all features not already in fs

    {

        new_glyphs = lookup(c, fs ∪ f) - result

        if (new_glyphs != ∅)

        {

            result = result ∪ new_glyphs

            fs = fs ∪ f

            all_glyphs(c)

            fs = fs - f

        }

    }

}

I've only tried it on a pretty simple case so far, so I'll need to assemble a more complex test font or two.

On Mon, Sep 18, 2023, 4:03 AM Werner LEMBERG <wl@gnu.org> wrote:

> Is testing all these combinations really necessary?

I don't know :-) I just wanted to point out that feature combinations
have to be considered.

> [...] My intuition says very few of these combinations actually
> matter.

Yes, I agree.

> I wrote some pseudocode for a different approach that I believe
> accomplishes the same thing, while being more efficient and hopefully
> removing the need to constrain the set of features considered: [...]

Sounds good.  Unfortunately, I'm a bit short of time right now; I'll
think about your algorithm within the next few days.  However, please
proceed anyway!

> I attached some pictures of the tilde unflattening approaches.

Thanks.  Do you have meanwhile found an explanation why o-tilde looks
so bad for Times New Roman at 16ppem?

> I chose sizes that showcase the differences between the approaches,
> and also committed my current code if you would like to try it
> yourself.

Will try if I find some time.


    Werner