fontblog https://docs.microsoft.com/archive/blogs/fontblog/feed.xml Tue, 16 Apr 2019 05:08:10 GMT en-US hourly 1 VTT Version 6.30 [August, 2018 release] https://docs.microsoft.com/archive/blogs/fontblog/vtt-version-6-30-august-2018-release Thu, 02 Aug 2018 09:09:02 GMT https://blogs.msdn.microsoft.com/fontblog/?p=1705 here The following are the changes since the 6.20 [March, 2017 release] release of VTT: • Support for Open Type Font Variations including Intermediates. Previously, VTT only supported varying CVTs at the extremes of axes in the design space. VTT now can vary CVTs anywhere in the design space, including intermediate points between axis masters, and the corners of the design space. • Updated UI in Variation CVT Windows. The Variation CVT window now clearly shows you how CVTs change at the selected point in the design space: it tells you which CVTs you have edited at that point, which CVTs are varying due to nearby deltas, and which CVTs are unchanged. You can also add, edit and remove instances represented in the cvar table. You can create temporary instances without deltas so you can quickly switch between points in the design space to proof your work. Finally, any can name any instance you create to make it easy to keep track of them. • Visual TrueType and FontTools. Visual TrueType uses a port of the FontTools varLib library when computing variation delta data for the cvar table. • Visual TrueType includes a command line utility vttshell.exe. This utility can be used to compile and/or strip sources from a font containing Visual TrueType source data. Usage options are available using the command “vttshell.exe -?”.]]> Glossary of Terms https://docs.microsoft.com/archive/blogs/fontblog/glossary-of-terms Tue, 12 Jun 2018 09:44:54 GMT https://blogs.msdn.microsoft.com/fontblog/?p=1575 glossary of terms, may be a useful reference for articles on FontBlog Aliasing: Sometimes called “the jaggies” or stair-stepping. It is an artifact of displaying round or diagonal features on a rectilinear grid like a display screen. Anti-aliasing: Techniques intending to minimize the impact of aliasing, including gray-scale rendering and ClearType. Traditional anti-aliasing techniques use signal-processing methods of sampling and coverage. Many anti-aliasing techniques tradeoff luminance edge contrast (blurriness) for spatial accuracy (position correctness), especially on low-resolution display grids. Anti-aliasing can create blurriness when the size of features you are displaying are similar or smaller than the size of the pixel grid on the display (e.g. if the stem-size in a glyph is equal-to or smaller than one-pixel). Font Smoothing: A specific technique of anti-aliasing used by Microsoft Windows starting with Windows 95. It uses a combination of grid-fitting and oversampling to create a sharper screen image than traditional anti-aliasing techniques. Grid-fitting has the side-effect of increasing luminance edge contrast. ClearType: A Microsoft specific technique that uses sub-pixel rendering to improve the quality of scan-conversion. The technique is based on breaking down a display pixel into its physical sub-components known as sub-pixels—in most cases these are red, green, and blue display elements. Because of the physical nature of sub-pixels, they may have a directional component that may improve quality in one axis (e.g. horizontally) while being neutral along the other axis (e.g. vertically). At small sizes and display resolutions, this asymmetry is not noticeable, but at larger sizes it becomes visible. Symmetric Smoothing: A technique that improves the non-symmetric aspects of ClearType rendering, but at the cost of reducing luminance edge contrast. Luminance edge contrast increases as the PPem size increases. The art of enabling symmetric smoothing is to enable it at a PPEm size where there is a minimal loss of luminance edge contrast while maximizing shape integrity. DirectWrite and GDI both now support symmetric rendering. Hinting: A generic term used in the font industry for improving font quality at low resolutions. It was originally used to describe a set of hints to the scan-conversion routine to create more consistent raster images. Grid-fitting: A specific technique used for improving scan-conversion that involves “snapping” the vertical and horizontal components of the vector outline to align with the target size (PPEm) pixel-grid. Instructing Fonts: A TrueType specific term that involves using instructions in the TrueType interpreter to implement hinting and/or grid-fitting. PPEm: Pixels per Em. A resolution independent method of representing font heights, or Ems, in the raster image. For a given display resolution, font point size can be converted to pixels per em with the following formula: PPEm (in pixels/em) = (Size in points/em) * ((device resolution in pixels/inch) / (72 points/inch)). For example, 12 points/em on a 300 pixel/inch printer would be 50 pixels/em. Overscaling: Scaling the font outline data by a large amount above the target size, often 2x, 4x, or even 16x Illustration of 4x Overscaled outline Downsampling: Converts the overscaled pixels to the original target pixel size by applying levels of gray to the pixel based on the percent coverage. Luminance Edge Contrast: Is the maximal light intensity change over a given distance for a feature on a pixel display. If a color changes on a pixel element from the brightest white to the darkest black on the adjacent pixel element, then the luminance edge contrast is high. If a pixel element changes from a gray to a minimally darker gray in the adjacent pixel element, then the luminance edge contrast is very low. If the transition is from maximal white to medium gray then to minimal black, the luminance edge contrast will depend on how physically close those transitions occur. If the display resolution is high, the luminance edge contrast will be higher than if the display resolution is low. Display Resolution: Is the density of pixels on a display surface. The higher the density of pixel resolution with respect to the resolution of the human eye, the more accurately the object can be represented. Typically display resolution is measured in either pixels per inch (PPI) or dots per inch (DPI) (which are equivalent). A more accurate unit of measurement with respect to the human visual system is pixels per degree, which takes into effect the distance the viewer is from the display. ]]> The ‘gasp’ Table https://docs.microsoft.com/archive/blogs/fontblog/the-gasp-table Wed, 09 May 2018 10:42:02 GMT https://blogs.msdn.microsoft.com/fontblog/?p=1495 What is the ‘gasp’ table? The ‘gasp’ table (Grid-fitting and Scan-conversion Procedure Table) in a TrueType font plays a very important role in how a Hinted TrueType font will render on-screen on Microsoft Windows. In general, the table contains information that describes the preferred rasterization techniques for the typeface, as well as specifying the combination of sizes and rasterization modes at which hinting should be applied. The following series of posts covering the ‘gasp’ table will go into more detail about the original intention of the table, how it has evolved, editing the different fields, and covering how the style of hinting used in the font effects how the font will render on screen. The following glossary of terms may be a useful reference while reading this series. Let’s start with some historical background, as this is relevant to how the ‘gasp’ table works today.

‘gasp’ table: Historical overview

Font smoothing, became the default rendering in Windows 2000 and was first released as an option for Windows 95 in the Plus! Pack. Font smoothing was a hybrid grayscale anti-aliasing technique designed to improve the contrast of fonts over traditional anti-aliasing techniques. Traditional anti-aliasing works by rasterizing the font at a much higher resolution called overscaling, or oversampling, then downsampling the bitmap. With traditional anti-aliasing the overscaling does not have Grid-fitting/Hinting applied. This can result in significant blur in the rendering. Font smoothing uses this same anti-aliasing technique, except that it applied ‘font hints’ or ‘grid fitting’ to snap vertical and horizontal edges of the font outlines so that they aligned with the pixel grid, prior to overscaling the outline data. In this situation, most horizontal and vertical stems of a font, when overscaled, cover 100% of the underlying pixels, and when downsampled return the text foreground color, which is usually black. Diagonal and round features of the font will not have full coverage of the pixel and will usually return some shade of gray, reflecting the coverage of the underlying pixel. When sampled with this technique horizontal and vertical features have maximal contrast while diagonals and rounds—which traditionally suffer from aliasing — get the ‘softer treatment’ reducing the aliasing. We liked this technique because of the better contrast — but we found a few problems. For example, in the uppercase K, the left hand vertical stroke is ‘black’ while the diagonals would appear to be ‘gray’. At small font sizes on screen where the strokes are one pixel or less, this led to weird depth cues where the vertical stroke comes to the foreground while the diagonals go to the background. (See Figure 1. below, middle) We found that once the stem-width moves to at least two pixels, this problem tends to go away. Bold fonts were often treated slightly different with bold values enabling font smoothing at lower sizes. If the ‘gasp’ table was not present in a typeface, the rasterizer applied default rules to decide how to render the glyphs.

Figure 1. Arial 10 point (13ppem) Top: Font Smoothing, No Grid fit. Significant blur on horizontal stems and rounds. Note: This is the equivalent of traditional Anti-Aliasing Middle: Font Smoothing, Gridfit: Note: Uppercase K, the left hand vertical stroke is ‘black’ while the diagonals would appear to be ‘gray’. Bottom: Bi-Level Rendering, Gridfit: Two colors represent the font, the foreground color and the background color. Sharp vertical and horizontal stems, aliasing on diagonals and rounds. The core fonts that Shipped with Windows 3.1, including Arial, were hinted for Black and White rendering, (Aliased) to ensure best display at the sizes where Font Smoothing was disabled. To address the problem, as described in the Cap K example, the ‘gasp’ table was created. The table allowed the font to determine the sizes that Font Smoothing should be enabled and also allowed the font to tune the sizes at which hinting was enabled. This allowed fonts to determine the exact size that font smoothing turns on or off. Most fonts that provided this level of information turn off hinting and turn on grayscale anti-aliasing below 9 pixels per em (PPEM), where the glyphs are too small for hinting to be useful. This is the equivalent of 7 points on a 96 PPI screen. Above 9 PPEM, hinting was turned on, and font smoothing was typically turned off until the main stems of the font were around two pixels wide. This resulted in the highest contrast, and sharpest text on screen. Once the main stems were two pixels wide, font smoothing and hinting remain on as the sizes increase. Two pixel wide stems are usually chosen because there is usually enough “backbone” of foreground colored pixels to keep the stem contrast high. So although font smoothing was the default, many of the common system fonts such as Times New Roman and Arial, and later Verdana and Georgia, when displayed at typical reading sizes, would render as bi-level, or black and white.

