| Summary: | Fontconfig does not create a proper charset for symbol.ttf | ||
|---|---|---|---|
| Product: | fontconfig | Reporter: | Christian Lupien <lupien> |
| Component: | library | Assignee: | Keith Packard <keithp> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Behdad Esfahbod <freedesktop> |
| Severity: | normal | ||
| Priority: | medium | CC: | akira |
| Version: | 2.8 | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | pdf file showing the glyph problem | ||
The fix is: <!-- From suse-pre-user.conf in fontconfig-2.8.0-20.1.src.rpm from http://software.opensuse.org/search?baseproject=openSUSE%3AFactory&p=1&q=fontconfig http://bugs.gentoo.org/show_bug.cgi?id=303591 --> <match target="pattern"> <test name="family"> <string>symbol</string> </test> <edit name="family" mode="append" binding="strong"> <string>OpenSymbol</string> </edit> <edit name="family" mode="append" binding="strong"> <string>Standard Symbols L</string> </edit> </match> I maintain a config with this and other fixes: http://forums.gentoo.org/viewtopic-p-6183606.html#6183606 I tried your conf (placed it in ~/.fonts.conf but it did not fix the problem I described above.
From what I understand, your conf adds aliases for symbol (to be replaced by OpenSymbol or Standard Symbols L) if missing.
My problem is not with those fonts but from the symbol.ttf (from microsoft or wine) that is used if installed.
Under my fedora 12, there is rule 30-urw-aliases.conf that ends with
<match target="pattern">
<test name="family">
<string>Symbol</string>
</test>
<edit name="family" mode="append" binding="same">
<string>Standard Symbols L</string>
</edit>
</match>
which is the equivalent to your config.
I think this is same issue I saw in another font and possibly may be fixed by Bug#35517. actually removing the cmap format 0 subtable from symbol.ttf fixes this issue. |
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.
Created attachment 35044 [details] pdf file showing the glyph problem The problem is that some programs (evince,...) show the wrong glyph when the symbol.ttf font is installed. This is on Fedora 11 and 12 with: fontconfig-2.8.0-1.fc11.x86_64 fontconfig-2.8.0-1.fc12.x86_64 fontconfig-2.8.0-1.fc12.i686 I discovered the problem in evince but it can also be seen with the gucharmap application and probably many others. With those applications, and if the symbol.ttf font is installed, I get some wrong characters displayed. In particular (see attached file), the Delta symbol is replaced by the emptyset symbol. Other characters are also affected in a similar way. To test, load the attached file with the symbol.ttf installed as a font somewhere. My font file comes from an windows XP machine but the wine distribution seems to have one in /usr/share/wine/fonts/symbol.ttf (wine-fonts-1.1.32-1.fc11.noarch). Then look at the line using the symbol font and you will see that the symbols are not the correct ones (compared to adobe reader for exemple). In gucharmap, go the the Mathematical operators block and look at the U+2205 (emptyset) and U+2206 (Increment) using the Symbol font. They should be different glyphs (Increment should look like Delta) but they are the same. This is the problem for evince because it looks for the U+2206 when it wants the Delta from the Symbol font. This is also seen in the charset glyph coverage using "fc-query symbol.ttf". Some unicode code points are wrongly avertised as present (they point to the wrong glyph). Like U+0152(Œ), U+0153(œ) which show instead the mathematical symbol of "element of" and "not an element of". Those 2 are not glyphs in the symbol font. Looking at the source code I guess the problem stems from fontconfig using the MacRoman table to produce the charset but this is wrong for the symbol font (code 0xc6 in MacRoman is the increment glyph, but for the symbol font code 0xc6 is the emptyset glyph).