[squeak-dev] I18n and Cairo/pango rendering

tim Rowledge tim at rowledge.org
Wed Jul 23 00:01:49 UTC 2014



> On Jul 22, 2014, at 14:14, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> 
> 
> 
> 2014-07-22 23:02 GMT+02:00 tim Rowledge <tim at rowledge.org>:
>> (Snip).
> 
> MacRoman? Beware Tim, you have slept too long, but I must tell you the awfull truth now.
> ByteString are not anymore MacRoman encoded.
> They are ISO8859L1 (latin 1) which matches Unicode on first 256 code points...
> 
Oh. Well, I was basing my comment on comments in code that I came across. Guess they need fixing. This isn't something I've ever felt a need to think about before so it's all new and clunky to me...
One thinks springs to mind though - if  the basic ByteString is Latin-1/utf why do we have any code to convert ? Right now (in my 4.5) it looks like there is a relatively slow check for any non-compliant chars in the #squeakToUtf8 method. Can we drop that now? It would likely be nice if any old ByteString were acceptable to the Cairo/pango plugin. 

> Converting to UTF8 seems hackish, but should just work.
> Why would you have to go back from UTF8? Optimization? (storing the UTF8 result)

Hopefully we don't really need to go back in my usage case - Scratch i18n short strings with very little editing. I can probably keep the 'real' string and convert as and when needed for the displaying methods, maybe even caching the converted form. For the longer term we should at least consider doing a better cleaner job so as to life in a world where it at least appears that UTF8 is becoming a new standard. I have no idea how everyone is handling editing variable length encoded texts.

> 
> Or could we create a UTF8String class?
Certainly a possibility. A simple version might just do a convert/edit/reconvert for every operation, but there has to be a better way.

/tim
{insert witticism here}

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140722/422bc86b/attachment.htm


More information about the Squeak-dev mailing list