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.