ClearType: Extending the ‘gasp’ table

With the introduction of ClearType, we discovered a similar but different issue. An earlier version of the ClearType Rasterizer, used asymmetric rendering because it gave better contrast at lower sizes At larger sizes, however, some aliasing was still evident especially on shallow curves. (See Fig.2 below) The ClearType rasterizer was updated in DirectWrite, and more recently in GDI, to support symmetric rendering, which provides antialiasing in both the vertical and horizontal directions, making for much smoothing rendering at larger sizes. Unfortunately, the symmetric filter did not work well at all sizes. As the size decreases, fewer pixels make for coarser rounding, and TrueType hints are needed to maintain stroke consistency while also keeping strong contrast of foreground vs background. At these small sizes, the grey pixels that symmetric rendering introduces, make up a significant proportion of a character’s bitmap, filling in counter spaces such as the interior of the letters ‘e’ and ‘a’, making these characters look heavier and blurred. (See Fig.3 below) It can be beneficial for some fonts, (particularly text fonts, intended for longer reading) to switch to an ‘asymmetric rendering’, i.e.: without vertical antialiasing. This helps to keeps text contrast higher, an important feature. We had hoped to come up with a filter that would support a symmetric filter with high contrast at all sizes but instead settled on changing to a symmetric filter at a threshold value. A new set of flags were added to the ‘gasp’ table so a font could now tell the rasterizer when to switch to the symmetric filter. These new flags were intended to only apply when ClearType is being used.

Figure 2. Symmetric v Asymmetric rendering at a larger point size. Top: ClearType Asymmetric rendering Bottom: ClearType Symmetric rendering Compare the top and bottom portions of the letter ‘C’ and ‘a’ above, where the shallow horizontal curve produces a jagged, high-contrast step pattern in the top example, and and a smoother progression in the bottom example. The symmetric rendering is applied at larger sizes of type, and may be controlled in a font speciﬁc way using the ‘gasp’ table. Font developers may determine at what sizes the rasterizer will apply asymmetric rendering and at what size to switch to symmetric rendering. It is important to note that this smoothing should not be applied at typical text sizes on screen, because it can reduce the overall contrast of the glyph image. This can make text type appear blurred and undermines readability.

Figure 3. Showing the VTT Demo font set at 15ppem (This is the equivalent of 11 point on a 96 PPI screen) Left: Hinting enabled and Symmetric font smoothing disabled via the ‘gasp’ table. The result is lighter, but sharper text overall. To ensure consistent rendering, stems must be hinted with a combination of Links and cvt's. I will cover this in more detail in the next post in the series. Right: Hinting enabled and Symmetric font smoothing enabled via the ‘gasp’ table. Note: The additional grey pixels introduced by symmetric smoothing causes the counter of ‘e’ and ‘a’ to fill in, making the characters heavier and introduces more blur. This font shown in the example above ships with Visual TrueType. Once VTT is installed the font can be found in Documents>Visual TrueType>sample>VTTDemo.ttf To view and or edit, the ‘gasp’ table in the font, Open the font in VTT > Menu> Edit > Edit Gasp table...

Figure 4. Showing the VTT Demo font set at 7ppem. (This is the equivalent of 5 point on a 96 PPI screen) At very small sizes, symmetric rendering and no hinting is recommended, where the glyphs are too small for hinting to be useful. Left: Hinting disabled and Symmetric font smoothing enabled. Right: Hinting enabled and Symmetric font smoothing enabled. The ‘gasp’ table in VTT Demo font is set to

Disable hinting, and enable symmetric smoothing below 8ppem.
Enable hinting, and disable symmetric smoothing from 9 to 18ppem.
Enable hinting, and enable symmetric smoothing @ 19ppem and above.

Setting the ‘gasp’ Table for ClearType and DirectWrite.

As discussed, the choice of which rendering mode to use for a given size is controlled by the OpenType ‘gasp’ table. Specifically, the ‘gasp’ table lists a set of size ranges, and for each, a set of flags that specify whether to apply hinting and whether to use symmetric or asymmetric rendering. Font Designers can choose the size ranges and rendering modes that best suit the style of the font, and hinting method used, and that provides a smooth progression of weight across size ranges. These settings may vary from font to font, within a family, as well as family to family.

Choosing ‘gasp’ table ranges

The ‘gasp’ table provides quite a bit of flexibility, but the current hinting and rendering environments do not require complex ‘gasp’ tables. Microsoft suggests that most fonts only require three or four ranges: Very small sizes: (typically 0-8ppem*), Render un-hinted, symmetric. Moderate sizes: (typically 9-17ppem*), Render hinted, asymmetric. At larger sizes: (> 17ppem*), Render hinted, symmetric. Very large sizes: (Optional) (> 100ppem*), render un-hinted, symmetric (approximatively*) Though the above is a rough guideline; not all fonts in a font family will have exactly the same ‘gasp’ table. A good guideline for choosing ranges is to consider the thickness of horizontal hairlines / thin strokes that are important for legibility – e.g. the crossbar of the lowercase ‘e’. At some smaller sizes, this thickness will resolve to less than a pixel. In that case, asymmetric rendering will be better as the stroke will still render with a full pixel, aiding legibility. At higher sizes, this thickness will resolve to greater than one pixel, for which symmetric rendering will be better. So, a good point to switch from asymmetric to symmetric rendering is the size at which the thickness of the thin horizontal strokes moves just past one pixel. Since the thin strokes of bold fonts are thicker than the corresponding strokes in lighter weights, the ‘gasp’ table for Bold fonts may switch to symmetric rendering at a smaller size than lighter weights. Similarly, the light weight in a family might cut over at a higher size. See sample 'gasp' Table, and more information here

Above, to show an example, is the ‘gasp’ table shown in VTT. (Visual TrueType 6.2, Arial Regular Font)

To View and Edit the ‘gasp’ table in VTT: Open a Font in VTT > Edit Menu > Edit Gasp Table
The left two columns control the settings to enable/disable Font Smoothing.
The right two columns control the settings to enable/disable ClearType symmetric/asymmetric

Note: Enable ClearType Flags, to activate ClearType ‘gasp’ settings Font Smoothing Settings 1. At 8ppem and below, disable Grid Fit (or Hinting) & enable Grey-scale (Font Smoothing) 2. At 9ppem to 17ppem, enable Grid Fit (or Hinting) & disable Grey-scale (Font Smoothing) 3. Above 17ppem, enable Grid Fit (or Hinting) & enable Grey-scale (Font Smoothing) ClearType Smoothing Settings 4. At 8ppem and below, disable Grid Fit (or Hinting) & enable Non CT AA (ClearType Symmetric Smoothing) 5. At 9ppem to 17ppem, enable Grid Fit (or Hinting) & disable Non CT AA (ClearType Symmetric Smoothing) 6. Above 17ppem, enable Grid Fit (or Hinting) & enable Non CT AA (ClearType Symmetric Smoothing) In the next post I will go into more detail on how to best set the ‘gasp’ table, based on the style of font hinting used, as well as proofing and editing the values. Mike]]> Hinting Font Variation fonts in VTT 6.2 https://docs.microsoft.com/archive/blogs/fontblog/hinting-font-variation-fonts-in-vtt-6-2 Mon, 27 Mar 2017 21:29:41 GMT https://blogs.msdn.microsoft.com/fontblog/?p=1375 Download VisualTrueType 6.20. Variation Window. The Variation window shows you the current selected glyph outline and hints, (just like in the Main window) for the selected variable font instance. With both the Main and Variation windows open, you can easily edit hints in the Main window and see the impact update live, on variations glyphs in the Variation window. Because hints in a variable font are associated with the default instance and merely follow interpolated CVTs for other instances, you can only edit hints in the Main window. The Variation window also allows for proofing the hinting results for variation instances within a font. Variation CVT Window. When you select a master instance, you can adjust the CVTs for that instance; just type a change and hit Ctrl-R to recompile. The Variation CVT window will show you which CVTs vary across the font and how they differ from the default instance. If you select an intermediate instance, you can *inspect the interpolated CVTs for that instance. This is discussed in further detail below, in The Variation CVT Window section. *Note: VTT does not yet support editing intermediate instance CVTs. The Variation CVT Window can also be used to select which variable font instance you would like to proof in the Waterfall, Text Sample, and Variation Windows. Note: VTT currently only supports varying CVTs for masters at the minimum, maximum, and default coordinates of variable font axes. Setting up for Hinting and Proofing in VTT. 6.20.

Main View
Variation View (Choose the View Menu > Variation)
The Variation view Window displays the currently selected Variation Instance.
Variation CVT Window.

The short video below, shows the basics of set-up, running the Light Latin Autohinter, and editing the hints, in a Variation Font. There are a few ways to begin Hinting on a font, including editing the CVT Table manually and adding the hinting via the Visual UI, running the Autohinter, or preparing the font for Hinting, via Control Program only. Please see this previous post for more information on setup and Autohinting. [video width="1704" height="864" mp4="https://msdnshared.blob.core.windows.net/media/2017/03/ScreenCapture_23-03-2017-11.36.262.mp4"][/video]

