> 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. > Looks good. 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. will do! Also, did you see my question about a glyph mapping to multiple characters? On Sat, Sep 30, 2023 at 2:40 AM Werner LEMBERG <w...@gnu.org> 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 > > OK. I think it is a bad side effect of the current auto-hinting > algorithm that there are different approaches. However, using the > adjustment database I wonder whether the knowledge of the character > topology can help improve the situation. In other words, do you see a > possibility to 'decouple' the (vertical) hinting of the tilde from the > base glyph hinting by checking a flag in the database? For this > purpose, a 'tilde' could be defined as the contour that lies higher > than the ascender of small letters – this implies that you need > another flag or enumeration to refer to small letter, uppercase > letters, etc. > > As an example, the database information for glyph 'o tilde' could be > > * lowercase character > * hint contour(s) higher than the lowercase ascender hight > separately > * stretch tilde vertically > > > I implemented the algorithm for all glyph variants! The version I > > used is different from what I wrote originally to fix some errors. > > Looks good. 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. > > > 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. > > A feature-rich (and freely available) font family is 'Libertinus', for > example. > > > Werner >
