Just looking in Pharo 2.0 release on Unicode handling today ... The class comment for UTF8DecomposedTextConverter says
"An UTF8DecomposedTextConverter converts from decomposed UTF8 using the UnicodeCompositionStream." I don't see UnicodeCompositionStream ... at least not in this One-Click image today ... I also wonder why we do not have more of a parallel in the BOM methods for the utf8 and utf16 Converter classes to ensure converter instances have polymorphic behavior ... even such simple accessors as BOM value methods are not implemented ... but one class has a >>nextPut... method that is doing a BOM check each time, so it is not just avoiding a method call here if that was the issue, I suppose ... I do use Unicode every day in my Japanese app's and this mismatch across converters looks as if it would bite someone eventually ... Or no ? Maybe I am missing something obvious ... Btw, are we safe to assume that no one in India (or elsewhere with IT shops) is still using utf32 ? -- View this message in context: http://forum.world.st/Unicode-in-Smalltalk-tp4676821p4677182.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
