Home   All Products  |   Support  |   Search  | Home  

Microsoft Typography | Developer | Hinting and production guidelines specification

Hinting and production guidelines specification

1 Overview

The purpose of this document is to define the Microsoft Typography criteria for hinting and quality in TrueType and OpenType fonts.

2 Table values

2.1.1 TrueType tables gasp

  • all information required.
  • Microsoft recommends setting the 'gasp' table so anti-aliasing is turned on when the fonts stems are two pixels or greater.

note: Anti-aliasing or grey scale is one of the most argued and controversial topics in font rendering. Some research and user feedback at Microsoft suggests that when a user enables 'Font Smoothing' they expect fonts to always be displayed with grey scale at all sizes.

The values in the 'gasp' table should be set so they are font dependant and the font vendor feels that they have given the font the best representation at all sizes. head

  • all information required.
  • unitsPerEm should be a power of 2, (2048 ideally).

    What is a power of 2?
    A value that is the product of 2 to the power of 'n'. Example : the ideal value of unitsPerEm is 2048. This is the product of 2 to the power of 11.

    Why a power of 2?
    Division on computers is a very slow operation. One way programmers get around this problem is to use a technique of shifting bits for division. When a value is a power of 2, division can be performed by simply shifting the bits in the binary of that number. This is extremely fast and efficient.

    This method is similar to dividing by ten in a decimal system. To divide 1000 by 10 you only need to move the decimal place one value to the left. The result is the same as 1000 divided by 10 or 100.0.

    Why 2048?
    2048 units were chosen for a few reasons.

    • It is a power of 2 value. (211)
    • 2048 is a high enough value for good precision in rendering.
    • 2048 is a low enough value to be processed efficiently by microcomputers.

    In the Asian fonts for Windows, MS Mincho and MS Gothic it was necessary (at the time of their release) to choose a lower value (256 units) because of the file size of these font files.

    The actual units per em value is a balance between the amount of processing power, the complexity and size of the font file, and the amount of precision that can be obtained with this value. A low units per em value would result in less quality in the output but be faster to process. A high units per em value would produce a higher quality output but be slower in processing.

    Today computers are more powerful than ever and the use of large fonts with thousands of glyphs is becoming more common especially with Unicode and OpenType fonts. With today's computers we suggest the 2048 units per em value as still the best value for all fonts of any size including large Latin or non-Latin script fonts.

  • xMin, yMin, xMax, yMax for all glyph bounding boxes.
  • macStyle bit should match fsSelection in the OS/2 table.
  • lowestRecPPEM should indeed be an indicator of the hinting level; not an arbitrary value.
  • Pay attention to the various flags in the table regarding the origin of the coordinate system, the baseline, integer ppems, and linearly scaled advance widths.
  • fontDirectionHint should be set according to the hints implemented. hhea

  • All information required.
  • Ascender, Descender, and LineGap are typographic values.
  • minLeftSideBearing, minRightSideBearing, advanveWidthMax calculated for hmtx glyphs with contours.
  • caretSlopeRise and caretSlopeRun; typographical values and should match with italicAngle in post table.

    The rise and run are common algebraic values used to calculate the angles of a right triangle. This value is used by Windows to slant the cursor (caret) to the italic angle of the font. These values can be calculated from the italicAngle entry in the 'post' table or by measuring the font.

    In an upright font the caretSlopeRise is usually set to 1 and the caretSlopeRun is always 0.

    In italic fonts these values can be programmatically or manually calculated.

    To manually calculate the caretSlopeRise and caretSlopeRun you need to measure the major italic slope of the font or obtain the value from the 'post' table.

    It is common to use the Uppercase Flat height for the caretSlopeRise.

    Once you have the two values you can calculate the caretSlopeRun by using a scientific calculator like the one in Windows. First calculate the tangent of the italicAngle in the 'post' table. Then multiply that by the caretSlopeRise (Uppercase height). This will give you the caretSlopeRun. Example : In my example font the italicAngle in the 'post' table is 10.

    1. The Uppercase flat height is 1465.
    2. The tangent of 10 is 0.17632.
    3. 0.17632 multiplied by the caretSlopeRise of 1465 the result is 258.3
    4. A caretSlopeRun of 258 would be correct.

  • numberoOfHMetrics not necessarily number of glyphs in the font. hmtx

  • All information required.
  • An array of all of the advance widths and left side bearings.
  • Avoid using compressed format for monospaced fonts at this juncture.
  • Individual glyph's advance widths should conform to criteria specified in Microsoft Character Design Standards. loca

  • All information required.
  • Keep in mind that the Mac glyphs of format 0 cmap can only be represented in a single byte (i.e. they need to be within the first 255 entries). maxp

  • All information required.
  • numGlyphs is fontwide; maxZones should be 2 if twilight zone is used.
  • maxPoints and maxContours are for non-composite glyphs only.
  • Most importantly in this table: the information given for the different fields should reflect what is in the font and never be less or significantly more than what the font metrics provide. For example, if maxSizeOfInstructions is 50, but a value of 250 was entered "just to be safe", then the system is running inefficiently consuming more memory than what is needed. name

  • Name table entries one through six should be filled out. Zero length, or entries containing only spaces are not acceptable.
  • Name strings required for both platforms (format 0, format 4).
  • Platform and encoding ID strings must match those in the cmap table.
  • Preferred Family and Preferred Subfamily name ID should be filled when applicable (for any style beyond the four standard styles).
  • Provide copyright and trademark information as appropriate. If you have legal copyright to a particular face, put it in there.
  • Pay attention to the language string ids. Additional language strings for format 4.0 could be added with the Microsoft Font Properties Editor.
  • Make sure that the name strings between both platforms contain the same data to ensure cross-platform compatibility.
  • Follow spec requirements for the contents of the language strings.
  • Version number string should read "Version x.xx".
  • First deliveries to Microsoft are set at "Version 0.70".
  • Second deliveries are set to "Version 0.71".
  • Final first shipment of a font file is "Version 1.00".
  • Provide Designer name and Internet Link if available.
  • Provide Type Foundry name and Internet Link.
  • Font description of the typeface. In cases of symbol fonts or special fonts this should describe the intent of the design and its use.
  • License information in this field should be in ordinary English. The Internet link should provide the exact legal end user license agreement, if a link is available.
  • An Embedding setting should be provided as one of the following, Installable, Editable, Print & Preview or Restricted (no embedding).
  • Provide the Vendor ID. This is the vendor of this font file which may not necessarily be the Type Foundry name.
  • Optimizing the name table creates a smaller size table but could cause problems in production tools that do not read optimized name tables. An optimized name table is optional. OS/2

  • xAvgCharWidth is computed for all 26 lowercase characters, plus space. If some characters are missing, take the weighted average.
  • usWeightClass and usWidthClass take values 100-900 and 1-9 respectively. Remember, the weight class is a measurement of the thickness, not the style variant itself
  • fsType value should be set to the licensing rights outlined in the spec, or project plan. Remember, if different embedding bits are set, then the least restrictive license takes primacy.
  • Superscript, Subscript, and Strikeout information (size and position) are values measured in FUnits to be supplied by the font maker.
  • Numbers for sFamilyClass, as well as numbers for the Panose classification system should be supplied by the vendor and in adherence to the spec. Also, include the vendor ID, which should always be 4 bytes long.
  • In fsSelection, make sure the bit settings don't conflict with macStyle bit settings in the head table. Minimum and maximum unicode indices belong in the usFirstCharIndex and usLastCharIndex.
  • sTypoAscender, sTypoDescender, and sTypoLineGap are all typographic values left up to the designers discretion. sTypoLineGap should roughly equal 7-10% of the Em.
  • usWinAscent and usWinDescent are typically the yMax and yMin of the Windows ansi character set. For fonts whose character set extends beyond Win ansi the usWinAscent and usWinDescent should be calculated based on the yMax / yMin of the entire font.
  • In unicode and code page ranges, set the appropriate bits to denote functionality for the unicode and code page blocks covered by the 3, 1 cmap. Functionality does not necessarily mean that all of the glyphs from a particular Unicode or code page range are present. cmap

  • Need at least two subtables, format 4 and format 0.
  • Format 4 is a Windows subtable which uses platform id 3, and encoding id 1 if the font is a text face and encoding id 0 if it is a symbol font. This format supports two-byte glyph indices.
  • Format 0 is a Macintosh subtable and it uses platform id 1, encoding 0. This format supports single-byte glyph indices.
  • The character sets should be defined at the start of the project, and if there are any non standard mapping due to some special purpose font, then that needs to be defined as well.
  • The subtables are to be placed in the cmap in sorted order by the platform and encoding ids.
  • For Microsoft fonts, a legal restriction requires that character code 240 (Apple logo) in cmap 1, 0 must be mapped to the missing glyph.
  • The Euro glyph is required for all Microsoft fonts and should be mapped to Unicode: U+20AC and Macintosh character code: x00db.
  • For Microsoft fonts, any alternate glyphs, OpenType, or unused glyphs should NOT be mapped in the Unicode Private Use area, they should remain unmapped. The fi and fl ligatures should no longer be mapped to the PUA. post

  • Italic angle in counter clockwise degrees should be in agreement with the caretSlopeRise and caretSlopeRun values in the hhea table.
  • Underline position and thickness are typographic values measured in FUnits and should be provided by the font maker.
  • All virtual memory fields may be set to 0.
  • Microsoft encourage format 2.0 post table to support double-byte glyph indices. Format 3.0 may be used.
  • PostScript character set glyph names should match those in the "PostScript Reference Manual", and glyphs outside of the postscript character set may use a character string in the format of "U-hexadecimal unicode value" as their postscript name. And also see Adobe's glyphlist.txt. PCLT

  • The support of a pclt table needs to be determined at the start of the project.
  • If a pclt is required, then the pclt values must come from Hewlett-Packard. kern

  • If kern table is required, subtable format should be 0, and coverage bit should be 0x1.
  • Please use a program (such as KernEdit) to verify your kerning pairs. cvt, prep, fpgm

  • Use these tables if needed for font hint instructions.
  • Do not include extraneous values in cvt. hdmx

