Sounds like the same kind of change I did to Strike Font character rendering :) Might want to check if the method hasWideCharactersFrom:to: I implemented for Strings/Text might be of use to clarify the code intent. (See StrikeFont >> displayString:on:from:to:at:kern: for an example usage) Cheers, Henry On Nov 1, 2009, at 11:06 43PM, Nicolas Cellier wrote:
2009/11/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Nicolas
I was wondering why TextConverter>> initialize was calling nextPut: to Stream: which is abstract.
which initialize ? initializeLatin1MapAndEncodings ? yes, it is intended for concrete subclass only and triggered by lazy initialization.
So I imagine that only subclasses are invoking this behavior.
So I was trying to understand the speed up idea but I failed (because I did not know the speed up of andreas).
Stef
MultiByteFileStream iterate Character by Character which is sloooow... The idea is that most ASCII characters won't need a conversion. Andreas trick is to do a fast scan of the String for detecting chunks not requiring translation (there are fast primitives to do that on a ByteString). This enables putting these chunks of String without translations directly on the stream...
I generalized this to any format (not only UTF8) I generalized this to lineEndConventions (for converting CR/LF, MultiByteFileStream iterates char by char too)
That's for writting only. Maybe someday we should also speed reading up.
Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project