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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
