GNOME Bugzilla – Bug 101856
PangoFT2 is unable to use fonts that have no Unicode mapping table
Last modified: 2004-12-22 21:47:04 UTC
WIth the latest cvs from 2002-12-22 I've got this error while trying to load some fonts in the text tool : ** (gimp-1.3:31608): WARNING **: Unable to load unicode charmap from font file /home/cjean/.fonts/sanka___.ttf ** (gimp-1.3:31608): WARNING **: Unable to open font file /home/cjean/.fonts/sanka___.ttf for font Sanka 24, falling back to /usr/X11R6/lib/X11/fonts/Type1/UTBI____.pfa Some other ttf fonts are working great, and in gnome2 ALL my ttf are ok
Looks as if the font in question doesn't provide an Unicode character mapping. It thus can't be used by PangoFT2. I'm afraid, there's not much we can do about broken fonts.
According to: http://freetype.sourceforge.net/freetype2/docs/reference/ft2- base_interface.html#FT_Encoding and http://developer.apple.com/fonts/TTRefMan/RM06/Chap6cmap.html TrueType fonts do not need to have a unicode map. So there is indeed a bug, but the problem is not in the font, but in PangoFT's assumption that a Unicode map is present in all valid TT fonts. Since regular Pango allows encodings other than Unicode, it is strange that PangoFT does not. If PangoFT intends to only support the subset of TrueType that has a Unicode map included, it should be well documented.
Reassigning to the Pango product.
Just because you can create a font without a unicode character map, doesn't mean that Pango has to be able to do anything with it... Input text to Pango is always Unicode characters, so it can't do anything with a font that doesn't have a defined relationship to Unicode and probably will never be able to do anything with such a font. In general, however, you shouldn't be getting these warnings because they shouldn't get listed. What version of Pango? If you are using fontconfig, what version of fontconfig?
This happened with : pango-1.1.1 fontconfig-2.0
Changed the version according to the info given by the bug reporter.
It appears that fontconfig will now list fonts with only AppleRoman or AppleSymbol encodings. Ugh. Making Pango able to support these encodings is probably only a day or so of work, but there is the potential for fontconfig to add new encodings without warning. It seems that we either need: - Fontconfig to export functionality that would allow an app to support any encoding that fontconfig supports without having to know about it adance. - Fontconfig to support only listing fonts with a fixed set of character maps.
So do I understand you correctly that all backends suffer from this problem? I had a quick look at the code and the xft backend seems to have the same set_unicode_charmap() call as PangoFT2 but it doesn't use it all. I'd like to help to extend Pangos handling of charmaps but I'd need a few pointers. Can you tell me what exactly needs to be done?
Could Pango use the fontconfig API for unicode->glyph mapping? That would make future mapping support in fontconfig usable by Pango without additional changes. If not, can we figure out what fontconfig needs to add for this to work?
*** Bug 106197 has been marked as a duplicate of this bug. ***
*** Bug 107434 has been marked as a duplicate of this bug. ***
For the HEAD branch of Pango, fixing the FT2 backend *might* be as simple as A) Remove the set_unicode_charmap() call B) Make pango_ft2_font_real_get_glyph() use FcFreeTypeCharIndex() rather than than FT_Get_Char_Index() C) Make pango_ft2_font_real_has_char() work using FcCharSetHasChar(), getting the charset from ft2font->font_pattern. I think that with the recent changes to encapsulate the FT2/Xft backend difference, these are the only places that care about having the unicode charmap set. I've already fixed up pango/opentype/pango-ot-info.c/synthesize_class_def to handle the case of no unicode charmap gracefully. (That was crashing before with the Xft backend.) Since I don't test the FT2 backend, it would be nice if someone else would tackle the above. I don't think it is worth trying to do anything for Pango-1.2.x, since that would require changes all over every FT2 backend.
Created attachment 19638 [details] [review] patch that implements the changes as proposed by Owen
The patch I've attached implements the suggested changes. However I have not given this any testing yet. With pango CVS head, pangoft2topgm crashes for me (with or without this change).
The crash in pangoft2topgm is definitely unrelated to my changes. I've now tested my patch with gimp-1.3 and it seems to work just perfectly. Fonts such as Webdings, that didn't use to work, can now be used and they give the same character-glyph mapping as shown by gucharmap. I am waiting for your OK to commit this change.
I'd really like to get this patch into CVS so that it gets wider testing (it still works fine for me). Is there a particular reason the patch wasn't approved yet?
Hmm, perhaps because the bug wasn't assigned correctly...
Patch looks good to commit. It would be *very* nice if you tracked down the pangoftopgm crash for you, since no, it doesn't crash for me.
With latest CVS, the crash in pangoft2topgm is gone. No idea what was causing it back then. Might have been a problem on my side. Applied the patch to the HEAD branch: 2003-11-18 Sven Neumann <sven@gimp.org> * pango/pangoft2-fontmap.c: removed the set_unicode_charmap() call. Made pango_ft2_font_real_get_glyph() use FcFreeTypeCharIndex() rather than FT_Get_Char_Index(). Madepango_ft2_font_real_has_char() use FcCharSetHasChar(). This allows to use PangoFT2 with all font encodings supported by fontconfig and fixes bug #101856.
Sven, the change you committed with that changelog entry actually looks like the fix for bug 123602. Whoops. :) So I guess you should apply the patch for this bug and figure out how to clean up after the other one....
2003-11-20 Sven Neumann <sven@gimp.org> * pango/pangoft2-fontmap.c: reverted the patch for bug #123602 since I only applied it accidentally. I still believe the patch should go in though. * pango/pangoft2.c: really applied the fix for #101856 as described below.
*** Bug 131988 has been marked as a duplicate of this bug. ***
*** Bug 132086 has been marked as a duplicate of this bug. ***
I wonder if there's a chance to workaround this problem in The GIMP. What I am seeking for is a way to get to know whether a font provides an Unicode character mapping or not. This would have to happen using the fontconfig API so that we have a chance to not list those fonts in our font selector. Do you see a way to make this happen?
*** Bug 132101 has been marked as a duplicate of this bug. ***
*** Bug 135121 has been marked as a duplicate of this bug. ***
*** Bug 135595 has been marked as a duplicate of this bug. ***
So, if there's no fontconfig API to find what character mapping a font provides (or not provides), perhaps there's a way to convince Pango-1.2 to use a fallback font that works instead of choosing a fallback that has the same problem (resulting in a call to exit). Owen, Keith, any ideas?
No further changes to Pango-1.2.x are planned.
I am not asking for any changes to Pango-1.2. I am asking for advice on how to configure Pango and fontconfig so that this problem doesn't lead to a crash (or rather a call to exit, which is a rather akward thing to do for a library). I haven't seen this problem causing a crash on Linux but it seems that on Windows it is fatal. So I assume that the difference is in the default fonts.conf that is installed on Win32 platforms. Why does Pango choose a useable fallback font on Linux but selects a broken one on Windows?
*** Bug 138224 has been marked as a duplicate of this bug. ***
*** Bug 137550 has been marked as a duplicate of this bug. ***
*** Bug 138316 has been marked as a duplicate of this bug. ***
*** Bug 138358 has been marked as a duplicate of this bug. ***
*** Bug 138383 has been marked as a duplicate of this bug. ***
how is it possible that this bug is marked RESOLVED, FIXED, when it is not the case, ... In Gimp 2.0.0 for Windows, it still result in a fatal crash
Your windows binary still uses pango-1.2 while the fix appeared in pango-1.3.1. Someone needs to bring the windows binaries uptodate. Tor wants to wait until glib-2.4.1 is released.
*** Bug 138447 has been marked as a duplicate of this bug. ***
*** Bug 138511 has been marked as a duplicate of this bug. ***
*** Bug 138572 has been marked as a duplicate of this bug. ***
*** Bug 138910 has been marked as a duplicate of this bug. ***
*** Bug 139131 has been marked as a duplicate of this bug. ***
*** Bug 139606 has been marked as a duplicate of this bug. ***
*** Bug 139915 has been marked as a duplicate of this bug. ***
*** Bug 139962 has been marked as a duplicate of this bug. ***
*** Bug 141018 has been marked as a duplicate of this bug. ***
*** Bug 141141 has been marked as a duplicate of this bug. ***
*** Bug 141283 has been marked as a duplicate of this bug. ***
*** Bug 141470 has been marked as a duplicate of this bug. ***
*** Bug 141647 has been marked as a duplicate of this bug. ***
*** Bug 141976 has been marked as a duplicate of this bug. ***
*** Bug 142007 has been marked as a duplicate of this bug. ***
*** Bug 142104 has been marked as a duplicate of this bug. ***
*** Bug 142391 has been marked as a duplicate of this bug. ***
There are a whole lot of dupes appearing on this bug, most of them seem to be related to GIMP not including a patched version of Pango. When is Gimp going to be released with the appropriate fix?
The GIMP developers don't release anything but source code so this is up to the people building the binary packages. So far these people have been waiting for a gtk+-2.4 release that works on win32 so that they can include pango-1.4 (which depends on glib-2.4). AFAIK there are still issues with gtk+-2.4 on the Win32 platform, so it might take a while.
*** Bug 142771 has been marked as a duplicate of this bug. ***
*** Bug 142787 has been marked as a duplicate of this bug. ***
*** Bug 142800 has been marked as a duplicate of this bug. ***
*** Bug 143027 has been marked as a duplicate of this bug. ***
*** Bug 143178 has been marked as a duplicate of this bug. ***
*** Bug 143202 has been marked as a duplicate of this bug. ***
Is there any way to issue the patch in a downloadable format? I was able to look at the patch, but since I know nothing of programming beyond QBasic-which is archaic-I can't implement the patch for my system. I think issuing a downloadable patch would greatly aid in the resolution of this problem.
Pango 1.4.0 is available prebuilt for Windows from www.gimp.org/win32/downloads.html. You will also need to update GLib to 2.4.1.
Thank you for your help. I have downloaded the suggested items. I am still recieving fatal errors. In particular, the baskville.ttf font is always listed on the error report. I am thinking of deleting that particular font and seeing what happens. I will post here with the results.
For me downloading and installing Pango 1.4.0 and glib 2.4.1 worked fine! Thanks.
*** Bug 143986 has been marked as a duplicate of this bug. ***
*** Bug 144111 has been marked as a duplicate of this bug. ***
*** Bug 144247 has been marked as a duplicate of this bug. ***
*** Bug 144365 has been marked as a duplicate of this bug. ***
*** Bug 144451 has been marked as a duplicate of this bug. ***
Just as a user's suggestion, can we minimize the pop-up window so a new user will not perceive this is a crashing bug? The pop-up window was on top of the GIMP and if you close the window, GIMP closes too.
Please do not attach completely unrelated comments here. If you want this to be discussed, open a new one.
*** Bug 144484 has been marked as a duplicate of this bug. ***
*** Bug 143159 has been marked as a duplicate of this bug. ***
*** Bug 149461 has been marked as a duplicate of this bug. ***
This situation is an interesting counter-example to the often-quoted ability of the open source community to repair a needed piece of software. This is apparently not important enough to users like me to actually learn the code and fix it myself (not that clueful about C, see), and there's no incentive to maintainers to fix it and release a fixed version. I'm *really* looking forward to seeing this bug closed. If any other reporters are interested, could we sponsor some effort to make this minor (but, from the duplicate bug count, obviously troublesome) nit go away? Apart from this one small issue my use of the Gimp continues to be a learning experience. It's a great piece of software.
Steve: the bug has been fixed a long time ago (2003-11) and the bug-fix is available in current win32 binaries. The only thing that this bug shows is that the typical Win32 user is unable to read and that he/she depends on others to build binaries for him/her.
Sven: not an unreasonable assumption, I suppose. It certainly does say "fixed" in the resolution. Thanks for pointing that out. I'm wondering whether your version of the future includes teaching the whole population to build the Linux kernel? Barring that, what will happen after Total World Domination, when the majority of Linux users are also unable to read and depend on others to build binaries for them? Just for your information, I first started programming in 1967, and worked for Sum Microsystems as a senior technical support specialist, so I don't really consider myself a typical Windows user. But anyway, we have each others' email addresses so we can hack away at each other without cloggin up the bugzilla channel, should we feel like it. Thanks for pointing out the obvious, which I freely admit I should have had the gumption to notice for myself. Perhaps a commercial distro might be a simpler solution for an old fart who's tired of compiling code - most of my programming nowadays is Python and JavaScript :-) And thanks again for the Gimp.
I am not suggesting that everyone compiles their software themselves. I don't do that myself with the exception of the software that I am actively developing myself. But it would have helped a lot if one of the many many win32 users would have built binaries with the fixed libraries instead of wasting their time duplicating this bug report over and over again. Anyway, in the meantime the usual supsects have made available fixed binaries (thanks!) and all should be well.