Open the Font Variation font you wish to add hinting to.
From the VTT Menu, choose Tools > Autohint > LightLatin Autohint
File > Save
Edit the hinting. Hinting is done in the Main Window on the default instance of the font, (in the same way as was done before for static fonts). With both the Main and Variation windows showing side by side, you can edit hints in the Main window and see the hints update live in the Variation window. Because hints in a variable font are associated with the default instance and merely follow interpolated CVT’s for other instances, you can only edit hints in the Main window. In this example, when using the Light Latin Autohinter, the only CVT’s that are used in the hinting, are for Height control. As the Heights, (such as x-height and Cap Height, for example) are consistent across the Variations in this font, there is no need to make any further edits to the Variation CVT table. The Light Latin Autohinter in VTT, uses the ‘ResYdist’ command, to control stem weights. This generally works very well across the variations, when rendered in environments such as DirectWrite, that have support for vertical anti-aliasing. If CVT’s are used for stem hints or for Height anchor CVT’s that need to change along a variation axis, then you need to adjust those CVTs for each variation master in your font. This is discussed in further detail below, in the Editing Variation CVT’s section.
Proofing. Proofing the hints, can be done by looking at the visual size run in the main Window, as well as in the Variation Window. There are two ways to change the variation instance to preview and proof in the Variation window. (A) Choose from the Display Menu > Variation Instance > Choose Variation, Light, Bold, Semilight etc. (B) CTRL + Shift + up arrow / down arrow, on the keyboard, is a quick way to toggle through all of the variations in the font. CTRL 8, displays the Waterfall window, which allows for a quick preview waterfall of the glyphs that are in the text sample. (To change the text sample see, Tools > Options > Extra Text. Glyphs added here will display in the text sample at the top, in the Main and Variation Windows, as well as in the Waterfall sample). Proofing can also be done on the entire glyph set, by choosing View > Character / glyph set. CTRL + Shift + up arrow / down arrow, on the keyboard, can be used in both the Waterfall view as well as the Glyph set view to toggle between all of the available font variations. Note: One set of hints covers all masters in the font. If there are problems with the hints, or you change you mind on the hinting strategy, select the Default master and edit the hints again in VTT’s main window. Remember, though, that any changes here effect all masters, so you’ll need to proof everything across all instances for the re-hinted glyphs again.

The Variation CVT Window. If you used CVTs for stem hints or anchor CVTs that need to change along a variation axis, then you need to adjust those CVTs for each variation master in your font. The short video, illustrations and text below, show an example of how to do this. 1) Hint the default instance as you normally would, creating CVTs and placing visual hints (or high-level instructions). Proof it as you normally would. If you want, you can use the Light Latin Autohinter, or just the Control Program generator to get a start on your CVTs for heights in the font.

a. Open up the Variation window (Menu > View Variation) and the Variation CVT window. (Menu > View Variation CVT) • The Variation CVT window lets you select a particular variation master (or any named instance), and shows you the CVT values for that master (and, in parentheses, the difference between that value and the default instance, if there is one). The Variation window displays the currently selected glyph using the Master you selected in the Variation CVT window, or from the Menu > Display > Variation Instance. • In the Variation CVT window, select one of your non-default masters from the drop down menu. In this example I have chosen the Bold Master, in the Selawik Font Variations font. Note: The Variation, Waterfall, and Text Sample windows will all switch to that instance. b. In this example, I have already measured the outline for the Uppercase Round stems in the default font. The outline measurement (from point 6 to point 18 on the Cap O) in the default font = 81 font units, as shown in the Green highlighted box. This feature will now reference CVT 68, (Uppercase Y Stroke) in the standard CVT Table. See the illustration above, by the Red arrows, showing the VTT Talk Window, ResYlink(6,18, 68). CVT 68 stores a value of 81 font units, in the CVT Table. Now use the measure tool in the Variation window to measure the new CVT values for the other masters in the font. Here I have measured the round stem for the Capital O for the Bold Master, which results in a measurement of 136 font units. CVT 68 now needs to be updated in the Bold Master, CVT Variation Window, to reflect the correct weight of the Bold Master. You can see in the following illustration, if I do not update the Bold Master, CVT Variation Window, to reflect the correct weight, the Bold Capital O, is incorrectly rendered too light from 9-16ppem, as the CVT 68, used in the Hinting, is still referencing the default font weight value of 81 font units, as stored in CVT 68 in the standard CVT Table, instead of the correct measured weight for the Bold Master for this feature of 136 font units.

To correct this: c. In the Variation CVT window, for the Bold Master, find the corresponding CVTs , in this example, CVT 68, and update the values to reflect the actual measurement of the Uppercase Bold Stem. Ctrl-R to compile. The CVT for that instance will be updated, and rendering will be updated accordingly. Note: There are two ways to change this CVT value in the CVT Variation window. 1. Scroll to find the appropriate CVT, in this case CVT 68, and change the value to the actual measured value for the Bold Master, which is 136 font units. When the CVT has been updated, and the window is compiled, CVT 68, will be automatically deleted from the unvaried CVT list, and moved into the Varied CVT list. 2. Type the updated CVT 68, directly into the Varied CVT list, in this format, 68: 136 (with the new value reflecting the actual measured value for the bold master), and compile (ctrl R). This will automatically update the Varied CVT list, and remove CVT 68, from the Unvaried CVT list. Here is the example, see illustration below. Variation CVT (Green highlight below) 68: 136 (55) (Red highlight below) Note: when you enter a varied CVT value, it can either be an absolute value, e.g. 136, or a relative value (55) In the above, CVT 68 now has the correct value of 136 font units for the Bold Master instance, which is a difference of 55 (shown in brackets) from the value for CVT 68 in the default instance (thus, the default instance of CVT 68 is 81). With the new CVT value now added to the Varied CVT list, and compiled, in the CVT Variations table for the Bold Master, the correct weight is now rendered for this feature, in the Bold Master. See illustration below.

d. Proof the rest of this instance to make sure you have all of the appropriate CVTs updated in the CVT Variations table as you’d like them, and reflecting the actual measurements in the Bold font. e. Remember again, that you have only one set of hints for all masters in the font. If you want to edit them, select the Default master and edit them in VTT’s main window. Remember, though, that any changes here effect all masters, so you’ll need to proof everything again. f. Repeat steps a-e for each Master in your font.

See the short video below, showing the steps to take in VTT, for editing the CVT for the Capital Bold Stems.

[video width="1036" height="692" mp4="https://msdnshared.blob.core.windows.net/media/2017/03/ScreenCapture_27-03-2017-12.49.141.mp4"][/video] 3) Now that you’ve hinted all the masters, your font should be ready to go, but it’s useful to proof any named instance you have defined in the fvar table, that is purely interpolated (i.e. that doesn’t have a master associated with it – e.g. semibold). To do that: a. In the Variation CVT window, select a non-master instance. Notice that the CVT area will be greyed out. That’s because this instance is not a master, so there are no explicit CVTs associated with this instance. Operating systems will interpolate this instance’s CVTs from nearby applicable masters (thus CVTs are implicit, not explicit), and thus you cannot edit them. b. Proof the instance in the Variation, Waterfall, Sample Text, etc windows. c. If there are problems with this instance, then you will need to make a change. However, since this instance is not a master, you cannot directly change it. You have the following options: i. You can change the base hints in the default master. To do this, make your changes in the main window, hit Ctrl-R, and you can instantly see the results in the Variation window. Note that changing the base hints will impact all your instances so you will need to proof those again. ii. You can edit the CVTs of nearby masters so that they interpolate the way you want them to for this instance. To do this, select each master in the Variation CVT window and make changes accordingly. Note that this will impact each of those masters as well as everything in between. 4) Your font should now be fully hinted and ready to go now. We recommend a light hinting style using ResYDist() instead of Links, with CVTs, and using CVTs only for height anchors. For more information on the RES Instructions, see this post. This is the same style that the Autohinter uses. This approach makes the hinting process much simpler, and saves time (only a few CVTs vary) and generally results in very good quality, for rendering environments such as Direct Write, which has support for y-direction smoothing Mike ]]> Some notes on the New ‘Res’ Hints, aka Smart Hinting. https://docs.microsoft.com/archive/blogs/fontblog/the-new-res-hinting-aka-smart-hints Fri, 08 Jul 2016 13:16:43 GMT https://blogs.msdn.microsoft.com/fontblog/?p=1305 (Rendering Environment Specific). Unlike old-style hints, which always round to a full pixel, ‘Res’ hints adjust to fractional pixels, when this option is available. The ‘Res’ hints adjust automatically to take advantage of whatever antialiasing mode an operating system is using, from 1990s-style black and white rendering, to the latest vertically and horizontally antialiased versions of ClearType. To better understand the flexibility ‘Res’ instructions have, it’s worth reviewing how old-style hints worked.

Older Style Hints

When working with the traditional set of TrueType instructions, you need to use a different set of hints for each rendering environment, that support different rounding granularity’s. For example, in Black-and-White rendering, the strokes of the fonts’ letterforms typically have a width onscreen that is a multiple of a full pixel, because in black-and-white rendering, a pixel is either fully on or fully off. As the type size on-screen increases, features in the y-direction, such as y-round features on the lowercase ‘n’ and ‘o’, must break from one full pixel to two, two to three, three to four, and so on. The first release of ClearType (ClearType GDI rendering), did not change the rounding granularity for y-direction features. While the x-direction features, such as stems, increased in resolution, the y-direction features were still restricted to having a width that was a multiple of a full pixel. ClearType DirectWrite, (now used in most modern Web Browsers on Windows) introduced y-direction antialiasing, which changed this rounding granularity. A pixel in DirectWrite, can assume an intermediate shade of grey or color. The intermediate shade is related to the fractional area of the pixel that is considered as being “inside” a letterform. Using older hinting methods, in previous versions of VTT, you would need one set of hints for black & white and ClearType GDI, where “hints”, such as ‘YLink’ or ‘YDist’ would constrain parts of the letterforms’ outlines to a full pixel boundary. This was the correct rounding for these rendering conditions. However, for ClearType in DirectWrite, a different set of hints would be needed for the same parts of the outlines, so that the same features rounded to a fractional pixel value, allowing for a more accurate and subtle rendering of type onscreen.

