Squeak to/from UTF-8 conversions

nicolas cellier ncellier at ifrance.com
Tue Jun 26 18:08:01 UTC 2007


However, if you strip the language tag, you will run into very minor 
bugs with the A macron and a macron, because their encodings have been 
hijacked as CrossedX and EndOfRun in the CharacterScanner family (clever 
trick when Characters were 256). I searched how these damned characters 
could ever work in Squeak and Sophie, and found black magic was this 
language tag.

Andreas, maybe you could have a look at how RTF text are converted in 
SOphie, it seems to deal with language tag correctly, at least with 
extended latin characters.

Nicolas

Bert Freudenberg a écrit :
> 
> On Jun 26, 2007, at 9:19 , Andreas Raab wrote:
> 
>> Hi -
>>
>> I was working on a little improvement in UTF-8 conversion speed (so 
>> far it's about 150x faster for latin-1 text ;-) and for measuring the 
>> improvements was running a test that said:
>>
>> strings := String allSubInstances.
>> 1 to: strings size do:[:i|
>>     original := strings at: i.
>>     utf8 := original squeakToUtf8.
>>     copy := utf8 utf8ToSqueak.
>>     original = copy ifFalse:[self error: 'Encoding problem'].
>> ].
>>
>> When I ran this test it failed on each and every WideString instance. 
>> Digging into it, it seems that all of the WideStrings in Squeak have a 
>> language tag that is being supplied implicitly by the current 
>> LanguageEnvironment.
>>
>> Questions:
>> 1) From what it looks like right now there is no way to preserve that 
>> language tag through a UTF-8 conversion. Is this indeed the case or am 
>> I missing something?
>> 2) Given that my language environment is being set to Latin-1, how 
>> should clients treat UTF-8 to provide the "proper" language tag? For 
>> example, I expected that a client be able to read and write UTF-8 text 
>> without implicitly providing that language tag. If that's the case, 
>> then how does one store these in common text files? (I could see how 
>> to do this for formatted text but not for "plain text files" without 
>> further attributation)
>> 3) More generally asking, isn't the language tag here more of a 
>> "decorator" along the lines of text attributes? This would certainly 
>> model more closely the effect that I'm seeing here (some attributes 
>> are dropped by the squeak -> utf8 -> squeak conversion) *except* that 
>> I didn't expect any lossy conversion for strings (contrary to Text 
>> where dropping text attributes is obviously lossy).
> 
> Nice catch. We had the discussion before, and this to me is another hint 
> that we really should strip the language tag from Strings and move it to 
> Text attributes. For rendering bare strings the default language could 
> be taken from the current environment. The problem is, IIUC, that 
> currently a lot of bare strings are passed around so it was simpler to 
> just tag the language onto the string itself.
> 
> - Bert -
> 
> 
> 
> 




More information about the Squeak-dev mailing list