Re: wv: windows codepages, changes to allow conversion to unicode

Justin Bradford (justin@ukans.edu)
Tue, 9 Nov 1999 20:48:43 -0600 (CST)


> >(function pointer) = wvGetCodePageConverter(lid)
> >unicodechar = (function pointer)(8 bit codepage character);
>
> OK. If you and Justin agree that the API should really be this low-level,
> that's fine by me. AFAIK, we'll never want to see the character variant in
> the Windows codepage, but just go directly to the full unicode equivalent.

While we probably will never care about anything but Unicode, it might be
possible other apps using wv do (or will). I don't think adding this extra
conversion step is a big deal, and it makes wv more flexible for other
uses. Possibly, a UnicodeCharHandler (which automatically converts to
Unicode for us) in addition to the current CharHandler would be in order
to hide some of this from the application. I imagine most apps would
prefer straight Unicode, anyway. How do you feel about that Caolan? I can
add it, if you think it's a good idea.

As for the conversion tables, I think it's a great idea. I'm currently
mapping a few Windows codepage oddities in the importer code, and there's
no way that was ever going to become an extensible, non-kludge solution to
the problem.

> >This change will be in the next cvs commit I do tomorrow or later on, so
> >I'm afraid that there will probably be some failed builds because of it.
>
> Justin, is this something you'll be able to get to? If not, let us know.
> It sounds like a very quick fix, so it shouldn't be that bad for someone
> else to paste in the relevant code snippet.

Yeah, I can do it.
Caolan, email me directly when you commit the code. If you give me an
approximate time (and timezone), I can be available (most likely) to fix
the importer right away. It would probably be best to email the list, too,
in case I'm unable to fix it right then.

Justin



This archive was generated by hypermail 1.03b2.