After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 315486 - pi character is rendered too high and too far to the left
pi character is rendered too high and too far to the left
Status: RESOLVED DUPLICATE of bug 144456
Product: vte
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-09-07 20:44 UTC by Loïc Minier
Modified: 2006-04-12 07:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Loïc Minier 2005-09-07 20:44:58 UTC 
Hi,

This bug was reported both to Debian and Redhat at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288662
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140681

The issue seems to be with the Pi glyph under UTF-8 locales.

Bye,
Comment 1 Behdad Esfahbod 2006-03-03 01:29:10 UTC 
I don't see why Pi is in vte_unichar_is_local_graphics.
I can see how that would have been useful five years ago, but not now.
I will remove it after GNOME 2.14 is out.
Comment 2 Behdad Esfahbod 2006-03-13 06:53:38 UTC 
Any idea which of these we should change:

        case 0x00a3: /* british pound */
        case 0x00b0: /* degree */
        case 0x00b1: /* plus/minus */
        case 0x00b7: /* bullet */
        case 0x03c0: /* pi */
        case 0x2190: /* left arrow */
        case 0x2191: /* up arrow */
        case 0x2192: /* right arrow */
        case 0x2193: /* down arrow */
        case 0x2260: /* != */
        case 0x2264: /* <= */
        case 0x2265: /* >= */
        case 0x23ba: /* scanline 1/9 */
        case 0x23bb: /* scanline 3/9 */
        case 0x23bc: /* scanline 7/9 */
        case 0x23bd: /* scanline 9/9 */
        case 0x2409: /* HT symbol */
        case 0x240a: /* LF symbol */
        case 0x240b: /* VT symbol */
        case 0x240c: /* FF symbol */
        case 0x240d: /* CR symbol */
        case 0x2424: /* NL symbol */
        case 0x2592: /* checkerboard */
        case 0x25ae: /* solid rectangle */
        case 0x25c6: /* diamond */

The change will probably be to try to find a glyph in the font for them, and fall back to the current code, instead of the other way which is what's happening now.

The slight problem with that is that we may prefer the local rendering to a glyph from a random font that happens to have a glyph for it.  That's not easy to fix though.
Comment 3 Behdad Esfahbod 2006-04-01 02:48:51 UTC 
Ok, I was wrong.  The problem indeed is that Bitstream Vera has a Pi glyph and since by default vte uses Xft directly, it just picks the Pi glyph from the first font that covers it.

The proper font selection is indeed implemented in Pango and won't suffer from this problem as much.  No idea how to fix it at this stage without serious performance penalty.  Need to think more about it...
Comment 4 Behdad Esfahbod 2006-04-12 07:10:23 UTC 

*** This bug has been marked as a duplicate of 144456 ***