On Tue, 2012-04-03 at 11:35 -0400, Werner LEMBERG wrote: > > This is not strictly a vertical line spacing problem. The primary > > impact of this fix is that the metrics are now integer-scaled rather > > than fractionally scaled. (Indeed, this appears to be the reason the > > TT driver overrides the default size_request.) > > Yes. This is what the TrueType standard mandates for bi-level and > grey-level glyphs. Note that ClearType is *not* implemented in > FreeType yet! As soon as this happens, the situation changes. This > document > > http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx > > writes the following about the GETINFO bytecode instruction: > > Compatible Width ClearType (Selector bit 7, Return bit 14) > > This flag is requested by setting selector bit seven. If the > return bit fourteen is set, this indicates that the glyphs for > this font size will be adjusted post hinting in order to return > advance widths that are exactly the same as bi-level rendering. > If the return bit fourteen is not set, then the advanced widths > will be either returned as integers rounded to the nearest pixel > or rounded to the nearest sixteenth of a pixel. The former is > referred to as natural widths ClearType and the later as sub-pixel > positioned ClearType. > > > Integer scaling *may* have been the font designer's requirement. > > If you develop non-ClearType TTFs, this *is* a requirement.
I think I wasn't clear enough here about integer-scaled vs. fractionally scaled metrics. I'm not referring to "Fractional Advance Widths". I'm referring to when the x-scale is forced to be an integer-multiple of units/EM. For example, let's suppose that I use FT_Set_Char_Size() to specify the desired character width as 10.66 (really, 10 43/64). This generates a size_request() to the TT driver, which the TT driver initially forwards back to FT_Request_Metrics(). Assuming that units_per_EM == 2048, the computed x_scale will be: x_scale = 10.66 * 2048 = 21856 This represents a fractional scaling value. Let's say this produces a max_advance of 384 (or 6.0). Now, if the TrueType font header indicates that integer-scaled values are required (Flags & bit 3 -- see here https://developer.apple.com/fonts/TTRefMan/RM06/Chap6head.html) the TT driver recomputes x_scale: x_scale = 11 * 2048 = 22528 and then recomputes max_advance. This larger scalar produces a max_advance of 448 (7.0). Note that the advance width is integral but now larger by 1 pixel per glyph (for monospace fonts). Before the fix, these computations did not affect the font metrics for layout because the base metrics were not changed. Now they are. Just to be clear here: there is no way for an application to control this outcome. > > However, it could be argued that if the font designer was using > > FreeType to proof the work, that the 'intention' was for the font to > > look as it did before this fix. > > Hmm. A font designer who relies only on FreeType for proofing a font? At first glance, perhaps that seems wrong, but some Linux distributions are providing custom fonts specifically for the distribution. What else would be the reference standard in this situation but FreeType? My point here is not to argue for reverting this fix, but rather to illustrate the impact at a higher level. Hopefully this collective doesn't consider that to be immaterial. Regards, Peter Hurley _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
