Hi Juan & all! Having used StrikeFonts v6 for some while now, I have some more feedback: - . are really hard to read on a 1920x1200 17inch display... I'm not sure if it's the size of the glyph in it self, but it really could at least use some more space up front, usually I can't distinguish it from the preceding character. - It does not play well with the displayMultiString:on: from: to: at: kern: baselineY: - method used for WideStrings in general, ASCII characters are then rendered as black blocks. Thing is, MultiDisplayScanner which is used in Pharo for TextEditors (well, most of them anyways, I haven't checked all) uses non-ascii characters as a stopCondition, thus any sequence in the string from:to: will always either be valid ASCII, or all unicode (for which ? is rendered correctly). So a possible solution is to check if first character is ascii, if so it's safe to use the standard method (which renders it correctly). Yet, it feels quite hackish to rely on the scanner dividing string into runs of ascii and non-ascii characters, (much faster though, as if the original method is used, a run of ascii-characters that happens to be part of a WideString, will be rendered one character at a time). It is however, a hack which will be quickly discovered if the pre- conditions change :) Would you be able to find some time to look into what it'd take to make the glyph-by-glyph rendering in misplayMultiString: work with the new StrikeFonts? To the others: - Would such a hack be acceptible for the moment? + Speeds up font rendering of strings with non-ascii characters (both FreeType and StrikeFonts) + Makes StrikeFonts v6 usable without further modifications - Is a hack dependent on the Scanner implementation. + Is easy to detect if preconditions change (basically, font rendering will fail :P) The alternate which is not Scanner dependent, is iterating each character in the run instead of just checking first. It's slower, and StrikeFonts will still fail to render if displayMultiString: goes unfixed. Not to mention, if a Scanner is made that does not make sure runs are either ASCII or from an extended charset, the slow method of rendering a glyph at a time will be used anyways... Cheers, Henry P.S: To the "We have FT fonts! Why care about StrikeFonts?"- replies. Yes, I know that. But: - Rendering is (no offense) slow. - Juans StrikeFonts code is good quality code of how it should be done. Increasing the ratio of such code compared to that which makes you go "Uuuuhh... " is one of the main reasons I got interested in Pharo, to make the Smalltalk experience for those determined on an OS- licensed smalltalk comparable to that I have working in VW on a daily basis.