Georg Baum wrote:
Lars Gullik Bjønnes wrote:
- All output:
- text (perhaps finished?)
Not at all. I sent a simple patch that almost finished it, but in
discussions it turned out that it was the wrong way to do it. Don't you
remember?
I think we have no choice but use ucs4/docstring for all strings that can
contain unicode internally.
Agreed, IMHO, before any cleanup can take place we need to simplify the
API and/or provide helper functions. Writing six lines for a string
conversion or manipulation is no-fun.
- Change the internal gettext machinery (message.C, B_, _) to
use unicode.
Could you do that please? I think that Jean-Marc's idea of a temporary
_ucs4() function makes a lot of sense.
| 2) How can I fix this endianness problem on windows?
Why should the endianness on windows (x86) be different than on linux (x86)?
That sure is weird...
| 2-a) how do I convert the lyx file to unicode so I can load them in
| English rather than Chinese?
On window? pttrt. On linux use iconv:
iconv --from-code=latin1 --tocode=utf8 --output \
UserGuideUTF8.lyx UserGuide.lyx
Don't do that, lyx2lyx will do it for you. Reading and writing .lyx files
works well. Make sure that you change the file format manually to 249 of
all files that were saved in utf8 when the file format was still 248.
If lyx2lyx support is done already why don't we do the change in trunk?
Abdel.