This table provides speed when advance widths are needed, but at the same time, the table adds a significant number of bytes to the font file. Thus, a decision needs to be made about the existence of hdmx, if any, and for what resolutions, and at which pixel sixes. To warrant an hdmx, one or more glyphs in the fonts need to scale non-linearly. Bit 2 or 4 in the head table must be set. LTSH

  • A compliment to the hdmx table with similar conditions, but defines at which point linearly scaled advance widths should be adopted.
  • At the beginning of the project, the above threshold should be defined.
  • Also, don't include hdmx entries for values above the ltsh's linear threshold. VDMX

  • Decide which ratRange groups will be supported. always have group 0,0,0 at end of groupings to support all non previously covered aspect ratios.
  • Decide on the character set covered for the vdmx (uCharSet is 0 when all glyphs in font are supported, and 1 when only the winansi char set is supported).
  • To get a healthy worthwhile vdmx, calculate the vdmx values algorithmically. Remember, the permutations are many, where at different aspect ratios yMax and yMin do not scale linearly. DSIG

  • Required - fonts should be delivered with the Vendors digital signature.

note: As the software distributor Microsoft will sign all fonts with its digital signature prior to shipping with Microsoft products.

3 Glyph hinting do's and don'ts

3.1 Outline data

  • Straight strokes that are intended to be absolutely vertical or absolutely horizontal should be exactly so. Plus or minus one font unit is not acceptable.
  • The outer outline should run clockwise. Glyphs with multiple contours should have their outline orientations alternate. Example in the uppercase 'O' the outer outline should be clockwise and the inner outline should be counter clockwise.