The new ‘Res’ instructions solves this problem by defining a new set of hints in VTT Talk, allowing the appropriate rounding to happen automatically for a variety of rendering environments. Unlike VTT Talk’s existing hints, which map to a series of TrueType instructions, the new ‘Res hints’ map to a set of TrueType functions. These functions determine the correct rounding granularity dynamically. In the example above the ‘y-round’ of the lowercase ‘n’ is hinted using a ‘ResYdist’ command. In Black and White rendering and ClearType GDI rendering, the feature will round to a full pixel or pixels. (Note, the y-round of the ‘n’ in (1) and (2) above, breaks from one to two pixels, at 13 to 14 point, in both the Black and White and ClearType GDI. In ClearType DirectWrite, (3) which has support for y-direction antialiasing, the feature will round to a fractional pixel, allowing for a smoother transition at these break points.

Using Older Hinting commands v new ‘Res’ hints

When using the traditional set of hinting commands, such as YLink or YDist, to control y-direction features, a difficult decision is always to decide at what size the hairline features or y-Rounds in a font should break from one pixel to two, and two to three, etc. As the size onscreen increases, there are more pixels available. However, even with the introduction of additional y-smoothing in DirectWrite, which allows for a more fine grained fractional rounding, the older hinting commands were designed to round to a full pixel. At these critical pixel break sizes, one pixel can often look too light, while two full pixels can make these fine features appear too heavy. The example below, shows the Georgia font at 38ppem. 38ppem can be both a larger Display size on screen at 96dpi, or 9 point on a 300 dpi screen.

The illustrated examples below, are shown using DirectWrite Rendering. (1) & (2) both use the older ‘YDist’ command, to control the y-rounds, while (3) uses the new ‘ResYdist’ command.

(1) The rounds of the lowercase characters, such as, the top round on the ‘a’, top and bottom rounds of the ‘o’ and ‘s’, and top round and middle bar of the ‘e’, all round to one full pixel. Although this may appear sharp, the weight is not correct. On a lower DPI screen, where 38ppem is a Display size, these features will look too light. On a 300 dpi screen, 38ppem is equal to 9 point. In this case the physical pixels are much smaller, and when these features are only one pixel in width, they can almost disappear on screen, and can cause the text onscreen to have an uneven look, causing the text to ‘sparkle’. (2), In this example all of the same features render as two full pixels. While this may help strengthen the appearance of the text on screen, the features now look too heavy and clunky. (3) The best solution is to use ‘Res’ hints, where these features can round to a fraction of a pixel. (Illustrated below, see the top round and middle bar of the lowercase ‘e’.) This allows for these fine features of the font, to be displayed onscreen, both at lower resolution and higher, at the correct weight. On higher resolution screens, because the pixels are so small, the effect is that the features appear to be the correct weight, and any additional blur is not noticeable. The overall typographic color of the text is much improved in both cases.

The following are the ‘Res’, Y-Direction hinting commands added automatically by the VTT 6.10 Light Latin Autohinter.

ResYAnchor
ResYDist

When a font is hinted using cvt’s, ResYlink can be used See the font VTTDemo.ttf, that ships with VTT 6.10, as a reference. Note: Adding the new ‘Res’ commands is not supported when using the GUI (Graphical User Interface) for Hinting. If you are hinting a font using the GUI, ‘Res’ will need to be appended to the existing Hinting commands. This can be done by editing in the VTT talk window and compiling. The Light Latin Autohinter, will add the ‘Res’ commands automatically. You can then continue to edit the hints in the font, via the GUI, and VTT will preserve the ‘Res’ hint commands. Mike ]]> Fine Tuning the Light Latin Autohinter output (Part 2) https://docs.microsoft.com/archive/blogs/fontblog/fine-tuning-the-light-latin-autohinter-output-part-2 Fri, 03 Jun 2016 14:01:45 GMT https://blogs.msdn.microsoft.com/fontblog/?p=1255 first post, in this series on Fine Tuning, I looked at editing the Autohinter code, where the Autohinter did not recognize certain features. In this post I will look at second category. 2. Local adjustments to individual glyphs hints, to add Interpolate commands, to improve the typographic color and proportion of the glyph, The Autohinter in VTT 6.10 does not currently add Interpolate commands. An Interpolation helps to control the proportions of a glyph, by maintaining the relative position of one or more ‘child’ points that fall between two other ‘parent’ points. The key word is between — the child point(s) cannot be further in the Y direction than either parent or on the same Y coordinate. When a YInterpolate command is added, it moves the point or points that are Interpolated, along the Y-Axis, in the hinted outline, so that their relationship to a reference point 1 and a reference point 2, is kept the same as it was in the original un-hinted outline. This helps to preserve the original proportion and maintains a good typographic colour onscreen. The following animation shows some examples of YInterpolations that are added to a typical font. The Animation shows adding YInterpolate commands to the following glyphs, Capital A, B, K, N, R, V, W, X, Y, and lowercase k, v, w, x, y. Note, once added and compiled, this instruction works to fix all sizes of the glyph. The animation is just under 3 minutes long. This is all the time it takes to add the Interpolation commands to the glyphs, I mentioned above. [video width="668" height="668" mp4="https://msdnshared.blob.core.windows.net/media/2016/06/ScreenCapture_07-06-2016-11.15.46.mp4"][/video] Note: When using the Graphical hinting tools, make sure to have the following set up in the Tools > Options Window. This will ensure that when the hints are added via the graphical hinting tools, the code will be automatically compiled. When the code is written directly into the VTT Talk window, it needs to be compiled. (ctrl R)

I will take a closer look at the YInterpolate command in the next post in the series. Mike ]]> Fine Tuning the Light Latin Autohinter output (Part 1) https://docs.microsoft.com/archive/blogs/fontblog/fine-tuning-the-light-latin-autohinter-output Fri, 27 May 2016 11:06:12 GMT https://blogs.msdn.microsoft.com/fontblog/?p=717 No Autohinter is perfect. The intent is that the Light Latin Autohinter works well enough for most glyphs. Autohinting for all glyphs in the font should be carefully checked and proofed in VTT 6.10. Hinting for certain glyphs may need editing, either by using the Visual Hinting tools, or by editing the VTT Talk code directly. As with any typeface design project, a great proofing and editing environment, is critical to achieving great quality results. VTT 6.10 has a built in Rasterizer, that can match how fonts render in the Browser, allowing you to confidently proof your font, and edit the hints, before installing and testing the font live from within the browser. Proofing can be done in the Main Glyph window, by viewing the rendering in the text run examples below the main glyph. By viewing the glyph run as well as looking at the Visual Hinting display, you will begin to recognize when you see certain features that have not been recognized by the Autohinter, or when the Hints are referencing incorrect points on the outline. see the previous post on setting up VTT 6.10 for proofing Webfonts, to ensure you have the correct settings. There are a few categories of fixes, (listed below 1-4), that may require some attention. 1. Local fixes to hints within an individual glyph, where the Autohinter has not recognized a certain feature, and the hints may either be missing for that feature, or hints are referencing incorrect points on the outline. 2. Local adjustments to individual glyphs hints, to add interpolate commands, to improve the typographic color and proportion of the glyph, 3. Local fixes to individual glyphs to add ‘deltas’ at specific sizes, to enhance legibility, and to improve the shape & proportion of the glyph. 4. Global adjustments, added to the ‘cvt’ table to adjust the heights of a range of glyphs, at a specific size, such as x-height for all lowercase glyphs, or Cap Height, for all Cap characters. In this post, I will cover some examples of Category 1. Number 1 is the most important of these fixes, and will need special attention after the Autohinter has run. Categories, 2, 3, & 4 relate to ‘fine tuning’ the font hinting to further improve the screen output quality. I will cover these in a later post.

Category 1.

Example glyph: Cap Q, Georgia Pro Regular.

In this example, the Autohinter Light, does not recognize the bottom round feature in the Capital Q, and does not add any hinting to control this feature. This results in this part of the glyph, looking too light onscreen at a range of sizes, and the feature does not round consistently. See the illustration below, Green box highlighting problem of missing hints, and red underlines highlighting the rendering issues.

Editing the Hinting, to add a fix, is easy. There are two ways to approach it, either by using the graphical hinting tools, or by writing the code directly in the VTT Talk Window, and compiling.

Using the Graphical Hinting tools.

The fix can be made to the ‘Q’, by adding new hinting commands, using the Graphical Hinting tools. (See the steps and the animation below) (1) Choose the YLink tool from the toolbar. With the left mouse button held down, drag from point, 13, to 31. This will add two lines of code in the VTT Talk Window. (a) Yanchor is added to point 13, using a reference to cvt 9, (Cap Round undershoot) and (b) YDist is added from point 13 to point 31 (a) YAnchor (13,9) (code added by the GUI, hinting) (b) YDist (13,31) (code added by the GUI, hinting) (2) Choose the YInterpolate tool. With left click on the mouse held down, position the middle of the YInterpolate cursor over point 13, and drag from point 13 to point 31. With left click on the mouse held down, drag the YInterpolate ‘elastic band’ , to select point 0, as the point to be interpolated between point 13, and point 31, as shown in the animation below. This will add the following line of code to the VTT Talk.

YInterpolate (31,0,13)

(3) Open the VTT Talk Window (ctrl 5) and type Res, in front of the YAnchor(13,9)

ResYAnchor (13,9) = (Final code, with the Res appended manually in the VTT Talk)

(4) Open the VTT Talk Window (ctrl 5) and type Res, in front of the YDist(13,31)

