2016-03-02 21:24 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

All the ZnByteEncoders are automagically initialised from official specs, for MacRoman

self generateByteToUnicodeSpec: 'http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT'

This is certainly good and robust practice, and I don't suggest removing the correct version!
My question was more about the alternate library.

Before removing it, may I ask how the hell did it get broken?

It's not broken in Squeak and was not broken in pharo 1.4 for example.

Doesn't tell it something?

��

> On 02 Mar 2016, at 21:09, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
>
>
>
> 2016-03-02 20:18 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
> Max,
>
> > On 02 Mar 2016, at 19:57, Max Leske <maxleske@gmail.com> wrote:
> >
> > Just so I don��t forget: this test fails (since at least 1.3). I have determined the correct value (175) independently with the respective tables and by using uconv.
> >
> > testConversionToFrom
> >�� self assert: (('��' convertToEncoding: 'mac-roman') convertFromEncoding: 'mac-roman') = '��'.
> >�� self
> >�� assert: ((Character value: 216) asString convertToEncoding: 'mac-roman')
> >�� equals: (Character value: 175) asString
> >
> > As far as I can tell, this flaw is not exclusive to the mac-roman encoding. However, latin1 and UTF8 are probably fine.
> >
> > Max
>
> That is because you are using the wrong encoders.
>
> | encoder string |
> encoder := #macroman asZnCharacterEncoder.
> string := '��'.
> (encoder decodeBytes: (encoder encodeString: string)) = string. " => true"
> encoder encodeString: (Character value: 216) asString. " => #[175]"
>
> We should probably replace the old ones with the newer ones in Pharo 6.
>
> Regards,
>
> Sven
>
> +1, why the hell maintaining two versions, one bogus?
>
> However, since this does not seem broken in Squeak, that makes a perfect example for investigating how and why such trivial error creeps in.
>
>