Re: ttfautohint — additional feature requests.

[Brian]

Quick note from the peanut gallery:

High-power platforms with high-DPI displays are not the only place where 
FreeType might be deployed.  Case in point, I am using FreeType to render fonts 
on an ESP32 platform for a 72 DPI 128x96 display.  Hinting (or at least 
reasonable antialiasing) is very important to make text readable on these small 
displays.  So don’t abandon the effort to do it and do it efficiently! :)

Cheers,
-Brian

> On Feb 16, 2020, at 10:12 AM, Werner LEMBERG <address@hidden> wrote:
> 
> 
> [please don't remove the CC fields]
> 
>>> While the current increase of computing power would allow for
>>> better algorithms to handle B/W auto-hinting, it becomes moot at
>>> the same time because the increase of today's screen resolution
>>> even for the cheapest displays makes hinting unnecessary, more or
>>> less.
>> 
>> Seeing the community think like this is cringe.  This only delays
>> the development of ttfautohint even further, even though bilevel
>> optimized hinting is of course a very important feature.  On my
>> laptop display, (1366×768, 101×101dpi, which is about 96dpi)
>> bilevel-optimized hinting is the best hinting.  And it remains so
>> even in displays of five fourths times the dpi (120dpi) and six
>> fourths times the dpi (144dpi).
> 
> Honestly, it's a matter of taste.  Look at MacOS, which abandonded
> hinting a long time ago.
> 
> In my opinion, the current approach of FreeType's auto-hinter is not a
> valid route to bi-level TrueType hinting.  It would thus be necessary
> to develop a completely new algorithm.  If someone is going to
> contribute such code to ttfautohint and/or FreeType: great!  I won't
> do that in the foreseeable future.
> 
>> Even in double the dpi (192dpi) bilevel optimized hinting is clearly
>> the sharpest text rendering.  For hinting to be "unnecessary" you
>> would have to approach Infinity dpi exponentially, that is, work on
>> 384dpi, 768dpi, 1536dpi displays, etc.
> 
> Well, hand-held devices *do* have such high resolutions!
> 
>> And that would be really expensive.  All because of the mindset that
>> blurry text is ever so slightly, but not really, better on higher
>> resolutions than on lower resolutions.  That's desirable for a
>> commercial company like Microsoft (it can get away with selling
>> systems that default to incorrect gamma anti-aliasing, which looks
>> awful regardless of resolution), but certainly undesirable for free
>> software.  I suggest ttfautohint developers to immediately think of
>> ways to achieve bilevel-optimized hinting.
> 
> Alas, there are no ttfautohint developers except me (and, to a certain
> extent, Ewald Hew), and I'm very dormant currently due to many other
> tasks and interests.  The only development that will eventually be
> added is Ewald's code to add hinting for Variation Fonts, see
> 
>  https://gitlab.com/ewaldhew/tah-vf/-/commits/glyf3-wip
> 
> However, this needs further improvements since the resulting fonts are
> very large, and the computation takes ages.
> 
>>> It's not clear to me why you are concentrating so much on hinting
>>> at such small sizes.  As the old MS core fonts (Times, Arial,
>>> Palatino) have demonstrated, it is an incredible amount of work to
>>> do this correctly.  Note also that MS abandoned B/W hinting for
>>> characters that have been added later to the core fonts.  This
>>> means that today only a small fraction of the glyphs in those
>>> fonts actually do work correctly with B/W hinting.
>> 
>> The reason hinting the Microsoft fonts was painful is because that
>> was the only job the hinters could find.
> 
> Do you have a proof for this strong claim?
> 
>> On the other hand, the true hinting of some free fonts is made by
>> the free software community.
> 
> What fonts exactly are you talking about?  Please give some links.
> 
>> The Microsoft fonts are completely irrelevant to this as they are of
>> no use towards developing free fonts.  The removal of horizontal
>> hinting to later glyphs is irrelevant as well: I think they did this
>> to speed up the initial development of the character set, while
>> retaining full hinting for many characters (this includes the WGL4
>> set, which is what most of the Latin, Greek and Cyrillic content
>> consists of).  It is not impressive at all, and a closer look can
>> reveal imperfections of hinting in all fonts, whether it be stem
>> weights diverging at larger sizes, or an imperfect letterform for a
>> particular size.
> 
> I agree, those extensions are definitely hinted with less love.
> 
>>> For such small sizes, a cheaper, probably better, and definitely
>>> much easier solution is to create embedded bitmaps and/or pixmaps,
>>> the latter using a low number of gray values.  A few years ago I
>>> visited the famous Morisawa company in Japan, which produces
>>> probably the best Japanese fonts.  In one department there were a
>>> bunch of people who created such pixmaps of CJK characters.  In
>>> other words, this *is* used, at least for CJK glyphs, and I don't
>>> see why this can't be used for non-CJK scripts, too.
>> 
>> I don't think most environments support this.
> 
> Hmm.
> 
>> Microsoft Calibri has embed bitmaps, but they don't appear to be
>> used, ever, at all.  Instead, GDI uses its broken hinting.  I've
>> heard Microsoft Windows has to detect for several Japanese
>> characters in the font before using embed bitmaps.
> 
> I will ask a Microsoft guy about the details.
> 
>>> You would be able to use such hinted fonts for screen-display
>>> only, for example, to display menus.  If you want to have
>>> something similar to WYSIWYG, such hints are completely useless.
>> 
>> Uh. Isn't that true for pretty much all fully hinted fonts?
> 
> Yes, it is, and I strongly believe that this is one of the main
> reasons that MS decided to use ClearType hinting instead.
> 
>>>> Unify the blue zones for ascenders and descenders if possible by
>>>> the font design.  Because some fonts have them the same, or
>>>> within 1 unit, etc. it makes for consistent hinting.
>>> 
>>> This I don't understand.  Please elaborate and give an example.
>> 
>> DMCA Sans Serif:
>> x-height: 1004
>> ascender-height: 1413
>> descender-height: -410
>> difference between x-height and ascender-height: -409
>> 
>> However, in ttfautohint, the difference between x-height and
>> ascender-height is independent of the descender height. So they end
>> up with different values!
> 
> Interesting.  I have never heard of such a harmonization.  Do you have
> links that elaborate on this?
> 
> I think this can be handled already with a control instructions file.
> Perhaps not in an elegant way, but certainly doable.
> 
>>>> Width delta: The monospaced width becomes a cvt rounded to an
>>>> integer, and the user can choose to delta it.  By default, this
>>>> feature is not used.
>>> 
>>> No idea what you are talking about.  What feature do you mean?
>> 
>> If the width cvt is delta'd, the width changes for every glyph in
>> that size.
> 
> This is an implementation detail of TrueType instructions, something
> that ttfautohint doesn't support at all.
> 
>>>> First of all, handling diagonal stems on the S/s characters.
>>>> I've actually figured out a way to do it:
>>>> https://i.imgur.com/2S3prC2.png .  It involves there being an
>>>> interpolate instruction from the top of the top and bottom stems
>>>> to a control point of the top of the diagonal stem, and so with
>>>> the bottoms of stems, and this interpolation automatically makes
>>>> the middle stem hinted to the proper weight.
>>> 
>>> Looks good.  Could you transform this image to some
>>> (mathematically based) algorithm?  Or reformulate it using
>>> bytecode instructions?
>> 
>> The interpolate instruction is an interpolation.  Suppose there are
>> points a, b, c, having coordinates in one dimension.  After hinting,
>> a and b move to locations A and B.  So, when c is interpolated
>> between a and b, its coordinate C becomes (((c-a)/(b-a))*(B-A))+A.
>> I don't think you should really use this raw equation, as it leads
>> to rounding errors.
> 
> OK, this looks like the standard IP TrueType bytecode instruction,
> right?  Many years ago, FreeType's auto-hinter contained some code to
> identify inflection points; I no longer know why this code has been
> removed.  Maybe this could be unearthed and improved to handle glyphs
> like 'S' in a better way.  Volunteers welcome!
> 
> 
>    Werner