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: Mon, 11 Sep 2023 01:30:26 -0400

So, if my understanding is correct, hb_ot_shape_glyphs_closure will take an input character or characters and tell me all the glyphs that it gets transformed into, as well as the final form.  I'm not sure about this interpretation, because the documentation uses the term "Transitive closure", which I'm not familiar with.
As for iterating through auto-hinter styles, do you mean that I should get a list of features and try each one for the 'features' parameter?

Also, I wanted to share my progress in the tilde unflattening.  You suggested earlier that I fix the algorithm by removing the segments containing points of the tilde from their edges.  This worked remarkably well.  In fact, I found that I often got better results with only this change.  The problem with the vertical stretch was that while it was able to fix the tilde in many cases, it caused the size to be inconsistent.  The tilde would be 2 pixels wide at one ppem, then increase to 3 when downsizing, when this issue wasn't present before (this happens both with and without the segment removal).  The segment removal is simpler and should be preferred if it solves the problem adequately.  The drawback of segment removal is that it causes the tildes to have blurrier outlines, and it doesn't fix some of the cases that it would if it was combined with the vertical stretch.
The segment removal should be part of the solution, but the question is to what extent the vertical stretch should be part of the solution.  To try to answer this, I tested on a bunch of fonts.
To aid testing, different characters use different versions of the algorithm:
õ: vertical stretch, no segment
ñ: no vertical stretch, segment removal
ã: vertical stretch and segment removal
all other tildes: no changes applied

Results:
Liberation Sans Regular: Segment removal delays flattening, but adding vertical stretch delays it even further.
Times New Roman: All approaches had weird behavior at exactly 16 ppem.  With only the stretch, the tilde flattened at this size.  With both approaches with segment removal, the tilde stretched to 3 pixels tall and looked very out of place.  This wasn't an issue with any non-adjusted letters with tildes (indicating it didn't originate from the font).  In all cases, the tilde was not flat but very blurry at all sizes where the glyph was legible.
Noto Sans Regular, suggested by Brad: both approaches with segment removal fix the tilde until around 13 ppem.  This font has flat tildes at sizes as high as 26 ppem, which occurred with the vertical-stretch-only mode.
Calibri Regular: Didn't have a flat tilde issue to begin with.  Both approaches using segment removal had no size anomalies.

On Sat, Sep 2, 2023 at 1:59 AM Werner LEMBERG <wl@gnu.org> wrote:

> I discovered there was an issue when I tried using a test font I created
> with the following as one of its lookups (in ttx format):
> <Lookup index="1">
>         <LookupType value="1"/>
>         <LookupFlag value="0"/>
>         <!-- SubTableCount=1 -->
>         <SingleSubst index="0">
>           <Substitution in="j" out="i"/>
>           <Substitution in="zero" out="one"/>
>         </SingleSubst>
>       </Lookup>
>
> There is one lookup here, but 2 substitutions.  My program needs to
> iterate through each substitution individually, but the function
> hb_ot_layout_lookup_collect_glyphs only returns 2 unordered sets
> representing all the input and output characters for this lookup.
> How can I get one substitution at a time?

Indeed, you can't use use `hb_ot_layout_lookup_collect_glyphs` for
that.  However, given that you actually want to map input character
codes to output glyph indices, what about using
`hb_ot_shape_glyphs_closure` on single input characters, iterating
over the auto-hinter 'styles'?  If you get a single output glyph,
everything's fine.  If you get more than a single output glyph this
essentially means that two or more lookups have been applied in
succession, but you only have to take care of the glyph that is part
of the 'style'.

Note that this is untested on my side – I was just searching in the
HarfBuzz API.

Behdad, if you have a better idea, please chime in :-)


    Werner

reply via email to

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