3.2 Instructions

  • All glyphs in the font file should have instructions. This includes the missing glyph, the missing glyph is usually at position 0.
  • Exceptions could be symbol glyphs or fonts with images that are too complex to produce better results with instructions. The type hinter is ultimately responsible for deciding the best approach for any glyph. The option to not hint a very complex font should always be considered before any hinting begins.

    Examples of fonts that have no glyph instructions, some instructed glyphs and some global instructions in the 'prep' table for controlling pixel drop outs are:

    • The logo font that Microsoft uses internal for its corporate logo.
    • A graphic lettering font called McZee that contains images of the comic character McZee climbing on letterforms.
    • Some glyphs in Webdings like the 'dove' image could not be improved with instructions.
    • Very fine engraver style fonts often can not be improved and using drop out control from the 'prep' table produces as good and many times better results than hinting. The use of drop out control is essential in this case.

3.2.1 Composite glyphs

  • Composite glyphs should be used whenever a glyph image is identical to another. Examples of these composite glyphs are glyphs with a base letterform and a diacritic or composed punctuation character such as the 'Lcatalan'.
  • All composite glyphs should contain instructions to control vertical and horizontal placement at specific PPEM sizes. These instructions are commonly function calls that insure diacritics center horizontally and does not touch a base glyph vertically caused by rounding or hints at specific PPEM sizes.
  • Overlapping composite glyphs can be used. It should be noted that older PostScript Level 2 drivers do not support overlapping contours. Examples of overlapping contours are the 'Ccedilla' or 'Aring'.
  • Use the instruction USEMYMETRICS on composite glyphs that should be the same as a base glyph. Example the 'eacute' should have the instruction USEMYMETRICS to insure the advance width remains the same as the lowercase 'e'.
  • The composite instruction SOFFSET for performing flipping, scaling or other transforms should not be used.
  • Recursive composites are supported.

