text: The Java virtual machines from Sun and IBM put the FPU into 64-bit mode rather
  than Linux's default 80-bit mode. For a little background on this, see:
  When in this mode, a bunch of weird rendering issues appear in text of GTK+ 2.8
  applications. The easiest way to see this is to watch the underlined characters
  in menus. The GTK+ application below reproduces the problem when using a font
  of "Arial 9" at 96-DPI. This bug should also occur under other OSs that use
  64-bit precision by default, such as FreeBSD, on other architectures such as
  PPC, and probably also when compiling cairo using -mfp-math=sse. However, I
  have not verified any of those configurations.
  #include <string.h>
  #include <gtk/gtk.h>
  #include <fpu_control.h>
  int main (int argc, char **argv)
  {
  GtkWidget *window, *menu, *vbox, *item, *bar;
  fpu_control_t fpu_control;
  _FPU_GETCW (fpu_control);
  fpu_control &= ~_FPU_EXTENDED;
  fpu_control |= _FPU_DOUBLE;
  _FPU_SETCW (fpu_control);
  gtk_init (&argc, &argv);
  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  g_signal_connect (G_OBJECT (window), "destroy",
  G_CALLBACK (gtk_main_quit), NULL);
  vbox = gtk_vbox_new (0, FALSE);
  gtk_container_add (GTK_CONTAINER (window), vbox);
  bar = gtk_menu_bar_new ();
  gtk_box_pack_start (GTK_BOX (vbox), bar, FALSE, FALSE, 0);
  item = gtk_menu_item_new_with_mnemonic ("_File");
  gtk_menu_shell_insert (GTK_MENU_SHELL (bar), item, 0);
  menu = gtk_menu_new ();
  gtk_menu_item_set_submenu (GTK_MENU_ITEM (item), menu);
  item = gtk_menu_item_new_with_mnemonic ("Open _Type...");
  gtk_container_add (GTK_CONTAINER (menu), item);
  item = gtk_menu_item_new_with_mnemonic ("Open Reso_urce...");
  gtk_container_add (GTK_CONTAINER (menu), item);
  item = gtk_menu_item_new_with_mnemonic ("Sho_w In");
  gtk_container_add (GTK_CONTAINER (menu), item);
  item = gtk_menu_item_new_with_mnemonic ("Ne_xt");
  gtk_container_add (GTK_CONTAINER (menu), item);
  item = gtk_menu_item_new_with_mnemonic ("Pre_vious");
  gtk_container_add (GTK_CONTAINER (menu), item);
  gtk_widget_show_all (window);
  gtk_main ();
  return 0;
  }
  This problem is not reproducable under GTK+ 2.6 and it smells a lot like a cairo
  problem.
  Created attachment 3949 [details]
  bad.png
  Created attachment 3950 [details]
  good.png
  Billy, is it the bug reported here:
  I hope it is. Anyway, can you check the patch attached in there?
  You reproduce this only on 86_64?
  I'll try out the patch. Note that this is on x86 not x86-64.
  See also downstream bug:.
  In particular, the screenshot attached. If this is really the problem, then I
  feel this should be upgraded to major (feel free to disagree <g>).
  I've tried the patch in
  against GTK+ 2.8.8, using Cairo 1.0.2. I still see the problem described in.
  Can you think of a workaround? We would rather not ship Eclipse 3.2 with this
  still broken....
  This bug hasn't even been tracked down to Pango or Cairo ... how could
  we suggest a workaround? I'd suggest that actually debugging the problem
  would help move the process along...
  (In reply to comment #6)
  > This bug hasn't even been tracked down to Pango or Cairo ... how could
  > we suggest a workaround? I'd suggest that actually debugging the problem
  > would help move the process along...
  I think either you misinterpreted the tone of my last post, or I'm
  misinterpreting the tone of this one. If I offended you, I'm sorry.
  My point was just that Eclipse is likely to need to write a workaround. We
  don't understand the internals of pango or cairo well, and would appreciate
  help. (At this point distributions have started shipping on broken versions
  of pango/cairo.)
  If you would like help debugging, then we're happy to lend some assistance.
  Behdad suggested a patch, which I've tried for him. Unfortunately, it didn't
  work. It might be helpful if you read, as it contains a little
  more detail about the effects we're seeing and things we've tried.
  I didn't mean to sound offended :-), but I was just trying to indicate
  that (as usual in free software), indicating that a bug is high priority
  for you usually doesn't produce too many results, especially if it is
  very hard to reproduce.
  I hadn't followed the link to the bug, but it appears glancing at it,
  that you guys have tracked it down to GTK+. If so, then you need to
  close this bug report, and open one against GTK+.
  (Really, it would seem very easy to take that investigation one step
  further and find the bug in that function. It might just be a
  incorrect rounding problem, say; but first step is to get the bug
  report filed against the right place.)
  Created attachment 4658 [details] [review]
  gdk patch
  Sorry I didn't feel like creating an account on Eclipse bugzilla. Can you test
  this Gtk+ patch and see if it's a fix?
  I didn't include the change to gtklabel; it seemed like it was included in
  error. The change to gdkpango.c doesn't seem to have any effect. Does the
  small test program given in comment #0 work for you?
  That test case is too subtle for me to verify. With my (rather huge) fonts, I
  don't see anything bad.
  If you have a C test program for the problem exposed in the Eclipse bug, I can
  test it.
  (In reply to comment #11)
  > That test case is too subtle for me to verify. With my (rather huge) fonts,
  > I don't see anything bad.
  It is definitely subtle. The Eclipse text selection issue is more jarring
  because it's one pixel of whitespace appearing throughout a text selection.
  But this only occurs in one of our custom widgets. It also seems to occur
  regardless of font.
  I'm not sure what your set-up is like, but with a JRE
  () and Eclipse
  (),
  you could see the problem for yourself.
  Otherwise, I'm happy to keep trying patches, and generally helping out any way
  I can.
  No, I cannot test that really.
  You said that the bug is in gdk_pango_layout_get_clip_region. Can't you just
  play with that function and see what's wrong? My gdkpango patch does something
  like that. You can at least report to us that "the text extents pango reports
  are these and these, and after rounding they become this with extended format,
  but that with double" so at least we know whether it's a pango bug, or gtk+...
  And other people can help if you open a bug against Gtk+... It's not obvious
  that it's a Cairo bug at all.
  Created attachment 5210 [details]
  test case
  This test case simulates a full selection text editor where the selection start
  in the middle of a word and spams all the way to the end.
  It uses clipping to draw a word that is half selected (to preserve arabic
  ligatures for example).
  It works fine with older version of pango (1.6.0), it fails on pango 1.10.2
  when the FPU mode is double. It works on pango 1.10.2 when FPU mode is extended
  (which is the default).
  Please, let me know if you need help to reproduce the problem.
  Created attachment 5211 [details]
  failing scenario
  Created attachment 5212 [details]
  working scenario
  In the failing scenario you can see the first selection box is short by one
  pixel in the height and width, this is because gdk_pango_layout_get_clip_region
  returns a region that is smaller.
  Note: to reproduce the problem you MUST have the right text, font, pango
  version, and fpu mode. I'm pretty sure this is a rounding problem and if you
  change anything you can get lucky and everything works....
  (In reply to comment #18)
  >...
  I'm a downstream maintainer of Eclipse for Gentoo. Finally got annoyed by the
  highlighting problem to start looking into it, and came across this bug.
  I tested a pango cvs snapshot from yesterday, and the Eclipse highlighting
  problem goes away. Awesome.
  Obviously, we missed the GNOME 2.14.1 release, but do you think we can see a
  1.10.2 release before the next GNOME release?
  Yes, this will be in the next version of GNOME.
  Behdad Esfahbod:
  Thanks for fixing this. But I need to support older version of gnome. So my
  question is:
  Is there any workaround I can use in my code (besides play the FPU mode) to
  fix this ?
  None that I know of.
  Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.