ResYDist(13,31) = (Final code, with the Res appended manually in the VTT Talk)

Note: The ‘Res’ commands used to control the rounding, are not supported in the GUI, and will need to be appended to the VTT Talk code manually. (4) Compile the VTT Talk Window (ctrl R) (5) Save (ctrl S) Note: When using the Graphical Hinting tools, to add hinting, the high level code for these hints are added to the VTT Talk Window. When Hinting is added via the GUI, VTT will delete the original ‘comments’ added by the Autohinter. Make a copy of the font, once the Autohinter Light has run as a backup, if you would like to have a reference to these comments. The comments are shown in the VTT Talk Window between /* & */. For example: /*Auto-Hinting Light*/. These comments may be useful to keep as a reference to how the font was hinted. [video width="668" height="668" mp4="https://msdnshared.blob.core.windows.net/media/2016/06/ScreenCapture_01-06-2016-15.17.29.mp4"][/video] The code added as shown in the animation above, will fix the rendering problem in the Q at a full range of sizes.

Writing the code directly into the VTT Talk Window.

(1) Go to the Cap Q, and open the VTT Talk Window (crtl 5), as shown above. (2) There are three commands that need to be added. (a:) ResYanchor on point 13, to anchor this point to the Cap Round undershoot, which references cvt 9. (b:) Adding a ResYdist to control the distance from point 13 to point 31. (c:) Adding an interpolate command to position point 0, so that point 0, is in the correct position, relative to point 13 and 31, which now have new gridfitted positions. /*New Code Added Manually*/ ResYAnchor (13,9) ResYDist (13,31) YInterpolate (31,0,13) (3) Compile the VTT Talk Window (ctrl R) (4) Save (ctrl S)

Looking at the Hinting in the Cap O will give a good reference here to follow, to control the bottom round of the Cap Q. Note, when the new code is added as shown below, compile the code (ctrl R) on the Keyboard, followed by (ctrl S) to save once you are happy with the results. The code added in this example will fix the rendering problem in the Q at a full range of sizes. This is the same solution as the first example, but this time the code is added manually to the VTT Talk window. If there are only a few hinting commands to be added, as in this case, it is often as easy to write the code manually in the VTT Talk Window, and compiling.

Category 1.

Example 2, glyph: Lowercase a, Verdana Pro Regular.

In this example, the Autohinter Light, does not recognize the middle stem in the lowercase a, and does not add any hinting to control this feature. This results in this part of the glyph, looking too light onscreen at a range of sizes, and the feature does not round consistently. [video width="668" height="668" mp4="https://msdnshared.blob.core.windows.net/media/2016/06/ScreenCapture_01-06-2016-16.37.29.mp4"][/video]

Using the Graphical Hinting tools.

The fix can be made to the ‘a’, by adding new hinting commands, using the Graphical Hinting tools. (See the steps and the animation above) (1) Choose the YInterpolate tool. With left click on the mouse held down, position the middle of the YInterpolate cursor over point 21, and drag from point 21 to point 5. With left click on the mouse held down, drag the YInterpolate ‘elastic band’ , to select point 26, as the point to be interpolated between point 21, and point 5, as shown in the animation. This will add the following line of code to the VTT Talk.

YInterpolate (5,26,21) (note, point 26 is not yet grid-fitted)

(2) Right click on point 26, and drag one box to the right to choose the align to grid function. This will change the above command from a YInterpolate to a YIPAnchor command, positioning point 26 on the grid.

YIPAnchor(5,26,21)

(3) Choose the Ylink tool from the toolbar. With the left mouse button held down, drag from point, 26, to 11. to create a YDist from point 26 to point 11

YDist (26,11)

(4) Open the VTT Talk Window (ctrl 5) and type Res, in front of the YDist(26,11)

ResYDist (26,11) = (Final code, with the Res appended manually in the VTT Talk)

Note that at the smallest sizes, 9 and 10ppem, the middle bar is too high causing clashing. Go to 9ppem by clicking on the glyph at this size in the size run below the main character in the Main Window, or by using the keyboard shortcut ctrl = and entering the size 9. (5) Choose the YDelta tool from the toolbar. With the left mouse button held down, click on point, 26, and drag down by one pixel. (6) Repeat step 5 for 10ppem (7) Compile the VTT Talk Window (ctrl R) (8) Save (ctrl S)

Writing the code directly into the VTT Talk Window.

The same fix can be made for the lowercase a, by writing some hinting code directly into the VTT Talk Window and compiling. This fix uses some code that calls a Function, designed to optimally position a middle feature such as the middle stem of the lowercase a. This code is supported in VTT 6.10 and can be used after the Autohinter has run, to optimally position mid bars in glyphs such as Cap H, E F, or in this case the lowercase a. One advantage of using this method, is that at 9 and 10 ppem the middle of the a is positioned correctly, thus removing the need to add any additional Deltas to correct this. Important Note. When this Hinting command is used, and VTT Talk is compiled, you will not be able to make any further edits via the GUI. If further edits are made by using the Graphical Hinting tools, the code will be overwritten by VTT and will be lost. (1) Open the VTT Talk Window (ctrl 5) (2) Type the code at the end of the VTT Talk, just before the Smooth() command. For this example the code looks like this

ResYIPDist||(5,26,11,21)

(7) Compile the VTT Talk Window (ctrl R) (8) Save (ctrl S) The code essentially does the same thing as in first example above. Point 5, at the beginning and point 21 at the end, are the two points, I used in the Interpolate in the first example. Points 26, and 11, are the points on the middle stem. [video width="668" height="668" mp4="https://msdnshared.blob.core.windows.net/media/2016/06/ScreenCapture_02-06-2016-16.01.26.mp4"][/video] In the next post in the series I will look at Categories, 2, 3, & 4 relating to ‘fine tuning’ the font hinting to further improve the screen output quality. Mike]]> A Graphical Guide To VTT 6.10 Light Latin Autohinting https://docs.microsoft.com/archive/blogs/fontblog/a-graphical-guide-to-vtt-6-10-light-latin-autohinting Fri, 08 Apr 2016 14:39:56 GMT https://blogs.msdn.microsoft.com/fontblog/?p=541 CVT (Control Value Table) heights as reference, and linking across common stems, such as H crossbar, E, F, Horizontals, O, Q, C, G, Rounds, lowercase ‘e’ rounds and horizontal bar, and lowercase ‘n’, ‘o’ rounds etc. This strategy, takes advantage of *DirectWrite rendering, allowing the inside of glyph contours to round to fractional pixels. The key heights are anchored to the a full pixel Grid, thereby maintaining consistency onscreen, in gridfitted heights of common characters, both within a font and across a font family. Note, the Autohinter Light will automatically generate a compiled and completed Control Program, Pre Program and Font Program. The following are the reduced set of Y-Direction hinting commands added automatically by the VTT 6.10 Light Latin Autohinter.

YAnchor & ResYAnchor
YIPAnchor (YInterpolate followed by Yanchor)
YInterpolate
ResYDist
YShift

For the examples below, I ran the Autohinter Light on the VTTDemo.ttf font, that ships with VTT 6.10. The following animations, of some of the control characters, for the Cap and Lowercase, shows the order of how the VTT Autohinter Light adds the basic set of Y-Direction hints. As you will see, the smaller set of hinting commands can be used to hint all of the characters in a font. Once you are familiar with this smaller set of hints, it is then easy, to edit the Autohinter output, or to add you own hinting. The hinting approach used in the Autohinter Light, is suitable for Webfonts that will be rendered in DirectWrite. *Note. The Autohinter sets the GASP table to always use ydirection antialiasing, for DirectWrite rendering, which allows for fractional rounding of horizontal stems. This approach does the following

Gridfits Heights such as Cap, and x-height a full pixel grid, helping to maintain high contrast, onscreen, and height consistency across glyphs, and font family weights and styles.
Allows horizontal stems to round to *fractional pixels.
Maintains the correct weight of stems, and correct proportions in the hinted glyphs.
Suppresses subtle features such as overshoots, and undershoots, at lower screen sizes, and allows these features to show again, when enough pixels are available.

*When Hinting for other types of Rendering, such as ClearType GDI, or black and white, that do not support fractional pixel rounding, a stricter method of hinting using inheritance is required. The following animations show the graphical representation of the High Level Hinting code, (VTT Talk) added by the Autohinter. Refer to the details below each animation describing more about the hints in each glyph. This will give a good overview of the basic stem control hints, needed for a standard Latin font. Hinting can be added using the VTT 6.10 Graphical User Interface or by running the Autohinter Light, and editing the hints using the GUI, post autohinting. More detailed notes are added for the CAP H and Cap O, to explain the hinting concepts. The remainder of the glyphs follow a similar pattern. I will add additional notes when there is a new concept introduced.

Let’s start with the Cap H.

