On Jan 20, 2011, at 2:31 59AM, Levente Uzonyi wrote:
On Thu, 20 Jan 2011, pharo@googlecode.com wrote:
Comment #2 on issue 3554 by ryd...@gmail.com: CP1252TextConverter new does not work http://code.google.com/p/pharo/issues/detail?id=3554
That's not the "right" way to do it anymore, ever since ByteTextConverter superclass was introduced. (AFAICT that was before 1.0, but after the soup implementation)
The only methods subclasses should implement are class-side methods: byteToUnicodeSpec encodingNames (languageEnvironment)
I'd suggest updating the Soup package to include the implementation found in Core, which works in all versions of Pharo.
Will it work in Squeak? I'm asking because we're using it in one of our projects and I'll be unhappy if it becomes uncompatible with Squeak the way SmaCC, OB, eCompletion, etc did.
Levente
Almost... The class variables hold all 256 entries instead of just the non-ascii range, and initialization logic was made a bit different as well when ByteTextConverter was introduced to Squeak :/ It should work with an additional method: CP1252TextConverter class >> initializeDecodeTable ^decodeTable := (0 to: 127) , self byteToUnicodeSpec (decodeTable would be undefined in Pharo, but the method never used) and changing the initialize method, unless you want to implement initializeTables in ByteTextConverter as: initializeTables self initializeDecodeTable; initializeEncodeTable; initializeLatin1MapAndEncodings Looking at initialize implementations in current squeak subclasses that might not be such a bad thing :) Cheers, Henry PS. Is there's a bug in CP1250 in squeak, or is there some hack I don't know about? AFAIK, ⬠(20AC) should be at 128...