On Jan 20, 2011, at 2:31 59AM, Levente Uzonyi wrote:
> On Thu, 20 Jan 2011, [email protected] wrote:
>
>>
>> Comment #2 on issue 3554 by [email protected]: 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...
