Georg Baum wrote:
Am Samstag, 2. Dezember 2006 22:43 schrieb Abdelrazak Younes:
Georg Baum wrote:
It is simple: Just do a proper conversion to QString. If André is right
then everything else will be done by Qt.
This is simple now (and this is good news) because QString support ucs4
in version 4.2.
That does not really make a difference. The version for qt 4.1 is 3 lines
instead of 1 line for qt 4.2, so it is more an esthetic issue than a real
problem. I did not measure the performance, but the feeled performance did
not change, so it certainly does not make a very big speed difference
either.
I also think it will not make a noticeable difference.
As for the other version (for Qt < 4.2), I did not do it
this way because I always supposed that QString will not interpret the
covenverted string correctly. I would be happy to be proved wrong.
That is not a QString issue (for qt4 anyway. For qt3 you would be right,
since QString used ucs2 internally). QString uses utf16 internally in qt4,
and that can store everything that can be stored in ucs4.
If there is any problem it is in the font/metrics/painting stuff, but I
repeat: According to André it works.
According to Lars (IIRC), Qt4 did not support full utf16 (i.e. no
surrogate). That's why I didn't bother with the conversion. Looks like
Qt4.2 has changed that and the full utf16 is supported as the new
from/toUcs4() seems to imply.
What I did not like with your solution was that you replaced a slow,
but
working solution
Correction, I don't think it was not working. IIRC, the out of range
chars were simply trashed.
I looked it up, and you are right, since it was converted to ucs2 and not
utf16. Seems my memory fades :-(
I am quite sure there will be any difference, you can shove it in.
You mean you would be surprised if there is a difference or not?
Surprised if there is difference, you can then commit safely.
But I
would be very surprised if it worked for Qt < 4.1. Did you try with
unicode characters that are outside the 16 bit range?
No. I only made sure that we do everything needed to support that. If it
still does not work then this is a qt problem and can probably hardly
fixed by us.
Why would you be surprised? Please note that utf16 that is used internally
in QString can handle all ucs4 characters (as surrogate pairs if needed),
so there is no technical reason why it should not work.
See above.
There's still one thing missing to support full ucs4. In GuiFontMetrics,
ucs4_to_qsting() shall be used instead of ucs4_to_qchar() in order to
get the real width of the ucs4 char.
??? I removed ucs4_to_qchar() and added this comment instead:
// no QChar const ucs4_to_qchar(char_type) because not all UCS4 code points
// can be translated to one QChar
Ah... very good, I over-read this part of the patch.
There's still one thing to support: some characters (mostly arabic) have
different width depending on their placement in a word. So we might need
to maintain multiple width cache for that kind of chars.
I agree with Jean-Marc that it is too much. LyX should also be usable
on
machines with less than 512 MB RAM.
Hum, there's a few hundreds MB between 37 and 512 ;-)
And there are a few other programs I want to run besides LyX and the OS. If
every program took 10 Mb of memory as if it was nothing then we are
quickly at the limit. 5 years ago I used to work with a 64 MB machine, and
that worked quite well.
I know and agree FWIW. I was playing the devil's advocate.
Abdel.
