freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Progress update on adjustment database


From: Craig White
Subject: Re: Progress update on adjustment database
Date: Tue, 26 Sep 2023 23:17:42 -0400

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]