Chris Withers wrote:
Pragmatic solution: define the character-set as iso-8859-1 in the page containing the form which in turn contains the rich-text-editing widget,
Well, every HTML page should specify the character set it's encoded with or it's not valid HTML <0.5 wink>
Instead of UTF-8 definition, rather than instead of nothing.
Windows clients ensure that what goes into the entry field conforms to that character-set, whether it's typed or added by a paste operation from, say, Word.
That seems like it should always happen. What happens on non-windows clients?
Currently, I don't care so haven't tested - user group is closed and all use some variety of Windows/Word. Will get round to testing from Mac clients one day and will report back.
Remaining issues: UTF-8-encoded Unicode breaks big-time. I know this is an issue for MySQL, and it seems to be an issue for Zope also.
What are the MySQL issues? What appear to be the Zope issues?
Hard to disentangle. MySQL explicitly doesn't support any encoding of Unicode except in latest (4.1?) versions - and then you need to define tables as UTF-8 at creation. 4.1 is not stable. In older versions the theory is that you can define fields as BLOBs but haven't tried that. In text fields only standard entity references work, (though they shouldn't). best Mark Barratt