ing.
saveLString(str);
} else {
Lstring temp = conv->convert(str);
saveLString(temp);
}
}
(7) But there's a problem in the above code. If the file encoding is a 8bit
encoding and we use 16bit
version of LString. How could we save this string? A possible looks like
for(i=str.begin();i!=str.end();i++) {
char c = (char) *i;
fputc(fp,c);
}
But we lose the opportunity to use uncide as file encoding now because we cast
string back to 8 bit here.
>
> Greets,
>
> Asger
I'll try to make a sample prototype recently to explain my through future.
Yu-Chung Wang
he toUnicode and fromUnicode methods are only for
> the Unicode inset and for the character level operations for poorly
> supported languages.
>
> Regards,
> SMiyata
Why I concern about is how Encoding will be used in LyX. Is it used by Unicode
inset only? I think so according to its current structure. If you want to use
it in
text buffer. I suggest we need another methods toWidthCharacter and
fromWidthCharacter
to translate between variable elength ncoding and fix legth encoding.
Yu-Chung Wang
Asger Alstrup Nielsen wrote:
>
> Let's detail the steps:
>
> Step 1: This step is done line by line (or key by key), so the memory
> overhead of switching to 16-bit LString even if the file is 8-bit is
> insignificant.
>
But I still don't understand you want to choice LString instead of C++
s not apropriate palce to
ask such question, but I've done such stupid things for a couple of times.
Yu-Chung Wang
oach, we don't need Unicode anymore and the LString could be
send to X function call
directly because X support fix byte encoding for a lot of one to two
bytes encoding.
Therefore, in my point of view, the design of Encoding seems that
doesn't fill the requirement? I hope
I'm wrong.
Yu-Chung Wang
