Improve pixel rendering of e

[probonopd]

As a result of #5, the e character is rendered badly at small pixel sizes.

The counter (the enclosed part) of the "e" should get larger by moving the line in the middle of the "e" downwards at small pixel sizes.
Is this something that could be improved by applying manual hinting?

[probonopd]

http://designwithfontforge.com/en-US/The_Final_Output_Generating_Font_Files.html

FontForge allows you to hint your font (and even provides an Autohint function), but in practice this step is not strictly necessary. Modern operating systems often have better grid-fitting functionality built into their text rendering engines than you can create yourself without expending considerable time and effort. In fact, Mac OS X and Linux both ignore any hints embedded in the font file itself. If you do decide your font needs hinting for the benefit of Windows users, your best bet is to build the font without embedded hints, then use a specialized application such as ttfautohint to add hinting after the fact.

Is this true? No way we can tell the system to render the e differently in small font sizes?

Manual hinting used to be a big deal...

[probonopd]

Would "Create HHint" like this help?

[probonopd]

Even after studying "PostScript Hints" by @miguelsousa I am not sure whether/how it is possible to achieve the desired effect.

[miguelsousa]

The counter (the enclosed part) of the "e" should get larger by moving the line in the middle of the "e" downwards at small pixel sizes.
Is this something that could be improved by applying manual hinting?

You can do it in TrueType fonts via hinting instructions, but that sort of operation is not available for OpenType-CFF fonts, which use PostScript hinting operators.

[probonopd]

Thanks for the clarification @miguelsousa.
Highly appreciated. 👍

Really surprised that TrueType is better than PostScript/OTF then, at least in this regard.

[miguelsousa]

The two font formats have somewhat opposing hinting models. In CFF the "intelligence" is mostly on the rasterizer, with the font providing only some basic information. In TrueType it's the opposite; each font needs to include detailed hinting information, and the rasterizer "simply" executes those instructions. The CFF approach to hinting also means that whenever the rasterizer is improved all existing fonts benefit, without having to be rebuilt.

TrueType hinting is a lot more powerful as you have full control over which pixels to turn on or off, via instructions attached to any of the glyph's points. But that great power comes with a big responsibility and burden. These days there are tools that do a good enough job at adding hints to TrueType fonts in an automated way (e.g. ttfautohint). And TrueType rasterization methods have improved a lot by producing better renderings of the outlines with less hinting data in the fonts.

[ctrlcctrlv]

@miguelsousa is of course correct to say that different rasterizers have different interpretations of the same PostScript hints, however my understanding of PostScript hinting is that if you put three horizontal hints (HHints) on your e, that should be enough in this case for most rasterizers to not muddle the glyph. Put one for the mid bar, then a short one at the top and bottom.

[probonopd]

Thanks @ctrlcctrlv for clarifying on IRC that I need to add 3 horizontal hints like this:

• one at the max y extrema
• one at min y extrema
• one for mid-bar

[miguelsousa]

Using 3 horizontal hints helps define the glyph's stems, but it won't prevent the conter from collapsing at small sizes, which, as far as I understand, is what this issue is about.

[probonopd]

prevent the counter from collapsing at small sizes

Correct, that is what this issue is about.

Thanks for the explanation.

In Dr. Peter Karow; 2013; Adobe & The Dutch Type Library, page 27, there is an image with 17 different kinds of hints. Apparently there is no hint that would allow one to specify "when in doubt, do this and that so that the counter stays open" - unless I am overlooking something.

There is a "counter" hint but it seems to be only about the width, not the minimal height...

Have I just invented a 18th hint type?

[ctrlcctrlv]

Try putting some verticals in between the two, if my suggestion doesn't work.

Even though there's no counter type, some rasterizers will keep the counter open if it's between two horizontal hints.

[ctrlcctrlv]

By the way I would not be so quick to assume that the counter type is width only. Easy oversight to make in the text of that book. You need to start actually experimenting and showing output of different configurations. PS hinting is trial and error! And your target rasterizer matters more than the hints themselves. You are trying to make ballet into an exact science, you know what I mean? Or fashion. Stop approaching this like a computer scientist, expecting exact specs and determinism. Approach more like an artist. Or use TT hints. 🤣

[miguelsousa]

@probonopd the list of PostScript hinting operators is described in Adobe Type 1 Font Format.