High-level Hinting code for Cap H (VTT Talk, ctrl + 5 in VTT) /* VTTTalk glyph 37, char 0x48 (H) */ /* GUI generated Mon Apr 11 03:23:49 2016 */ ResYAnchor(0,2), Moves point 0 to the Grid, using Control Value Table number 2 as reference. (Cap Height outline measurement = 1434. cvt 2 =1434) YShift(0,5) Shifts point 5, to a new position on the grid, relative to point 0’s new position on the grid, ensuring point 5 will also be gridfitted to Cap Height. Note: We do not need to touch all points when hinting. If two points are at the same position and make an unbroken straight line, we can use either point for hinting and the other point will travel with the hinted point, because when the hints are compiled, an instruction called ‘Interpolate Untouched Points’, keeps these two points moving together. In the example above, point 1, will travel with the hinted Point 0, and point 4 will travel with the hinted point 5, similar for the commands at the base of the Cap H. ResYAnchor(11,8) Moves point 11 to the baseline Grid, using Control Value Table number 8 as reference. (Baseline outline measurement = 0. cvt 8 =0) YShift(11,7) Shifts point 7, to a new position on the grid, relative to point 11, ensuring point 7 will also be gridfitted to Baseline. YIPAnchor(0,9,11) Moves point 9, to full pixel grid, relative to point 0 & point 11, which now have new gridfitted positions. This helps to keep high contrast on the bottom of the horizontal crossbar on the Cap H. The Autohinter chooses point 9 on the bottom of the horizontal bar, to interpolate, between the top and bottom of the Cap H. If point 2 was chosen, the bar would have a tendency to round down and may cause the bar to be low. It is better visually for the bar to be high as opposed to low. The bottom point is used, and if the bar cannot be centered it will be pushed up. This same strategy is used in a consistent way, for E, F, etc. ResYDist(9,2) Links across Cap H horizontal crossbar from point 9 to point 2. This command positions point 2, relative to point 9’s new position on the grid, and allow point 2 to round to a fractional pixel. This maintains the correct weight of the horizontal bar, allowing also for a more subtle transition at break points. In rendering that does not support fractional pixels, hairlines and crossbars must break in full pixel jumps, so from 1 to 2, 2 to 3 etc. This can cause the rendering to either look too light or too heavy at the point where it breaks. Fractional rounding, can happen in DirectWrite where we have additional anti-aliasing in the y-direction, allowing for a much smoother transition at these breakpoints. A note on the Res command. TrueType fonts need to be hinted to render optimally onscreen. Some of these, Hints, are specific to particular rendering environments such as black-and-white or grey-scaling (anti-aliased), or ClearType/ClearType with vertical anti-aliasing rendering. The general structure of the Hints are the same for the all of the rendering environments. For example, a letterform such as an uppercase “H” has two vertical strokes and one horizontal bar, whether it is rendered in ClearType or in black-and-white. In black-and-white rendering, the strokes of the fonts’ letterforms typically have a width that is a multiple of a full pixel, because in black-and-white rendering a pixel is either fully on or fully off. In grey-scaling and ClearType rendering, a pixel can have an intermediate shade of grey or color. In black-and-white rendering for instance, Hints will often constrain parts of the letterforms’ outlines to a full pixel boundary, while in grey-scaling and ClearType rendering the same parts of the outlines will be constrained to a fractional pixel value. The Res addition to the command ResYDist, for example, stands for Rendering Environment Specific, and ensures that the appropriate rounding happens, for the various rendering environments. This saves adding additional Hinting commands if Hinting is required to work in a variety of rendering environments. I will cover this in more detail in a later post. A note on the Control Value Table (‘cvt’) TrueType allows control over the regularity of features through the use of values stored in the ‘cvt’ table. Control values are measurements of features, such as lowercase stems widths, and key heights such as Cap Heights and x-Height. These stems, and Heights, although similar to one another, may have slightly different outline measurements. With cvt’s the distances can be controlled so they are the same pixel width at a low resolution, and heights, can be made to be equal also at lower resolutions. At a higher resolution the control value won’t be used and the natural distance will display in the stems and heights. see below for more on Overshoots and Undershoots in the Cap O example.

An example of a section of the CVT Table from the VTTDemo.ttf font. To view the CVT Table, in VTT, View Menu, > Control Program, or ctrl + 4

Cap O