3.3 Horizontal and vertical image control

3.3.1 Horizontal images and placement Spacing

  • Hinting is mainly for low-resolution control of images on screens and low-resolution printers. Hints should not change the positioning of original outline placement.
  • At low resolution when there is an uneven number of pixels on either side of the glyph's pixel image it is preferable to have the pixel image to the left of center.

    The image below shows the uppercase 'O' with only one pixel of white space on the right side. Putting the odd white pixel on the right is preferable to putting the white pixel on the left side because page layout applications use a blinking cursor to show the next input point for the next character. If the uppercase 'O' in our example below did not have a white pixel on the right this cursor will appear to be on top of the character's image. Stem thickness

  • Stem thickness should be compared across all fonts in the family. Stem thickness is best controlled by the use of 'inheritance' of the glyph's control values and the use of deltas that adjust the global control values so all stems can be adjusted in a group.
  • Regular weight fonts should not become two pixels below 17PPEM. This would make it impossible to make a bold version that was not unnaturally heavy at such a small size. 16PPEM is also 12 point on the most common Windows monitors and users are not use to having twelve point appearing as two pixels at this 96dpi resolution. It would be confused with a bold font.

3.3.2 Vertical images and placement

  • As defined in section 3.2.1 for composites, instructions should be used in composite glyphs to avoid the problem of diacritics hitting the base glyph.

4 Binary bitmap quality - single stem pixels

4.1 Blobs

Single pixel stem sizes are the most difficult to control and create the most problems with clean bitmaps. In regular weight fonts these appear at and below 12 point on a VGA screen (which is 16 ppem and below).

The most common problem is with "blobs". Blobs are when more than one pixel are turned on and causes a stem to appear thicker than one pixel. Usually this occurs on curved areas or crossing strokes and diagonals. Diacritics are a common victim of double pixels or blobs.

Blobs on bitmaps with single pixel stems are not acceptable. There is an exception to this rule. Inferior, superior numerals, and letterforms at very small sizes sometimes can not be made clear without expanding the bitmaps to a size that is awkward and too large for the font. In the case of the ring expanding its size is better than a two by two block.

