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.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.