Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:

| Georg Baum wrote:
| > Am Donnerstag, 24. August 2006 18:47 schrieb Abdelrazak Younes:
| >> Enrico Forestieri wrote:
| >>> I have compiled a Cygwin version of LyX/Qt4 using the native GUI
| >>> (no
| > X11)
| >>> and now I see the chinese characters mentioned by Abdel when I load
| >>> an old document. I also get a lot of messages on the console:
| >>>
| >>> Error returned from iconv
| >>> EILSEQ An invalid multibyte sequence has been encountered in the input.
| >>> When converting from UCS-4 to UCS-2.
| >>> Input: 0xff 0xff 0xff 0xa2 This was not the case with Qt3 where
| >>> the characters were simply hollow
| >>> squares on screen. However, when I start a new document the characters
| >>> are shown correctly.
| >> The attached patch at least make LyX show normal text correctly.
| > Abdel,
| > do you still need that patch?
| > There is something with the byte order I don't understand. I just
| > found out that with the iconv on my little endian linux box UCS-4 ==
| > UCS-4BE. That means that the bytes coming from iconv are in big
| > endian byte order. This is reversed in bytes_to_ucs4:
| | Interestingly enough the Qt docs says that Big endian is the order
| prescribed by the Unicode Standard in the absence of higher-level
| protocols. Here is the full text:

Talks about big-endian Unicode text files. We don't use multi-byte
encoding in text files so that point is moot. (and if Qt forces us to
use big-endian internally then that is a severe Qt limitation)

And the unicode standard does not apply to the encoding used inside
lyx. (We want to use host-native endianess there.)

Of course not. I was talking about iconv which AFAIK has been created to convert files. My guess is that it is not surprising that BE is the default for UCS4 even on LE machine.

Looks like I always appear stupider than I really am when I try to explain something :-(

Abdel.


Reply via email to