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