[ I still am not accepted to the mailing list to POST ... ]

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 ?