Description of problem: The "Numero sign" (U+2116, №) glyph in the LucidaTypewriter font has double width, but its metric says that it is a single-width character. This causes incorrect rendering of the text containing this character in the LucidaTypewriter font - tne right part of Numero sign gets overwritten by subsequently rendered characters. Version-Release number of selected component (if applicable): If I can map this font to the package name, I think it is (at least) xorg-x11-fonts-100dpi-7.1-2 from Fedora Core 6, up to xorg-x11-fonts-100dpi-7.2-3 from Fedora 8, which is the latest one I have. I am not sure how this maps to Product and Component names in the fd.o bugzilla. How reproducible: 100% Steps to Reproduce: $ gconftool-2 --set /apps/gnome-terminal/profiles/Default/font \ -t string 'LucidaTypewriter 12' $ gconftool-2 --set /apps/gnome-terminal/profiles/Default/use_system_font \ -t bool false $ Xvfb :5 & $ DISPLAY=:5 PS1='№XY 123' gnome-terminal & $ xwd -display :5 -root -out x.xwd $ xwud -in x.xwd Actual results: The numero sign is rendered as a double-width character, but because the metric says it is single-width, the adjacent character "X" overwrites part of it. Expected results: Either the numero sign glyph should have a single width (most other monospaced fonts have this), or the metric should be updated to reflect the actual double width of the character. Note: this bug has been originally reported in Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=240070 - I am trying to move it upstream. In that bugzilla entry there are also several screenshots documenting this bug.
I cannot find a U+2116 NUMERO SIGN (№) glyph in the Lucida Typewriter bdf fonts as found in the xorg git repos. In fact, I don’t see *any* Cyrillic glyphs, and no iso8859-5 subsets get installed. So, either Fedora patches the BDFs or this is a font substitution issue. Do you see the character in apps which use server-side fonts? You can test the glyph coverage of all of the versions of said fonts which are configured for server-side rendering with this: :; xlsfonts|egrep typewriter.+10646|sort -u|xargs -n 1 xfd -fn Leave out the «.+10646» to test each of the subsets as well, or use «.+8859-5» to test the ISO8859 Cyrillic glyphset. Note that is is typical for character-cell targeted apps like terminal emulators to use the metrics of the first specified font to specify the character cell and, when glyph substitution occurs, to shoehorn the foreign (to the first-specified font) glyph into the cell. This will either result in overlap or on squished glyphs if the substitute glyph is wider than the cell. I bet gnome-terminal is grabbing the glyph from your default client-side font (typically Sans).
I don't think we have patched *the fonts* of xorg-x11-fonts. This is the list of patches in our xorg-x11-fonts package: [matej@viklef devel]$ ls *.patch encodings-1.0.0-encodings-fontdir-fix.patch font-alias-1.0.0-fonts-alias-fontdir-fix.patch (that's checkout from fedora CVS). And the patches contain just what the name suggests (fixing of paths): [matej@viklef devel]$ wc -l *.patch 11 encodings-1.0.0-encodings-fontdir-fix.patch 11 font-alias-1.0.0-fonts-alias-fontdir-fix.patch 22 celkem [matej@viklef devel]$ Now to the lucidatypewriter font itself. We are using these upstream sources: [matej@viklef devel]$ grep ^Source.*lucidatypewriter xorg-x11-fonts.spec Source18: ftp://ftp.x.org/pub/individual/font/font-bh-lucidatypewriter-100dpi-1.0.0.tar.bz2 Source19: ftp://ftp.x.org/pub/individual/font/font-bh-lucidatypewriter-75dpi-1.0.0.tar.bz2 [matej@viklef devel]$ with these MD5 checksums c44d3f730564da465993e9292a33c235 font-bh-lucidatypewriter-100dpi-1.0.0.tar.bz2 fdd9be5b9db94ef363a33e39b7977e2b font-bh-lucidatypewriter-75dpi-1.0.0.tar.bz2
Created attachment 15753 [details] [review] encodings-1.0.0-encodings-fontdir-fix.patch Just to be sure there is no misinformation, this is the first Fedora patch of xorg-x11-fonts
Created attachment 15754 [details] [review] font-alias-1.0.0-fonts-alias-fontdir-fix.patch and this is the second
(In reply to comment #1) > I cannot find a U+2116 NUMERO SIGN (№) glyph in the Lucida Typewriter bdf > fonts as found in the xorg git repos. In fact, I don’t see *any* Cyrillic > glyphs, and no iso8859-5 subsets get installed. I cannot claim to be an Unicode expert, but why do you think U+2116 is a Cyrilic glyph? I found it in http://www.unicode.org/charts/PDF/U2100.pdf (Letterlike Symbols).
As for the comment #1: You are probably right - I am not able to reproduce this problem with xterm (I don't see a NUMERO SIGN glyph when I paste it to xterm -fn '-*-lucidatypewriter-*-r-*-*-14-*-*-*-*-*-iso10646-1'). So it is probably a font substitution problem then. However, the problem is that with this font, gnome-terminal uses other double-width characters (like Hiragana or Kanji) correctly, just the U+2116 character is the problem. So which other component should I fill this bug against? I would also like to know which font is used for substituting characters here: I have tried to change the gnome-terminal's font to the following fonts I have, and all of them display the NUMERO SIGN as a character with single-width metric _and_ glyph: Bitstream Vera Sans Mono DejaVu LGC Sans Mono DejaVu Sans Mono Liberation Mono Luxi Mono Monospace Nimbus Mono L The following two settings display the problem: Miriam Mono CLM LucidaTypewriter
I prepared the *-ISO10646-1 BDF fonts in ssh://git.freedesktop.org/git/xorg/font/bh-lucidatypewriter-100dpi ssh://git.freedesktop.org/git/xorg/font/bh-lucidatypewriter-75dpi You can easily confirm yourself that all the glyphs in these BDF files are fixed-width: $ cd font/bh-lucidatypewriter-100dpi/ $ grep DWIDTH *.bdf | sort -u lutBS08.bdf:DWIDTH 7 0 lutBS10.bdf:DWIDTH 8 0 lutBS12.bdf:DWIDTH 10 0 lutBS14.bdf:DWIDTH 12 0 lutBS18.bdf:DWIDTH 15 0 lutBS19.bdf:DWIDTH 16 0 lutBS24.bdf:DWIDTH 20 0 lutRS08.bdf:DWIDTH 7 0 lutRS10.bdf:DWIDTH 8 0 lutRS12.bdf:DWIDTH 10 0 lutRS14.bdf:DWIDTH 12 0 lutRS18.bdf:DWIDTH 15 0 lutRS19.bdf:DWIDTH 16 0 lutRS24.bdf:DWIDTH 20 0 As you can see, there is only a single pixel-width value (DWITDH attribute) associated with any glyph within in each of these fonts. What happened here is that some modern terminal emulators have very little respect for the notion of a fixed-width font. They behave more like web browsers and cobble together a Unicode repertoire as complete as possible from whatever font they can get hold of, independent of the resulting glyph size. I know that konsole does that by default under openSUSE, and I suspect that gnome-terminal is not much better. I'll leave it to other to decide whether that is a "bug" or merely a "controversial feature". Ask the developers of your favorite terminal emulators for advice; there may well be configuration options to change the font-selection strategy. Xterm has a IMHO much more sane font-selection semantics here and will only load two fixed fonts at a time (not counting bold), one single-width and one double-width for CJK. Preferably, use a font that contains the full glyph repertoire that you regularly need. The BDF versions of LucidaTypewriter obviously do not fulfill your repertoire requirements.
(In reply to comment #5) I called it a Cyrillic character because that is where it is most commonly used/found. Note its inclusion in eg the ISO 8859-5 and MacCyrillic sets. (In reply to comment #6) Fontconfig supports the FC_DEBUG environmental and libXft has XFT_DEBUG. Set those to integers to turn on various debug outputs. The relevant #defines are: #define XFT_DBG_OPEN 1 #define XFT_DBG_OPENV 2 #define XFT_DBG_RENDER 4 #define XFT_DBG_DRAW 8 #define XFT_DBG_REF 16 #define XFT_DBG_GLYPH 32 #define XFT_DBG_GLYPHV 64 #define XFT_DBG_CACHE 128 #define XFT_DBG_CACHEV 256 #define XFT_DBG_MEMORY 512 and #define FC_DBG_MATCH 1 #define FC_DBG_MATCHV 2 #define FC_DBG_EDIT 4 #define FC_DBG_FONTSET 8 #define FC_DBG_CACHE 16 #define FC_DBG_CACHEV 32 #define FC_DBG_PARSE 64 #define FC_DBG_SCAN 128 #define FC_DBG_SCANV 256 #define FC_DBG_MEMORY 512 #define FC_DBG_CONFIG 1024 #define FC_DBG_LANGSET 2048 #define FC_DBG_OBJTYPES 4096 AND together the debugs you want. Again, I suspect you are getting U+2116 from the Sans alias. (It is possible you may need to recompile fontconfig and/or libXft to enable said DEBUG support; I get it by default from the Gentoo ebuilds but I think I recall some previous conversations indicating that it wasn't compiled in by default on (some of) the rpm and deb dists.)
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.