freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] Teaching the autohinter about diacritics


From: Markus Trippelsdorf
Subject: Re: [ft-devel] Teaching the autohinter about diacritics
Date: Sun, 6 Aug 2017 14:39:28 +0200

On 2017.08.06 at 14:00 +0200, Nikolaus Waxweiler wrote:
> Hello list,
> in a mail to Werner, I was wondering about how to teach the autohinter
> about diacritics. Reason: In many fonts like Noto Sans, diacritics like
> in 'i' may hang too low at smaller pixel sizes and might even be
> compressed, resulting in a very unpleasant look and making glyphs harder
> to distinguish (Test the string "Hi" at 15 px on
> https://fonts.google.com/specimen/Noto+Sans).
> 
> I think this deserves a public discussion. Werner is aware of the
> problem and though of 3 possible solutions:
> 
> 1) A bottom blue zone for diacritics in the Unicode diacritics block.
> 
>    Problems:
> 
>    a) The diacritics themselves may not align at the bottom like in Noto
> Sans.
> 
>    b) The blue zone must be independent of the script.
> 
>    c) Many basic fonts do not have the block, so the autohinter can't
> produce a blue zone.
> 
>    d) Sometimes, diacritics are positioned differently on purpose. A
> font might put the dieresis closer to the base glyph for German than for
> other languages.
> 
> 2) A generic mechanism in the autohinter that helps avoid vertical
> collisions. This might compress diacritics more, however, because the
> autohinter may not know it can move the entire contour.
> 
> 3) A new diacritics database that describes things like the 'i' having
> two contours, one of which must be at least one pixel above the other,
> or the '~' and 'ã' having a contour that must be expanded to be at least
> two pixels high.
> 
> Werner gravitates towards 3) with an expanded afblue.dat.
> 
> Solution 2) sounds interesting to me, with the twist that the autohinter
> moves entire unconnected contours vertically to avoid collisions. The
> easiest case would be something like the 'i', a more complicated case
> may be multiple diacritcs and even other writing systems.

Another problem case is the lowercase 'g'. The bowl often touches the
loop for serif fonts, when stem-darkening is enabled for the autofitter.
(The issue doesn't happen with CFF fonts.)

-- 
Markus



reply via email to

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