High-level Hinting code for Cap O /* VTTTalk glyph 64, char 0x4f (O) */ /* GUI generated Mon Apr 11 09:02:53 2016 */ /* Y direction */ ResYAnchor(7,3) Moves point 7 to the Grid, using Control Value Table number 3 as reference. CVT 3 = 24. (24 is the measured difference between the Square Cap Height and the Round Cap Height. At small sizes, the round cap height is made equal to the square Cap Height, and rounds to a full pixel. This is done ensure undershoots and overshoots, do not round to above the Cap Height or below the Baseline, where there are not enough pixels onscreen to show this difference. At larger sizes, when there are enough pixels, to show the difference, the undershoots and overshoots are allowed to round using the measured outline. These values are calculated automatically by the Autohinter. The size at which Overshoots and Undershoots kick in, can be manually edited. I will cover this in greater detail in a later post. Fitting the overshoots and undershoots to a full pixel grid, helps to, minimize blur at small screen sizes, and keeps heights consistent onscreen between square and round characters, within a font. ResYDist(7,23) Links across Cap O Top Y-Round, from point 7 to point 23. This command positions point 23, relative to point 7’s new position on the grid, and allow point 23 to round to a fractional pixel. ResYAnchor(15,9) Moves point 15 to the Grid, using Control Value Table number 9 as reference. (undershoots are controlled in the same way as the overshoot above. In this case, CVT 9 = -24. (-24 is the measured difference between the Baseline of 0(zero), and the Round undershoot measurement of the Cap O, which is measured at -24 below the baseline. ResYDist(15,31) Links across Cap O Bottom Y-Round, from point 15 to point 31. This command positions point 31, relative to point 15’s new position on the grid, and allow point 31 to round to a fractional pixel. Smooth()

Cap A

High-level Hinting code for Cap A /* VTTTalk Unicode 0x41 (A) */ /* ACT generated Fri Apr 8 06:14:52 2016 */ /* Min and Max */ ResYAnchor(3,8) ResYAnchor(4,2) YInterpolate(4,1,3) YAnchor(1) ResYDist(1,17) YShift(3,7) Smooth()

Cap E

High-level Hinting code for Cap E /* VTTTalk glyph 23, char 0x45 (E) */ /* GUI generated Fri Apr 8 06:17:44 2016 */ /* Y direction */ (1) ResYAnchor(0,2) Moves point 0 to the Grid, using Control Value Table number 2 as reference. (Cap Height outline measurement = 1434. cvt 2 =1434) (2) ResYDist(0,3) Links across Cap E top horizontal bar, from point 0 to point 3. This command positions point 3, relative to point 2’s new position on the grid. (3) ResYAnchor(11,8) Moves point 11 to the baseline Grid, using Control Value Table number 8 as reference. (Baseline outline measurement = 0. cvt 8 =0) (4) ResYDist(11,8) Links across Cap E lower horizontal bar from point 11 to point 8. This command positions point 8, relative to point 11’s new position on the grid. (5) YIPAnchor(0,7,11) Repositions point 7, on the Cap E Mid-Bar, relative to point 0 & point 11, which now have new gridfitted positions. This command also moves point 7 to the nearest grid. (6) ResYDist(7,4) Links across Cap E mid-bar from point 7 to point 4. This command positions point 4, relative to point 7’s new position on the grid. Smooth()

Cap M

/* VTTTalk glyph 57, char 0x4d (M) */ /* GUI generated Tue Apr 12 03:43:20 2016 */ /* Y direction */ ResYAnchor(0,2) YShift(0,11) ResYAnchor(30,8) YShift(30,13) YShift(30,22) Smooth()

Lowercase x

/* VTTTalk glyph 223, char 0x78 (x) */ /* GUI generated Tue Apr 12 04:22:20 2016 */ /* Y direction */ ResYAnchor(1,6) Moves point 1 to the Grid, using Control Value Table number 6 as reference. (x-height outline measurement = 974. cvt 6 =974) YShift(1,6) Shifts point 6, to a new position on the grid, relative to point 1, ensuring point 6 will also be gridfitted to x-height. ResYAnchor(13,10) Moves point 13 to the baseline Grid, using Control Value Table number 10 as reference. (Baseline outline measurement = 0. cvt 10 =0) YShift(13,9) Shifts point 9, to a new position on the grid, relative to point 13, ensuring point 9 will also be gridfitted to baseline. Smooth()

Lowercase o

/* VTTTalk Unicode 0x6f (o) */ /* ACT generated Fri Apr 8 06:14:52 2016 */ ResYAnchor(15,11) Moves point 15 to the Grid, using Control Value Table number 11 as reference. CVT 11 = -25. (25 is the measured difference between the lowercase baseline of 0 (zero) and the lowercase round undershoot) Overshoots and Undershoots are handled in the same way as the Cap examples above. ResYAnchor(7,7) Moves point 7 to the Grid, using Control Value Table number 7 as reference. CVT 7 = 25. (25 is the measured difference between the lowercase square x-height of 974, stored in CVT 6, and the lowercase round overshoot) ResYDist(7,23) Links across lowercase o top Y-Round, from point 7 to point 23. This command positions point 23, relative to point 7’s new position on the grid, and allows point 23 to round to a fractional pixel. ResYDist(15,31) Links across lowercase o bottom Y-Round, from point 15 to point 31. This command positions point 31, relative to point 15’s new position on the grid, and allows point 31 to round to a fractional pixel. Smooth()

Lowercase n

/* VTTTalk glyph 174, char 0x6e (n) */ /* GUI generated Tue Apr 12 07:39:10 2016 */ /* Y direction */ ResYAnchor(14,10) YShift(14,5) ResYAnchor(15,6) ResYAnchor(19,7) ResYDist(19,9) Smooth() Hopefully this gave a good overview of the smaller set of Hinting commands needed for making Webfonts. If there is more interest, I can add additional animations for other glyphs, with explanations. In the next post I will look at how to edit the Hinting generated by the Autohinter, to fine tune the rendering for onscreen display. cheers Mike]]> Preparing settings in VTT 6.10, for Hinting and Proofing Webfonts https://docs.microsoft.com/archive/blogs/fontblog/preparing-settings-in-vtt-6-10-for-hinting-and-proofing-webfonts Mon, 04 Apr 2016 15:14:52 GMT https://blogs.msdn.microsoft.com/fontblog/?p=373 VTT allows you to easily customize your viewing settings. When you begin Hinting, most of the work, will be previewing and proofing the hinted font glyphs, in the Main View Window. Hinting can be targeted for specific rendering environments. The illustration below, shows a typical setup, of the Main Viewing Window in VTT, for viewing, hinting, and proofing fonts for the Web. VTT 6.10 has a built in Rasterizer, that can match how fonts render in the Browser. As with any other typeface design task, a great proofing environment, is critical to ensure quality results. VTT allows you to confidently add Hints, and Proof your fonts, as you progress through the Hinting process, before installing and proofing live from within the browser.

Some Notes on Lighter Hinting

With the advent of newer rendering technologies, and better screens, Hinting has become much easier. The details in the post below will help you to set up VTT in the best way to add and proof your fonts for the Web. In the past, for older rendering such as Black and White, complex hinting instructions, particularly x-direction hints, and additional Delta hints, were needed to strictly control the character shape onscreen. Because of the limits of a rigid pixel grid at small type sizes, the most difficult characters to render well were those with curves and diagonal strokes – especially italics, and much of this was controlled by adding hinting in the x-direction. Characters such as the lowercase 'm', in a typical Latin font, also needed to be controlled for symmetry, by using special hinting in the x-direction. With the advent of newer rendering technologies, such as ClearType, the set of hinting instructions needed in a typical font, have become much simpler. Because of the increased resolution in the x-direction and accurate subpixel positioning, (when rendering in DirectWrite), stroke weight consistency between vertical strokes is rendered well onscreen, and is forgiving of slight variations in actual stem widths in ways that black and white full pixel rendering was not. The need for hinting in the x-direction to maintain issues of symmetry and stem consistency, are no longer necessary. The lowercase 'm', for example, will be rendered in ClearType, without the need for any x-direction hints. The three vertical stems will be render with consistent weight and even spacing. Italic fonts also benefit greatly from this increased resolution, in the x-direction, greatly reducing the amount of hinting instructions needed. The recommendation for hinting Web fonts, is to use a more Lightweight hinting strategy, using Y-Direction Hinting commands only This simpler set of instructions, focuses on grid-fitting common heights, such as x-height, Cap Height, Ascender & Descender, using CVT (Control Value Table) Height measurements, as reference, and linking across common stems and rounds, such as Cap H horizontal crossbar, E, F, horizontals, O, Q, C, G, Rounds, lowercase 'e' rounds and horizontal bar, and lowercase ‘n’, ‘o’ rounds etc. This strategy, takes advantage of Windows symmetric DirectWrite rendering modes. The key heights are anchored to the Grid, thereby maintaining consistency in grid-fitted Heights of common characters across a font family. This method of grid-fitting also helps to reduce blur, and minimizes distortion to the outline when grid-fitted. I will cover this in more detail in a future post.

Setting up VTT

Click to view full size image. Before beginning hinting, to match the setup shown above in the Main Window, in your own version of VTT, follow these steps to customise the View in the VTT Main Window. 1. After opening a font in VTT, choose View > Main Window (Ctrl+1) from the VTT Menu.

2. Choose Display > Options (Ctrl+D) Display Options, will affect how the glyph outline and visual hinting is displayed in the Main Window. The following setup, shows the settings needed for Hinting and proofing a font, for DirectWrite in VTT. 6.10. Direct Write is the most common rendering used in most modern Web Browsers on Windows, including IE 11, Edge, Chrome and Firefox. The example here shows how I usually have the main Window setup for hinting. You can customise these to how best suits your own working style, or preference.

Display options is broken up into a number of categories, under the Glyph Visuals tab. (There are also settings for Color fonts, under the ‘Color’ Tab option. This is ouside the scope of this blog post, and is not relevent for most hinting tasks)

Settings Details

VTT General

(Bottom left panel) Hide: Stroke Angle. Shows the stroke angle in Italic font. This was useful for older hinting methods, but is not normally needed. VTT Attributes and VTT Commands in these directions. Show: Y-direction only. (See notes above): To work with Y-direction Hinting tools. This setting will show or hide the hinting tools needed for Hinting, in the Toolbar in the main Window.

Rasterizer Options

Set the VTT 6.10 built in Rasterizer, to a combination of ClearType + CT (Frac. AW) + CT (anti-aliased). This will allow for proofing inside of VTT 6.10, using DirectWrite rendering, matching how fonts render in the Browser. (Top Right Panel) Hide: sbit : Set this option to show embedded bitmaps. Hide: Gray scale: Set this option to rasterize with the GDI grey scale technique used by Windows 95 through Windows XP. *Hide: ClearType Grey: Set this option to rasterize with the ClearType Gray technique introduced in Windows 8. *Note: To cover all methods of rendering in DirectWrite environments, make sure to proof using this setting. Show: ClearType: Set this option to rasterize with the color ClearType technique introduced in Windows XP. Hide: CT (comp. AW): Set this option to show ClearType text with compatible widths. Hide: CT (BGR order): Set this option to show color ClearType text with BGR subpixel order. Show: CT (fract. AW): Set this option to show ClearType text with subpixel widths (sometimes called subpixel positioning). Works with both ClearType and ClearType Gray. Show: CT (anti-aliased): Set this option to rasterize in ClearType with vertical antialiasing as introduced with DirectWrite. Works with both ClearType and ClearType Gray.

Design Options

(Upper left panel) The most useful to show in this is panel are as follows. Show: Outlines: Shows the glyph outline in the Main Window Show: Points and Point numbers: Points and point number, are needed to be shown to add hints to a glyphs, as well as to keep track of hinting commands that references point numbers. Show: Fewer points: This setting makes the display of the Glyph outline in the main Window clearer, for hinting purposes, showing only the main points on the outline, that need to be referenced when hinting, and hiding off curve points. Show: Heights: Shows common heights, such as baseline, Cap Height, X-Heights, descender, etc., as a blue line. Show: Metrics: Displays the left and right sidebearings as a blue vertical line. Hide: Outline Errors. Advanced setting, hidden by default. Hide: Equiv. on-curve Advanced setting, disabled by default, and not needed for Hinting. Shows any off curve points as if they were on curve. Designates this by changing the color of the points.

Device Options

(Upper middle panel) Show: Grid fit, Pixels, Grid Lines and Pixel centers are the most useful settings, to view and proof hinted font results. TIP: When working in the Main view, you can use keyboard commands to quickly toggle between some of these settings. The ‘Grid Fit’ setting for instance, will show the glyph in the Main Window, with Hinting turned on. Toggling between the hinted and un-hinted view of the glyph you are working on in the main window is a critical part of the hinting process, to ensure, that the hinting is working as expected, and that there are no unexpected distortions introduced. You can easily toggle between the hinted and un-hinted view of the glyph in the Main Window, to compare the original outline to the hinted outline. Tip: Toggle between the hinted and un-hinted outline = ctrl g Tip: Toggle between the showing and hiding pixels = ctrl b Hide: VDMX heights. For typical hinting this setting can be hidden. For much more detailed information on the VDMX, see this link. Hide: Instructed metrics. This setting was typically used when hinting fonts for older rendering environments, such as black and white, when side-bearings were hinted to control spacing within the font. This setting is not needed when hinting a font for DirectWrite rendering, where hinting is not typically used in the x-direction to control sidebearings These following settings make it easy to view and proofing the hinted glyph in the main Window. The Text string will display above the main Glyph in the Main Window. The ‘Size Run’ will display at the bottom of the main window. Show: Text string. The text strings can be customised to show short samples of text such as ‘the quick brown fox jumps over the lazy dog’. The text string shown at the top of the Main Window can be customized in the Tools> Options panel.Show: Size Run . Shows the rasterized glyph at a range of sizes. The size range shown at the bottom of the Main Window can be customized in the Tools> Options panel. This is a very useful for proofing the Hinted glyphs at a range of common sizes. Note: The sample ‘text string’ along with the ‘text run’ is the best place within the Main Window to proof the hinting of the font as you progress. The ‘text string’ and ‘text run’ will display to match the settings in the Display Options dialog. For example, under the Rasterizer Options, top right panel in the Display Options dialog, When ClearType + CT (frac. AW) + CT (anti-aliasied) are set, the text string will render as ClearType, Subpixel positioned Spacing, plus ClearType y-direction smoothing.

VTT Attributes and VTT Commands

Visual TrueType allows you to add hinting instruction to a font via a graphical user interface. VTT shows relationships between points, connected by arrows. At a glance, you’ll know characteristics of those relationships by studying.

The color of the arrows (green for Y direction links, red for X direction links, grey for flexible interpolations, black for shifts and strokes, and blue for strokes).
Orientation of the arrowheads (X, Y, or any direction).
Shape of the arrowheads (identifying the most frequent control value categories of straight stem, round stem, and any distance).
Control points and their rounding methods (none, to grid, to half-grid, to double-grid, down-to-grid, and up-to-grid).
Other symbols represent the presence or absence of an anchored point, a control value table (‘cvt’), or an override for a minimum distance.

You use your mouse to drag and drop arrows until the on-screen character looks its best at different sizes. For example, you can drag arrows, arrowheads, and arrow tails to change the relationships between points. By displaying pop-up menus, you can change or remove attributes such as ‘cvt’ category, ‘cvt’ number, rounding methods, and freedom vectors. Alternatively, you can add or adjust any of these relationships by typing the relevant commands in the VTT Talk window. Recommended: Set all of the following options.

(Bottom middle panel & Bottom Right Panel) Note: Disabling X-Direction Commands in the VTT General Tab, will disable these commands in the Graphical User Interface. When Hinting to target Direct Write, only Y-Direction hints are needed. If Hinting is targeted at other rendering environments, such as ClearType GDI, or Black and White, x-Direction Hinting may be needed, and can be enabled.

VTT attributes

Show: Anchors: Shows an indicator when points are anchored via a YAnchor or XAnchor command. Show: Rounding method: Adds an indicator to points to show the rounding method used on those points. Show: CVTs: Shows a highway shield on any visual hints associated with a CVT. Show: CVT numbers: Shows the assigned CVT number in the highway shield icon on a visual hint. Show: Minimum distance: Shows an icon on visual hints when a minimum distance has been set. Show: Ppem limits: Shows an icon on Align commands when ppem limits are set.

VTT commands

Show: Links and dists: Set this option to show Link and Dist commands. Show: Shifts: Set this option to show Shift commands. Show: Interpolates: Set this option to show Interpolate commands. Show: Aligns: Set this option to show Align commands. Show: Strokes: Set this option to show Stroke commands. Show: Moves: Set this option to show Move commands Show: Deltas: Set this option to show Delta commands. Now you have VTT setup, the Hinting can begin! The next post in the series will cover Recommendations and best practices, to achieve great results, using a Lighter Hinting approach, and a reduced set of Hinting Instructions. cheers Mike ]]> Introducing VTT 6.10, with Autohinting. https://docs.microsoft.com/archive/blogs/fontblog/364 Mon, 04 Apr 2016 12:10:16 GMT https://blogs.msdn.microsoft.com/fontblog/?p=364 VTT

