On Apr 19, 2010, at 4:16 25PM, Schwab,Wilhelm K wrote:
What about what Microsoft (sorry...) calls font metrics? By involving a device context (canvas in our world), one can find out how big a particular string will be on the target device's resolution, and allowing for kerning.
So far, I have found #heightOf: and #widthOf: in the Font hierarchy, which means they know nothing of the intended device, and do not (obviously anyway) seem to know about kerning. Are there glaringly missing features here, or is this simply an consequence of printing being done via PostScript and therefore still in terms of point sizes?
Bill
StrikeFonts take their glyphs from a bitmap, thus will have constant pixel sizes. (decentKern is used for italic glyphs though) As far as I know, kerning is not done for StrikeFonts, the only related use is of ascentKern when making a bitmap for italic derivatives of basefonts. Changing StrikeFonts to include kerning info will mean rewriting the string-rendering primitive, so I wouldn't get my hopes up it is likely to happen anytime soon. For FreeTypeFonts, getWidthOf: uses AbstractFont>>pixelSize, which again uses TextStyle>>pointsToPixels: , which relies on TextStyles>>pixelsPerInch. pixelsPerInch _could_ be set based on information gathered at startup about resolution and screen size, but is not done currently, so a default of 96 is used. FreeTypeFont>> widthOfString:from:to: returns a width which takes kerning into account. (in theory, see the comment for clarifications) In essence, if those features are important to you: - Use FreeTypeFonts. - Set TextStyle pixelsPerInch: to a computed value at startup. Cheers, Henry