Prevent anti-aliasing (or sub-pixel rendering) of a TrueType font

15
votes

This is how the .ttf font is rendered:

How the font is rendered

I have created this vector-only TrueType font using FontForge. I want to use this font on applications which require vector-based glyphs, and do not support loading .ttf embedded bitmaps (which do not seem to have this problem).

On certain color-schemes this sub-pixel rendering that Windows does makes the font completely unreadable. This effect is present in most ttf fonts, but is much stronger on fonts with pixel-perfect edges like mine.

Does anybody know any programmable hinting tricks or font-settings that will allow the font to render pixel-perfectly instead of with this red/blue halo? I would like the font to work properly without OS modifications to disable ClearType or similar.

To clarify, this is a question about leveraging the TrueType Instruction Set, or changing a TrueType font-setting (not a System/Application setting) that I have may have neglected to set properly, to make the font render legibly (if possible).

2
truetypefontforgecleartype
Are you wanting to make one application use this font with ClearType disabled locally (not OS-wide)? Or have it apply to every usage of the font even those done dynamically (when the user picks from a list of installed fonts, so the application author may have never seen it before)? – Ben Voigt
@BenVoigt The second case - this isn't an application programming question. Windows applications using GDI/GDI+ based font rendering seem to be the primary culprit (though it may not be limited as such). I am hoping an expert in TTF instruction set knows a tweak that may fix the problem: developer.apple.com/fonts/TrueType-Reference-Manual/RM05/… – Nowayz
When you refer to “applications which … do not support loading .ttf embedded bitmaps”, are you certain there’s no support for embedded bitmaps, or is it that you’ve tried them in your font and they haven’t been used? If the latter, have you tried the tricks described in this blog post to encourage the renderer to use them? – Brian Nixon
@BrianNixon I'm assuming there isn't support since the behavior of all the applications I've tried is largely the same unless they use font rendering that isn't related to WinAPI (FreeType, etc). Thanks for that link. This extremely convoluted method may be what I need, though there's no way I (nor anybody) would have ever known to do something as ridiculous as this without MS Mincho exploiting it for whatever reason. – Nowayz
@BrianNixon Hey, can you add your comment as an answer, it worked. I literally can't believe that was the solution but it totally fixed my problem in every application using WinAPI for font rendering (basically everything). – Nowayz

2 Answers

11
votes

Working Solution

Credit goes to Brian Nixon for posting the solution URL, and to Erik Olofsson for researching and posting the solution on his blog.

Erik Olofsson provides a solution that forces Windows font API to prioritize .ttf embedded bitmaps to be used with priority over glyphs when rendering.

The solution can be found in detail at http://www.electronicdissonance.com/2010/01/raster-fonts-in-visual-studio-2010.html

Solution Summary

  1. Add 'Traditional Chinese' code page to the OS/2 Panpose table.
  2. Use the 'ISO 106046-1' (Unicode, UCS-2) encoding.
  3. Include glyphs for the following seemingly random Hiragana characters:
    • い - U+3044
    • う - U+3046
    • か - U+304B
    • ひ - U+3057
    • の - U+306E
    • ん - U+3093

This list is not a joke

0
votes

On certain color-schemes this sub-pixel rendering that Windows does makes the font completely unreadable.

It sounds as if ClearType is not correctly calibrated.

"Pixel-perfect" display is possible only when the text color matches a color plane of the display. For black or grayscale text, that means a grayscale display (high-resolution and expensive digital monochrome displays are popular in the medical imaging field, for example).

Otherwise, you run into the fundamental fact that color components are physically separated on the display. The concept of ClearType is to adjust the image to compensate for the actual physical offset between color planes.

Printed media with high-precision registration is the closest you get to multiple color planes without any offset.

Now, it does still make sense to disable ClearType in some cases -- when the image is intended to be saved in a file rather than presented on the local display, disabling ClearType can produce results that are legible across a wider range of displays and also compress better. (But for best results, send vectors and let the end-user display compensate for its particular sub-pixel structure)

In GDI, control of ClearType is set via the LOGFONT structure that command text-drawing functions which font family, size, and attributes to use. In GDI+, use SetTextRenderingHint on a Graphics instance.

Because the use of ClearType is set by the application at the same time as size, weight, and other attributes, your font is subject to being requested both with and without. However, ClearType is not compatible with all fonts, by forcing incompatibility you will avoid ClearType for your font alone.

The LOGFONT documentation has the following remarks about ClearType:

The following situations do not support ClearType antialiasing:

  • Text is rendered on a printer.
  • Display set for 256 colors or less.
  • Text is rendered to a terminal server client.
  • The font is not a TrueType font or an OpenType font with TrueType outlines. For example, the following do not support ClearType antialiasing: Type 1 fonts, Postscript OpenType fonts without TrueType outlines, bitmap fonts, vector fonts, and device fonts.
  • The font has tuned embedded bitmaps, for any font sizes that contain the embedded bitmaps. For example, this occurs commonly in East Asian fonts.

In addition, the gasp table within the TTF format has several fields specified to influence ClearType usage.

enter image description here

Documentation at https://www.microsoft.com/typography/otspec/gasp.htm and https://fontforge.github.io/fontinfo.html#gasp

And of course, make sure that the "optimized for ClearType" bit in the head table is not set.