 |
 |
All Products | Support | Search | microsoft.com Home | |
 |
 |
||
|
|
|
|
 |
|||
| Microsoft Typography | Developer information | Visual TrueType resources | The raster tragedy... | |||
 |
|||
|
Excerpts from the presentation at the training session on 29 October 1997 (updated in March 1998) given by Beat Stamm, lead developer of Visual TrueType.
The outline of a glyph is a mathematical description of the glyph's shape using lines and curves (Béziers).
The particular choice of curve is irrelevant. Both quadratic and cubic Bézier curves will do, as long as we have control points. The control points are needed to scale the glyph to the desired type size and resolution (or ppem size for short). The screen is a regularly spaced grid of black and white dots (pixels). To rasterize the glyph essentially means to turn on all pixels inside the scaled outline.
Doing so naïvely results in the above raster tragedy: disjoined arches, unequal stems, missing serifs, etc.
Control point coordinates are integers. There are no decimal places or fractional numbers.
The pixel grid is integer as well, there are no fractional pixels either. E.g., at 12 pt and 96 dpi, the em-square is 16 by 16 pixels. If the pixel grid were not integer, we would simply round it. On screen, we can't tell 12.2 pt from 12 anyhow.
What's left to do to scale the outline is to multiply all coordinates by 16/2048, i.e., first multiply them by 16, then divide them by 2048. The only thing that can (and will) go wrong is the division. Most integers don't divide. Therefore, the computer will have to round some numbers. This is the same as to decide for pixels. As a consequence of rounding, "things don't add up anymore." Something always has to give way. Some things (distances, proportions) must not give way. Notice that if we were to use fractional coordinates and/or allow fractional point sizes, the computer still would have to decide for pixels. In the end, the problem with fractional numbers is the same, it is merely more difficult to understand.
The computer has to be told, which things must not give way. This is what is colloquially called hinting. More precisely, it is called grid-fitting or instructing, since we give the computer precise instructions how to fit the outlines to the grid before turning on the pixels. The purpose of hinting is to...
We cannot have both the left and right edge of stem in the right place and have the correct stem weight (correct in terms of pixels). We have to make a trade-off chosing one of the following: leftEdge + stemWeight = rightEdge rightEdge - stemWeight = leftEdge rightEdge - leftEdge = stemWeight The trade-offs are the variables on the right. They will have to give way.
In TrueType, there is no concept of edges and stems. There are just control points.
There are on-curve points (
VTT's "Show fewer points" hides the off-curve points.
We have to choose which control points we want to define the edge (
A pair of control points defines a pair of edges, which in turn delimits a stem.
VTT's "Measuring Tool"shows measurements for both distances, in x- and in y-direction
This may be a bit confusing:
For a vertical stem, the relevant distance is in x (i.e. horizontal). We move the point in x-direction to fit it to the grid.
For a horizontal stem, the relevant distance is in y (i.e. vertical). We move the point in y-direction to fit it to the grid.
Suppose we have grid-fitted ("touched") the above points in y-direction to control the horizontal stems. Now what about the other ("untouched") points?
They follow "accordingly," due to a pair of IUP instructions ("interpolate-untouched-points") in x-and y-direction that VTT adds at the end of the other instructions.
If we don't "touch" all extremes, IUP can't interpolate all the "untouched" points between pairs of "touched" points, only shift them along with the "touched" points.
This is probably not what we want. But we may still see this intermediate stage while we're linking with "grid-fitting" turned on. Just turn it off, as desired.
So, the left and right edge of a stem is just a pair of control points. If we move these points, the other points will follow "accordingly". Now then, let's give priority to the left edge and the stem weight. This is what the link tool is for. It defines a relationship between:
preserves the weights of the stems
preserves the weight of the serifs. A link across a black distance keeps a minimum distance of one pixel. bottomOfSerif + serifWeight = topOfSerif
prevents arches from "drop-outs".
Notice the two links in x-direction across the left stem. We can see a stem, but the computer cannot. It merely sees a bunch of unrelated control points. We have to relate these control points by links or shifts, even though they are on the same edge of the stem. But why are there two links, rather than four? IUP[X] will take care of the others if there is no gap between them. Compare this to the vstem or hstem hints in Type 1.
How many links for the "Croatian d"?
Fortunately, this case is rare.
Also, there are different ways to do it.
regularly spaces the stems. A link can entail another link, which in turn can entail a third one etc.
The chain of links goes from the left to the right sidebearing in 7 steps. Each step may be off by 1/2 pixel. Therefore, the right sidebearing may be off by 31/2 pixels. Trade-off: proportion (width vs. height), advance width, wysiwyg. At 96 dpi, 31/2 pixels is 50% of the x-height (of 7 pixels). In contrast, at 600 dpi, 31/2 pixels is only 8% of the x-height. How is that going to "line up" such as to see what you get?
Compare this to the vstem3 hint in Type 1. We don't have to know what it does, nor can we do anything if it doesn't do what we want it to.
A link too many would create a circular chain of links. This means that nothing can give way. But we can't keep passing the buck around in a circle. Something always has to give way.
This looks fairly acceptable at 12 pt and 96 dpi.
It is still fine at 10, but not at 8 and 6 pt. At 8 and 6 pt, the cap height must have rounded down, while the location of the middle bar appears to have rounded up. The proportions don't add up to the capheight.
The interpolation doesn't preserve a distance from a parent to a child. The interpolation preserves the proportion of the distance from parent #1 to a child, relative to the total distance from parent #1 to parent #2. It does so in terms of pixels.
Compare this to the hstem3 hint in Type 1.
One way to horizontally align the top bowl with the bottom one.
This works fine with an interpolation. But we might just as well link them. A link across a white or grey distance does not keep a minimum distance. Eventually, the distance rounds down to 0 pixels, and remains 0 for smaller sizes (consistency).
The interpolation doesn't work the other way round. We cannot extrapolate the position of the bottom bowl relative to the top bowl. The child point has to be between the parent points.
At 8 and 6 pt, the point at the crotch between the two bowls is roughly in the center of the middle crossbar, while at 7 pt it isn't.
Extremal points don't know where to go. We have to tell them. What were parent and child for the link become parents for the interpolation.
What a difference a pixel makes. Notice that this last interpolation is relevant to many point sizes, although we're merely looking at one of them. The fact that the 6 pt B has rather odd bowls is another problem, quite specific to that point size.
The B at 12, 11, and 10 pt: By design, the round vertical strokes are a bit wider than the straight ones. We can't see this at 12 and 10 pt. In contrast, at 11 pt we can see a bit too much.
The round stroke is just over 11/2 pixels, which rounds up to 2 pixels. The straight stroke is just under 11/2 pixels, which rounds down to 1 pixel. We need a common reference distance that both strokes can refer to. A control value is a dominant width or length of a group of features such as the stem width or the serif length. Control values are tabulated in the control value table (cvt). You'll have to populate the cvt by measuring the character's features. Compare this to blue values and dictionaries in Type 1.
The pre-program (prep) scales the control values for the desired ppem size. In the prep, we can adjust, at and below which ppem size the scaled cvt values for straight and round strokes should be the same, and similar. Links can then use the respective values from the cvt, rather than using the actual distance between the two control points. As a result, we have leftEdge + stemWeightFromCvtForRoundStrokes = rightEdge leftEdge + stemWeightFromCvtForStraightStrokes = rightEdge yielding the same stem weights for the set ppem size and below.
Cvts are attributed by:
VTT will pick the best match for a given attribute and the actual distance. We can override this choice.
Compare this to hint replacement commands in Type 1. We just put the right cvts in the right places, but we have to put them there at all. Then we can override at what size a 1 pixel stem becomes 2 pixels. We can also override whether e.g. the round strokes should be tied to the straight ones or vice versa for more contrast at smaller sizes.
The O looks fairy straightforward to do. The question mark merely indicates VTT didn't find a cvt for UC White X LSB.
Cvts for height guidelines are a bit tricky. We have to store the absolute value (base line, cap height) for the squares (like the H), and relative value (over- and undershoot) for the rounds (like the O). We would like to link from the cap height to the cap height overshoot and from the base line to the base line undershoot, using the same cvt both times. But the O has no control points on the cap height or on the base line. Therefore, we have to simulate this behaviour.
VTT will pick a cvt for the height if it is attributed as "Grey-Y-Absolute (or Relative) Height" We can override this choice.
In daily font production, you may start with the heights and then go from there with links and interpolates. But we first had to learn about things not adding up and how links and cvts can fix this. We use cvts for squares as well. Like this we can tweak the cap height for coordination of the roman with the italic or the bold. Compare this to the blue lines in Type 1.
Grid-fitting is
Links round strokes to the nearest number of pixels at any ppem size, and using cvts makes them come out the same width. Links do not specify a number of pixels nor address a specific pixel. But after linking, we may be left with knees or elbows and other unfortunate pixel patterns. First, we should make sure no link with round-to-halfgrid etc. can control this pattern.
A delta can e.g. at 12 pt/96 dpi (16 ppem) move the off-curve point at the top 1/8 pixel to the left and another delta can move a point at the bottom 1/8 pixel to the right. These deltas apply to
We'll have to check and fix all sizes likely to be displayed on screen. We can insert a delta between links and interpolates or add a bitmap for a particular size if this saves many deltas.
Hand hinting requires a lot of work. While VTT makes it easier to learn and faster to do the work, we still have to learn all the various hinting strategies and do the work. Auto-hinting would be nice to have, but would you trust a computer to have enough "taste" to make the right trade-offs, always? What is the "right" trade-off, anyway? Are the trade-offs always the same ones? Or are they different for different fonts, usages, or customers? The future of VTT may look into more computer assistance in cases where it can make logical decisions or crunch numbers.
The main difference between Type 1 and TrueType is:
Which of the two should you put into an OpenType font? This depends on what you'll use it for.
|
|||
|
|||
| Microsoft Typography | Developer information | Visual TrueType resources | The raster tragedy... | |||
 |
|||
) and off-curve points (
). Both on- and off-curve points are called control points.
).
