Description of problem: mkfontscale can generate index with '?' How reproducible: always Steps to Reproduce: 1. wget http://support.wolfram.com/technotes/fonts/windows/files/MathFonts_TrueType_41.exe 2. unzip MathFonts_TrueType_41.exe 3. mkfontscale 4. grep '?' fonts.scale Actual results: math3m__.ttf -misc-????-medium-r-normal--0-0-0-0-p-0-iso10646-1 math3m__.ttf -misc-????-medium-r-normal--0-0-0-0-p-0-microsoft-symbol math3mb_.ttf -misc-????-bold-r-normal--0-0-0-0-p-0-iso10646-1 math3mb_.ttf -misc-????-bold-r-normal--0-0-0-0-p-0-microsoft-symbol Expected results: No output Additional info: This bug originates from the Bug #470619. According to "X Logical Font Description Conventions" the '?' is not allowed in XLFD fields. If the fonts are broken, the mkfontscale should fail.
Created attachment 404898 [details] screenshot of the font in question Well, the problem doesn't seem to lie in the font, but in mkfontscale. Nautilus with (I guess) freetype doesn't seem to have a problem with the font.
Created attachment 404901 [details] font in question With just this font in a directory, mkfontscale generates this fonts.scale file: 2 math3m__.ttf -misc-????-medium-r-normal--0-0-0-0-p-0-iso10646-1 math3m__.ttf -misc-????-medium-r-normal--0-0-0-0-p-0-microsoft-symbol
Behdad, any ideas, what's going on?
Just two more datapoints: johanka:~$ ftlint 120 /tmp/font/math3m__.ttf /tmp/font/math3m__.ttf: OK. johanka:~$ ftstring -m 'Moudivlacek' 120 /tmp/font/math3m__.ttf XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 158 requests (156 known processed) with 0 events remaining. johanka:~$ (ftstring doesn't show anything readable)
The font correctly follows the OpenType specification in defining 'name' table entries in platform=3, encoding=0 (symbol) instead of platform=3, encoding=1 (Unicode). mkfontscale however seems to be unable to handle that. The relevant parts of the spec are from this page: http://www.microsoft.com/typography/otspec/name.htm """ When building a Unicode font for Windows, the platform ID should be 3 and the encoding ID should be 1. When building a symbol font for Windows, the platform ID should be 3 and the encoding ID should be 0. ... ... Note that OS/2 and Windows both require that all name strings be defined in Unicode. Thus all 'name' table strings for platform ID = 3 (Windows) will require two bytes per character. Macintosh fonts require single byte strings. """ The following patch for mkfontscale makes it examine all platform=3 (Windows) encodings. Fixes the problem in this bug and I don't expect it introduce any issues. I do need to consult the OpenType mailing list though, since this part of the spec is a bit contradictory. Anyway, here's the patch for now. Should actually be safe to go in. diff -up xorg-x11-font-utils-7.2/mkfontscale-1.0.7/mkfontscale.c.symbol xorg-x11-font-utils-7.2/mkfontscale-1.0.7/mkfontscale.c --- xorg-x11-font-utils-7.2/mkfontscale-1.0.7/mkfontscale.c.symbol 2010-04-07 12:04:29.000000000 -0400 +++ xorg-x11-font-utils-7.2/mkfontscale-1.0.7/mkfontscale.c 2010-04-07 12:03:54.000000000 -0400 @@ -317,7 +317,7 @@ getName(FT_Face face, int nid) int i; if(getNameHelper(face, nid, - TT_PLATFORM_MICROSOFT, TT_MS_ID_UNICODE_CS, &name) || + TT_PLATFORM_MICROSOFT, -1, &name) || getNameHelper(face, nid, TT_PLATFORM_APPLE_UNICODE, -1, &name)) { string = malloc(name.string_len / 2 + 1); Ideally though, mkfontscale should be updated/rewritten to use fontconfig.
Build in http://koji.fedoraproject.org/koji/taskinfo?taskID=2105930