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, 31 Jul 2023 18:04:26 -0400

I have an algorithm I'm testing for the tilde unflattening.  I went with doing it before all steps, because it worked better with my idea, but the function af_glyph_hints_align_weak_points is undoing my changes.
I can tell by measuring the height of the tilde after each step of the latin hinting process.
Here's an example from one test:
before tilde unflattening: 109 units
after: 124 units
after af_latin_hint_edges: 124 units
after af_glyph_hints_align_edge_points: 146 units
after af_glyph_hints_align_strong_points: 146 units
after af_glyph_hints_align_weak_points: 59 units

Even setting oy = y for all the points doesn't stop it, or making extreme changes like raising all points by 200.  How do I fix this? 

On Mon, Jul 31, 2023 at 12:51 AM Werner LEMBERG <wl@gnu.org> wrote:
> > Just take the extrema of *all* points – for fonts this should be
> > good enough, because it is standard to have points at the curve
> > extrema, thus making the bounding box of the curve identical to
> > the bounding box of the points (both on and off points).
>
> Ok, thanks.  This is exactly what I needed.  I was already trying
> this, but I thought it was wrong because of off points.

For your information, you might also look at FreeType's function
`FT_Glyph_Get_CBox`, which handles the generic case.

> What I mean is: my code allows the adjustment for i to be applied to
> glyphs with more than 2 contours to also adjust accented o and a, so
> the rules you suggested would reject around half of the characters
> that are currently being adjusted this way.  I think your rules can
> still be enforced by treating the contour to be moved as "A" and all
> other contours collectively as "B".

Yeah, I was especially referring to glyph 'i', since here the problem
is most visible.

>> [...] I ask you to have this in mind to find a solution that can be
>> easily extended to cover this situation, too (for example, by using
>> an extendable structure instead of a plain variable).
>
> In this case, do you mean that instead of making a codepoint a key
> for the database directly, I should wrap it in a struct so that
> other kind of keys can be added?

Something like this, yes.  Just try to be generic, and think of
possible extensions.


   Werner

reply via email to

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