Bidirectional text in tooltips

Bidirectional text in tooltips

[Eli Zaretskii]

I have committed to trunk revision 102265, which makes tooltips
support bidirectional text.  I made changes in w32fns.c and in xfns.c.
Only the former is fully tested, for the latter I could only test that
it builds correctly.  Please make sure the X build works as well (you
will find test cases near the end of this mail).

There remain two cases where I don't see in the sources the same code
as in xfns.c and w32fns.c.  One is the GTK build, which under
x_gtk_use_system_tooltips calls xg_prepare_tooltip and
xg_show_tooltip, which use GTK features to display tooltips.  Can
someone see if GTK does TRT when it shows tooltips with bidirectional
text (again, using the text cases below)?  If it doesn't, we will need
to find a way to fix that somehow.

The other case is NS.  IIUC, the place that calculates the width of
the tooltip is the setText method of the EmacsTooltip class,
implemented on nsmenu.m.  My reading of the setText method is that it
assumes a single line of text in the tip, is that right?  If so,
that's a bug in itself, I think.  In any case, if the NS build uses
the string length, it relies on the NS toolkit to DTRT, I think; can
someone please see if the results are satisfactory?

To test bidirectional tooltips, evaluate in "emacs -Q":

  (setq-default bidi-display-reordering t)

and then use these two test cases (copy-paste them into *scratch*):

(x-show-tip "שלום, עולם אכזר ומכוער!")

(x-show-tip "שלום, עולם אכזר ומכוער!

Hello, world!")

The first one should show a one-line tooltip, the second a 3-line
tooltip (with the 2nd line empty).  In both cases, the tooltip should
be just wide enough to display the entire text of each non-empty line.
(With previous code, you'd see an ugly 80-column wide tooltip in both
cases.)  In the second test case, the first line should be flushed all
the way to the right edge of the tooltip, while the last line should
be flushed to the left.

TIA

Re: Bidirectional text in tooltips

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]

Well, not sure how it is supposed to look, but here are the NS and Gtk+ 
results.  The first image is from NS, but Gtk+ looks the same.  The ! has 
moved to the left, maybe that is intended?

For the second test, the NS does not align the same way Gtk+ does (I added 
some text to make this clear).  I guess NS is wrong here.

	Jan D.


Eli Zaretskii skrev 2010-11-06 15.14:
> I have committed to trunk revision 102265, which makes tooltips
> support bidirectional text.  I made changes in w32fns.c and in xfns.c.
> Only the former is fully tested, for the latter I could only test that
> it builds correctly.  Please make sure the X build works as well (you
> will find test cases near the end of this mail).
>
> There remain two cases where I don't see in the sources the same code
> as in xfns.c and w32fns.c.  One is the GTK build, which under
> x_gtk_use_system_tooltips calls xg_prepare_tooltip and
> xg_show_tooltip, which use GTK features to display tooltips.  Can
> someone see if GTK does TRT when it shows tooltips with bidirectional
> text (again, using the text cases below)?  If it doesn't, we will need
> to find a way to fix that somehow.
>
> The other case is NS.  IIUC, the place that calculates the width of
> the tooltip is the setText method of the EmacsTooltip class,
> implemented on nsmenu.m.  My reading of the setText method is that it
> assumes a single line of text in the tip, is that right?  If so,
> that's a bug in itself, I think.  In any case, if the NS build uses
> the string length, it relies on the NS toolkit to DTRT, I think; can
> someone please see if the results are satisfactory?
>
> To test bidirectional tooltips, evaluate in "emacs -Q":
>
>    (setq-default bidi-display-reordering t)
>
> and then use these two test cases (copy-paste them into *scratch*):
>
> (x-show-tip "שלום, עולם אכזר ומכוער!")
>
> (x-show-tip "שלום, עולם אכזר ומכוער!
>
> Hello, world!")
>
> The first one should show a one-line tooltip, the second a 3-line
> tooltip (with the 2nd line empty).  In both cases, the tooltip should
> be just wide enough to display the entire text of each non-empty line.
> (With previous code, you'd see an ugly 80-column wide tooltip in both
> cases.)  In the second test case, the first line should be flushed all
> the way to the right edge of the tooltip, while the last line should
> be flushed to the left.
>
> TIA
>

[-- Attachment #2: ns1.png --]
[-- Type: image/png, Size: 8447 bytes --]

[-- Attachment #3: ns2.png --]
[-- Type: image/png, Size: 13230 bytes --]

[-- Attachment #4: gtk.png --]
[-- Type: image/png, Size: 12310 bytes --]

Re: Bidirectional text in tooltips

[Jan Djärv]

Eli Zaretskii skrev 2010-11-06 15.14:

> The other case is NS.  IIUC, the place that calculates the width of
> the tooltip is the setText method of the EmacsTooltip class,
> implemented on nsmenu.m.  My reading of the setText method is that it
> assumes a single line of text in the tip, is that right?  If so,
> that's a bug in itself, I think.

It does not, sizeWithAttributes returns the bounding box the drawn string 
would have.  It handles newlines.

	Jan D.

Re: Bidirectional text in tooltips

[Eli Zaretskii]

> Date: Sat, 06 Nov 2010 18:23:03 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: emacs-devel@gnu.org
> 
> Well, not sure how it is supposed to look, but here are the NS and Gtk+
> results.

Thanks.

> The first image is from NS, but Gtk+ looks the same.

This image looks good, although the string seems to be flushed to the
left; the w32 display is slightly better in this case, and so should
be the non-GTK display on X.  However, judging by the second example,
I'm guessing that this is NS-only problem, in this case as well, and
GTK did flush the text to the right, did it?

> The ! has moved to the left, maybe that is intended?

Yes, because the text is read right-to-left, so the reordering engine
shows it correctly, with the exclam at the end of the text.  (This
doesn't happen in the x-show-tip call in *scratch*, because the
trailing quote prevents that, per UBA, the Unicode Bidirectional
Algorithm.)

> For the second test, the NS does not align the same way Gtk+ does (I added
> some text to make this clear).  I guess NS is wrong here.

Yes, GTK's display is correct, NS's display is not.  Looks like NS
does not determine the paragraph direction dynamically as required by
the UBA.  Perhaps there's some NS setting outside Emacs that enables
that?

Anyway, it looks like these two toolkits produce reasonable results,
even though NS is slightly incorrect.  (I don't expect many tooltips
with mixed L2R and R2L text.)

Thanks for testing this.