All the ZnByteEncoders are automagically initialised from official specs, for MacRoman
self generateByteToUnicodeSpec: 'http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT' > On 02 Mar 2016, at 21:09, Nicolas Cellier > <nicolas.cellier.aka.n...@gmail.com> wrote: > > > > 2016-03-02 20:18 GMT+01:00 Sven Van Caekenberghe <s...@stfx.eu>: > Max, > > > On 02 Mar 2016, at 19:57, Max Leske <maxle...@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. > >
