Discussion:
Render of Thai text with and without mouse selection
(too old to reply)
Pattara Kiatisevi
2004-12-23 10:45:01 UTC
Permalink
Hello kfm-devel,

I'm not sure if this is a problem of KHTML but maybe you guys here
have a clue. The problem is for some Thai texts, rendering becomes
different when one selects that text with mouse.

Here is the illustration (animated-GIF):
Loading Image...

The text in the input box (first frame) is rendered correctly.
The text without mouse selection (second frame) is most wrong.
The text with mouse selection (third frame) seems to be almost correct
but at the end of the string, there is an extra MAI_TO vowel (maybe
remnant from the second frame).

Cheers,
Otto
Leo Savernik
2004-12-23 15:45:29 UTC
Permalink
Post by Pattara Kiatisevi
Hello kfm-devel,
I'm not sure if this is a problem of KHTML but maybe you guys here
have a clue. The problem is for some Thai texts, rendering becomes
different when one selects that text with mouse.
Yes, this *is* a problem of khtml. Selection doesn't work for Arabic, Hebrew
and a multitude of other scripts either.
Post by Pattara Kiatisevi
http://webls.ex.nii.ac.jp/~pattara/tmp/kde-highlight-problem.gif
The page loads eternally. I haven't yet got all frames.
Post by Pattara Kiatisevi
The text in the input box (first frame) is rendered correctly.
Sure. This is a QTextEdit which doesn't suffer from KHTML bugs.

Lars told us at the Konference how to solve this particular bug in general,
but it's difficult to integrate the fix into KHTML's current architecture.
Don't expect it to be fixed before KDE 4.0.

[...]

mfg
Leo
Pattara Kiatisevi
2004-12-24 05:03:44 UTC
Permalink
Post by Leo Savernik
Post by Pattara Kiatisevi
Hello kfm-devel,
I'm not sure if this is a problem of KHTML but maybe you guys
here have a clue. The problem is for some Thai texts, rendering
becomes different when one selects that text with mouse.
Yes, this *is* a problem of khtml. Selection doesn't work for
Arabic, Hebrew and a multitude of other scripts either.
Post by Pattara Kiatisevi
http://webls.ex.nii.ac.jp/~pattara/tmp/kde-highlight-problem.gif
The page loads eternally. I haven't yet got all frames.
How about this?
http://webls.ex.nii.ac.jp/~pattara/kde/

Not sure of it is the same problem you mentioned. Because when text is
*selected* it is rendered *correctly*. It is wrong when it is NOT
selected. This happens only for some text though, like in the example
GIF: มีสังสรรค์ไหมวันนี้

