Click Here to Install Silverlight*
United StatesChange|All Microsoft Sites

Typography Home Typography Home

Developing fonts > Specifications

Hinting and Production Guidelines

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  TrueType tables

2.1.1 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-dependent, and the font vendor feels that they have given the font the best representation at all sizes.

2.1.1 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'. For 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 (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.

2.1.2 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.

For example, consider a font whose 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 is not necessarily the number of glyphs in the font.

2.1.3 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.

2.1.4 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).

2.1.5 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 necessary.

2.1.6 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 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'.
  • For first delivery to Microsoft, the Version string should be 'Version 0.70'.
  • For second deliveries, the Version string should be '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.

Top of page

2.1.7 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.

Top of page

2.1.8 cmap

  • Need at least two subtables, format 4 and format 0.
  • Format 4 is a Windows subtable that 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 that 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 ID's.
  • 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 (PUA). They should remain unmapped. The fi and fl ligatures should no longer be mapped to the PUA.

Top of page

2.1.9 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 encourages 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 with the format 'U-hexadecimal Unicode value' as their Postscript name. Also, see Adobe's Glyph List for New Fonts.

2.1.10 PCLT

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

2.1.11 kern

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

2.1.12 cvt, prep, fpgm

  • Use these tables, as needed, for font hint instructions.
  • Do not include extraneous values in 'cvt'.

2.1.12 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.

Top of page

2.1.13 LTSH

  • The LTSH table complements the 'hdmx' table, with similar conditions, but it also defines when linearly scaled advance widths should be adopted.
  • At the beginning of the project, the above threshold should be defined.
  • Don't include 'hdmx' entries for values above the LTSH's linear threshold.

2.1.14 VDMX

  • Decide which ratRange groups will be supported. Always have group 0,0,0 at end of groupings to support any aspect ratios not previously covered.
  • Select the character set covered for VDMX (uCharSet is 0 when all glyphs in font are supported, and 1 when only Win ANSI 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.

2.1.15 DSIG

This table is required. All fonts should be delivered with the Vendor's digital signature.

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

Top of page

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 alternate their outline orientations. For 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, which is usually at position 0.
  • Exceptions include 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 dropouts are:

  • The logo font that Microsoft uses internally 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 cannot be improved, and using dropout control from the 'prep' table produces as good and many times better results than hinting. The use of dropout 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 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 CCEDILLA or ARING.
  • Use the instruction USEMYMETRICS on composite glyphs that should be the same as a base glyph. For 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 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 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.

Example of uppercase O with pixel spacing on right. 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, where 12 point appearing as two pixels at this 96dpi resolution is unexpected, and would be mistaken for 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.

Top of page

4. Binary Bitmap Quality

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 occur when more than one pixel is 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, superiornumerals, and letterforms at very small sizes sometimes cannot 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.

Example of blobs.

The characters in the above example, 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 has an ascender but with 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, has no blobs, and still represents a B WITH BAR.

Example of bitmap inconsistency.

4.2  Greater than one pixel stems

4.2.1 Weight bitmap inconsistency

This type of inconsistency usually occurs at 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
Fractions at 18 ppem
Weight inconsistencies 19ppem top row, 18ppem lower row
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, then all characters should be the same size.

4.2.2 Bad character shape

This refers to stray pixels as well as inconsistency in rendering the bitmap.

In the illustration shown 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.

Example of bad bitmap shape.

In the next 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, and then avoid blobs. Lowering the bowl of the o portion of the ETH is a good alternative to bad character shape.

Example of blobs and bad bitmap shape.

Top of page

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.2  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.3  Stem thickness

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

5.4  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.

Top of page

6. Minimal Character Set for Microsoft Fonts

Our recommendation is that all user-accessible, non symbol-encoded fonts supplied with Microsoft products should contain at least support for Windows Codepage 1252, along with any required non-Latin characters and glyphs language support. Our current recommendation is that any glyphs added to a font should be placed at the end of the font, rather than reordered to Unicode or some other order.

6.1  Characters for Microsoft Office

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

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.

Example of pixel dropout caused by rounding

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

Top of page

Last updated 22 February 2005.

© 2017 Microsoft Corporation. All rights reserved. Contact Us |Terms of Use |Trademarks |Privacy & Cookies