All these characters (shown here at 11 ppem which is a common 8 point VGA) with the exception of the lowercase c cedilla have blobs that could have been avoided. The ring on the first characters in the top and bottom rows, Aring and aring could have avoided the blob by being three pixels wide by three pixels tall.

  • Character bitmap inconsistency : Another main problem is inconsistency. The lowercase barred characters cause many common problems. Shown below at 11 ppem the b with bar on the left has no blobs but has no ascender and the d with bar a has an ascender but the blobs. The h with bar also has a slight connection blob problem. But the b with bar is better and acceptable since it is in the single pixel range and has no blobs and still represents a b with a bar.

4.2 Binary bitmap quality - greater than one pixel stems

  • Weight bitmap inconsistency: Break points that are different when some character stems are one pixel and others are two. The vertical placement of characters such as on the x-height or baseline should not become tall or short due to hinting.

    Fractions at 18 ppem

    Weight inconsistencies 19ppem top row, 18ppem lower row

    In the top row of the second illustration the percent sign is one pixel (there is enough room to make it consistent) and the rest of the characters in the size are two pixels. The fractions have been two pixels since 18 ppem.

    The macron over the uppercase U and lowercase u are two pixels tall and most of the other diacritics are one. In the lower row the ring, grave, and tilde are one pixel and lighter than the other diacritics. If the heavier weight is the preferred weight than all characters should be the same size.

  • Bad character shape : Bad character refers to stray pixels as well as inconsistency in rendering the bitmap.

    In the illustration below the glyph at the sixth size from the left is compressed compared to the rest of the row of lollipops. This is inconsistent and a bad bitmap shape.

    In this illustration the eth has both blobs and bad character shape. The goal of good character shape is to first make the bitmap readable as the letterform it represents. Second is to avoid blobs. Lowering the bowl of the o portion of the eth would have been a good alternative to bad character shape.

5 Printer quality

5.1 Spacing and accent placement

Good outline placement insures all images space well when used with other images. A test is usually performed before hinting begins to ensure all outline data is correctly space. Once hinting begins care should be taken not to use instructions that will alter the original shape or placement of the outline data at high resolution. Good tests are ones that show characters in groups spaced between control characters from their group. Common control characters are the uppercase H and O, lowercase n and o and figure zero. The test should show all characters at 300dpi or above and at least two sizes, one for text testing and one at a display size. Sizes 12 and 24 point are good sizes for this test. Each character should be checked for correct placement and all diacritics should be checked to insure hint data has not altered their original position.

5.3 Shape

Hint data should not create changes in the quality of the outlines.

Examples of these problems are:

  • straight lines should not become uneven.
  • curves should not have dents.
  • the vertical placement of characters such as on the x-height or baseline should not become tall or short due to hinting.

5.4 Stem thickness

  • diagonals should not become excessively thick in comparison to straight stems.
  • stems and rounds become unnaturally different in thickness.

5.5 Round overshoots

Overshoots should turn on at a size large enough that the round characters visually appear equal to the flat characters. If the overshoot is turned on too early it will appear that the round characters are taller and lower than the flat characters. If the overshoot is turned on too late the round characters will look too short and small in comparison to the flat characters. A good size to turn on the overshoot in most fonts is at 10 point 300dpi or 42ppem.

6 Character set

The following information was provided by Microsoft's Office group, and is not part of our official hinting and production guidelines specification. However, for fonts to function correctly in Microsoft Office applications the following characters should be included.

Uindex UISOname Note
00AONO-BREAK SPACESame glyph as space
00B6PILCROW SIGNParagraph sign

7 Overlaps in cursive script typefaces

An issue with fonts that have connecting characters, like Arabic language fonts, is that an overlap of a minimal size is required. This overlap is necessary to avoid issues where rounding causes a column of pixels not to render, leaving a small gap in connection. This break between characters can be seen in the figure below.

figure 1

We have provided a set of guidelines that help font vendors make fonts that avoid this issue.

this page was last updated 3 November 2002
© 2003 Microsoft Corporation. All rights reserved. Terms of use.
comments to the MST group: how to contact us


Microsoft Typography | Developer | Hinting and production guidelines specification