MfG and merry chirstmas!
Pattara
Post by Leo Savernik
Post by Pattara Kiatisevi
The text in the input box (first frame) is rendered correctly.
Sure. This is a QTextEdit which doesn't suffer from KHTML bugs.
Lars told us at the Konference how to solve this particular bug in
general, but it's difficult to integrate the fix into KHTML's
current architecture. Don't expect it to be fixed before KDE 4.0.
[...]
mfg
Leo
Leo Savernik
2004-12-26 20:03:06 UTC
Permalink
Post by Pattara Kiatisevi
Post by Leo Savernik
The page loads eternally. I haven't yet got all frames.
How about this?
http://webls.ex.nii.ac.jp/~pattara/kde/
"Unknown host webls.ex.nii.ac.jp" :-(
Post by Pattara Kiatisevi
Not sure of it is the same problem you mentioned. Because when text is
*selected* it is rendered *correctly*. It is wrong when it is NOT
selected. This happens only for some text though, like in the example
GIF: àž¡àžµàžªàž±àž‡àžªàž£àž£àž„à¹Œà¹„àž«àž¡àž§àž±àž™àž™àžµà¹‰
The only thing I can perceive from the small example is that the text moves
around slightly while selecting it. This is the bug I'm talking about.

mfg
Leo
Ismail Donmez
2004-12-26 20:11:14 UTC
Permalink
Post by Leo Savernik
Post by Pattara Kiatisevi
Post by Leo Savernik
The page loads eternally. I haven't yet got all frames.
How about this?
http://webls.ex.nii.ac.jp/~pattara/kde/
"Unknown host webls.ex.nii.ac.jp" :-(
URL works here so I uploaded image to :
Loading Image...

Regards,
ismail
Otto Pattara
2004-12-27 16:26:26 UTC
Permalink
Post by Leo Savernik
Post by Pattara Kiatisevi
Post by Leo Savernik
The page loads eternally. I haven't yet got all frames.
How about this?
http://webls.ex.nii.ac.jp/~pattara/kde/
"Unknown host webls.ex.nii.ac.jp" :-(
Post by Pattara Kiatisevi
Not sure of it is the same problem you mentioned. Because when
text is *selected* it is rendered *correctly*. It is wrong when
it is NOT selected. This happens only for some text though, like
in the example GIF: มีสังสรรค์ไหมวันนี้
The only thing I can perceive from the small example is that the
text moves around slightly while selecting it. This is the bug I'm
talking about.
Yes, then I think we are talking about the same thing.

Would you mind sharing me some more information about this bug or
pointing to some URLs or source code? Just when you have time...

Cheers,
Otto
Post by Leo Savernik
Leo
Leo Savernik
2004-12-27 19:21:15 UTC
Permalink
Post by Otto Pattara
Post by Leo Savernik
The only thing I can perceive from the small example is that the
text moves around slightly while selecting it. This is the bug I'm
talking about.
Yes, then I think we are talking about the same thing.
Would you mind sharing me some more information about this bug or
pointing to some URLs or source code? Just when you have time...
Here you go:

Painting the selection:
http://lxr.kde.org/ident?i=paintSelection

Painting the text (and the selection in a different pass):
RenderText::paint
http://lxr.kde.org/source/kdelibs/khtml/rendering/render_text.cpp#L908

The problem is the fact that certain scripts combine adjacent characters when
drawn as a single text run. However, the selection may break the combining at
any point, thus producing two separate (and normally different looking)
characters, one in front of, and one after the selection boundary.

The proper solution would be to draw the full run, and clip it between the
combined characters (this will keep the characters from being drawn in their
separated form). However, there's no public API in Qt to retrieve the exact
point of clipping (or is there, Lars?).

Otto, feel free to work on the problem if you like. If you manage to achieve a
working result, I'd like to see the patches.

mfg
Leo
Allan Sandfeld Jensen
2004-12-27 19:53:22 UTC
Permalink
Post by Leo Savernik
The proper solution would be to draw the full run, and clip it between the
combined characters (this will keep the characters from being drawn in
their separated form). However, there's no public API in Qt to retrieve the
exact point of clipping (or is there, Lars?).
That would be the good looking solution. I don't know common practices in
these languages but would splitting the text at selection points with a
breakable zerowidth space and issuing a local relayout, be all that bad?

From experimenting with www.farsikde.org, I think there are more problems.
Often the selection doesn't not even appear near the cursor.

`Allan
Leo Savernik
2004-12-27 20:28:57 UTC
Permalink
Post by Allan Sandfeld Jensen
Post by Leo Savernik
The proper solution would be to draw the full run, and clip it between
the combined characters (this will keep the characters from being drawn
in their separated form). However, there's no public API in Qt to
retrieve the exact point of clipping (or is there, Lars?).
That would be the good looking solution. I don't know common practices in
these languages but would splitting the text at selection points with a
breakable zerowidth space and issuing a local relayout, be all that bad?
Yes, it might change the meaning of the word (maybe making out of "wisest
leader" a "fuckhead", thus escalating WW3 ;-) ). A zerowidth-space certainly
breaks up the combining, which leaves us in a situation no better than the
current one.
Post by Allan Sandfeld Jensen
From experimenting with www.farsikde.org, I think there are more problems.
Often the selection doesn't not even appear near the cursor.
Oh my gawd! We have problems, we have problems...

Excellent test page :-)

mfg
Leo
Lars Knoll
2004-12-27 21:35:33 UTC
Permalink
Post by Leo Savernik
Post by Otto Pattara
Post by Leo Savernik
The only thing I can perceive from the small example is that the
text moves around slightly while selecting it. This is the bug I'm
talking about.
Yes, then I think we are talking about the same thing.
Would you mind sharing me some more information about this bug or
pointing to some URLs or source code? Just when you have time...
http://lxr.kde.org/ident?i=paintSelection
RenderText::paint
http://lxr.kde.org/source/kdelibs/khtml/rendering/render_text.cpp#L908
The problem is the fact that certain scripts combine adjacent characters
when drawn as a single text run. However, the selection may break the
combining at any point, thus producing two separate (and normally different
looking) characters, one in front of, and one after the selection boundary.
The proper solution would be to draw the full run, and clip it between the
combined characters (this will keep the characters from being drawn in
their separated form). However, there's no public API in Qt to retrieve the
exact point of clipping (or is there, Lars?).
There are two ways to get it. One is through public API but painfully slow for
complex writing systems:

QFontMetrics::charWidth(const QString &text, int pos)

will give you the width of a character in context and makes it possible to
calculate the points you need.

The other one is quite a bit faster, but uses internal API (I can however
promise that the API will not change in a BIC way in Qt 3 anymore). That is
to use the QTextLayout class. QFontMetrics::charWidth() uses this class as
well, but recalculates a lot for every single character, something you could
avoid by using the class directly.

Cheers,
Lars
Post by Leo Savernik
Otto, feel free to work on the problem if you like. If you manage to
achieve a working result, I'd like to see the patches.
mfg
Leo
Continue reading on narkive:
Loading...