Quote:
|
Originally Posted by Laurens
I wish Plucker supported Unicode! That would solve the whole character encoding issue. At any rate, UTF-8 would be the way to go, since this works well with standard string functions that assume NULL-terminated sequences and, more importantly, does not require a change to the Plucker specification. IIRC, MultiByteToWidechar() does not support UTF-8 under Windows Mobile, so you'd have to write something yourself. Very easy to do, however.
|
I think there's no point in solving encoding issues *that* way.
Plucker DB supports any 8-bit and 7-bit encoding. Unfortunately it, too, falls to the pit of confusing encodings with charsets, but that doesn't stop it from supporting any "8-bit" charset and UTF-8. Furthermore, Plucker DB can have different charsets for different (sequences of) records. This is achieved by using the ExceptionalCharset metadata fields.
I've added support for charsets to the recent Vade-Mecum (0.6.6). It understands any charset for which WinCE on a target device has corresponding code page. This includes UTF-8 and UTF-7 that *are* supported at least in WM2003. Different charsets for different records are supported too.
What's missing, is the support for charsets for the sequences of "linked" records (those having "Click here for the next/previuos part" links) since the reference (Python) distiller attaches an ExceptionalCharset metadata block to the first record of such sequences only. It does so also for the sequences of continued records, but that's easily handled. Handling this behaviour for linked records is a hell, but I'm working on this.
If you wish I can help you handle charset issues in Sunrise XP since I have some degree of understanding about how this is implemented in the reference distiller. And at least you can grab the source of VM and read this:
vim-charsets.html
I think we should move to e-mail to speed up the efforts.
You can mail me at flatworm{}users.sourceforge.net
and khomoutov{}gmail.com