Hi, Mike Duggan here. I am a Program Manager/Typographer, at Microsoft. Today I would like to introduce some of the features in the latest version of VTT, (Visual TrueType), designed to make hinting fonts, easier and faster than ever. The download is available here The download can be installed as a fresh install, or as an upgrade from the last release 6.01 August 2015. Whether you have some experience with Hinting, or are new to VTT, the new version will allow you to easily add and edit hints using a combination of Autohinting and editing via the Graphical User Interface. Over the next few weeks, I will be writing some posts to cover the following topics

Best settings in VTT for Hinting and Proofing Webfonts
Recommendations and best practices, to achieve great results using a Lighter Hinting approach to control common stems, and covering details of the reduced set of Hinting Instructions.
Using the New Autohinter, to add and edit Hints, for great Webfont results, and using the new CVT (Control Value Table) creation mode.
Setting the GASP table

The first post is to introduce the new Version of VTT, and to talk about the new features. VTT 6.10 now includes an Autohinter for Latin and East Asian fonts, that automatically generates a set of Hinting instructions for all glyphs in a font. The automatically generated Hints can easily be edited via the Graphical User Interface, or by directly editing the High Level VTT Talk code. The Autohinter makes use of a new lightweight hinting strategy, that is best suited to today’s rendering environments, such as DirectWrite. When adding hints from scratch, instead of using the Autohinter, VTT 6.10 can now also automatically generate a ‘Control Value Table’ for Latin fonts, saving you time, so that you can begin adding Visual hints to your font straight away, without the need to measure the font, and manually fill in the relevant CVT entries.

What’s new?

Version 6.10 [February, 2016 release] The following are the changes since the 6.01 [August 31, 2015 release] release of VTT: New: Brand new Icon for VTT, & new icons for the Graphical Hinting interface. New: Autohinter for Latin and East Asian fonts. Most Autohinters generate low level hinting instructions that you cannot easily edit or improve. The new Autohinter in VTT, generates high-level hints that you can easily edit via VTT’s graphical user interface. Some details below. Note: No Autohinter, including this one, is perfect; the intent is that this Autohinter works well enough for most glyphs. Autohinting for all glyphs in the font should be carefully checked and proofed, and certain glyphs may need to be re-hinted manually, either by using the Visual Hinting tools, or by editing the VTT talk. You can study the sample font VTTDemo.ttf, that ships with VTT as a reference on best practices for hinting. New: Ability to automatically generate a ‘Control Value Table’ for Latin fonts, saving you time, so that you can begin adding ‘Visual hints’ to your font straight away, without the need to measure the font, and manually fill in the relevant CVT entries. New: Error and Warnings Limit. When you open a font, VTT will show a list of errors and warnings it detects in a font. If there are many errors and warnings in the font, this may slow down the process of opening a font file. To speed up opening time, you can set a limit on how many errors and warnings to display. New: Legacy Compile. Set this option to ensure that your font will compile exactly the same as it did in Versions 4 and below of VTT. New: Check box added to allow future suppression of Import binary hints message when opening a font with no source data. Various bug fixes related to performance.

Light Latin Autohint

VTT 6.10 now includes an Autohinter for Latin fonts, which makes use of a new lightweight hinting strategy. The new Autohinter generates high-level hints that can easily be edited via VTT’s graphical user interface. The ease of use of the Autohinter, combined with the ease of editing, makes crafting fonts for onscreen use, faster and more intuitive then ever. The simpler set of instructions, added by the Autohinter, focuses on grid-fitting common heights, such as x-height, Cap Height, Ascender & Descender heights, using CVT (Control Value Table) Height measurements, as reference, and linking across common stems and rounds, such as Cap H horizontal crossbar, E, F, horizontals, O, Q, C, G, Rounds, lowercase ‘e’ rounds and horizontal bar, and lowercase ‘n’, ‘o’ rounds etc. This strategy, takes advantage of Windows symmetric DirectWrite rendering modes. Key heights are anchored to the Grid, using Control Value Table references, thereby maintaining consistency in gridfitted Heights of common characters across a font family. I will go delve into more detail on how to use the simpler set of instructions to achieve great quality for Webfonts, in a later post. Follow these steps to Autohint a Latin font: 1. Start Visual True Type. 2. File > Open. Navigate to font file you would like to Autohint. 3. Select Font File and Open. 4. From the Tools menu, select Autohint > Light Latin Autohint. 5. When Autohinting is complete choose Save from File Menu Note: No Autohinter, including this one, is perfect; the intent is that this Autohinter works well enough for most glyphs. Autohinting for all glyphs in the font should be carefully checked and proofed, and certain glyphs may need to be re-hinted manually, either by using the Visual Hinting tools, or by editing the VTT talk. Please see the sample font VTTDemo.ttf, that ships with VTT as a reference on best practices for hinting.

East Asian Autohinter

VTT 6.10 also includes an Autohinter for East Asian fonts. This Autohinter makes use of a new lightweight hinting strategy that focuses on the horizontal strokes common in East Asian scripts. This strategy, takes advantage of Windows symmetric rendering modes and locks the bottom of strokes to the pixel grid while letting the top of strokes float, by using a ‘Shift’ command. This strategy balances edge contrast vs. blur and produces a good distribution of strokes with balanced counters. Note: When the East Asian autohinter is run, on an EA font, the Latin portion of the font will be automatically hinted using the same hinting strategy as used by the Light Latin Autohinter. Follow these steps to Autohint an East Asian font: 1. Start Visual True Type. 2. File > Open. Navigate to font file you would like to Autohint. 3. Select Font File and Open. 4. From the Tools menu, select Autohint > East Asian AutoHint. 5. When Autohinting is complete choose Save from File Menu Note: This simpler automatically generated instruction set will allow for easier editing by a typographer. The intent is that the Autohinter works well enough for most glyphs, leaving a smaller percentage that will need manual touch-up. These fixes might include changes to fix symmetry or proportion issues. No Autohinter, method can produce perfect results. Extensive Proofing of the Automatically generated hints, is highly recommended before shipping a font file. Note: On complex fonts, the progress indictor may stop updating and the Autohinter may appear to have hung. Generally, the Autohinter is still running and will complete in just a few moments. As a time reference, Autohinting a 28,000 glyph Asian font on an average laptop takes just under one minute.

Control Program Only

TrueType allows control over the regularity of features through the use of values stored in the ‘CVT’ table. Control values are measurements of features, such as lowercase stem widths. These stems, although similar to one another, may have slightly different outline distances. With Cvt’s, these distances can be controlled so they are the same pixel width at a low resolution. At a higher resolution the control value won’t be used but the natural distance will display in the stems. The Control Value table doesn’t require these values to be glyph feature distances. The values are an integer and can be accessed from many TrueType instructions. The table also can be written to as well as read from other tables. Other examples of glyph and font features that can be stored in the control value table are: cap heights, x-heights, overshoot distances, ascender heights, baselines, figure heights, serif lengths and heights, italic angle, group (uppercase, lowercase, etc.) stem distances, group round distances. Other features might be: smaller group distances such as a math sign stem distance, braces, brackets, or parentheses distances. VTT 6.10 can now automatically generate a Control Value Table for Latin Fonts. The above mentioned measurements will be automatically generated. Visual hints can then be added straight away without the need to measure the font, and manually fill in the relevant CVT entries. This makes it easy for intermediate and advanced hinters to get started on a font, saving significant setup time. Note: Selecting Tools> Autohint > Control Program Only, is similar to Tools > Prepare font > Import Templates method of generating tables in older versions of VTT. Selecting, Tools> Autohint > Control Program only, will automatically generate a compiled completed Control Program, Pre Program and Font Program. Follow these steps to Automatically Generate a Control Program 1. Start Visual True Type. 2. File > Open. Navigate to font file you would like to Generate a Control Program for 3. Select Font File and Open. 4. From the Tools menu, select Autohint > Control Program Only 5. When complete choose Save from File Menu You can now begin hinting, either using the Graphical User Interface or by adding instructions in the VTT talk window and compiling. You can study the sample font, VTTDemo.ttf, that ships with VTT 6.10 as a reference on best practices for hinting. the next post will look at how to use the appropriate setting up VTT, when Hinting fonts for the Web. Mike Duggan ]]>