GNOME Bugzilla – Bug 149858
gnome-print unable to handle ttf fonts with missing style information in 'name' table
Last modified: 2004-12-22 21:47:04 UTC
There are some ttf fonts out there which don't have the right entries for the members of the ttf 'name' table such as font family, sub family (style), PS name. Out of this font-config mandates the family name and gnome-print can live without a PS name (it substitutes Helvetica for that). But with the missing sub family (style) entry the font is not included in the print output. This is wrong as eventhough ttf specs mandates that the name table should be present for each ttf, it does not mandate the any of the entries to be present and it is the resposibility of the library/app to make up for this and work even though this piece of information is absent. Due to this issue, we have problem printing in Korean locales.
Created attachment 30420 [details] [review] libgnomeprint/gnome-fontmap.c patch
Created attachment 30421 [details] [review] -do-
oops bad day, had to create a second one.
Comment on attachment 30421 [details] [review] -do- Seems reasonable please commit to head.
committed
Hi Jody, Sorry for reworking the patch a bit. Seems like the font-config functions used for adding the patterns etc. are working not consistently when I tested this fix in multiple versions of fontconfig. Indeed that's an issue with fontconfig. Looking more to it I found we can remove the fontconfig dependency and the resultant patch works in places where they have this fontconfig issue present. Pl. check the attached patch (which should be applied after the original as head is already patched) A coupole of simple warnings are also fixed inthat.
Created attachment 30724 [details] [review] patch
Suresh : can you be more specific about the problem the new patch solves ?
The whole purpose of this function (fcpattern_to_gp_font_entry) seems like to fill in the GPFontEntry struct, FcpatternAddString/FcPatternGetStrin,functions (which was introduced in the original patch) does not seem to do it's job of setting the required FC_STYLE attrib which we created from slant/weight and retrieving it later. Looking at the rest of the code I found that this exercise is not necessary we can get the values and directly fill in the FcPatternGetString once we make it out of the slant/weight, doing like tbat, removing the font-config dependency seems to be the better approach.
Oops a typo, read like I found that this exercise is not necessary we can get the values and directly fill in the GPFontEntry once we make it out of the slant/weight.
The intent of the patch is pretty clear, but I am still unclear on why you think it is necessary. Your mail mentions problems with some versions of font-config ? Which versions ? How does pango work when these routines are broken ?
Well, I certainly like the new patch *much* more than the earlier version. Calling FcConfigGetFonts() and then modifying the returned patterns is a very bad idea, since you are modifying the fonts for *all* users of fontconfig. It does seem to me that the current code will "work" with current versions of fontconfig, but I wouldn't consider it legal code. (A patch was sent to the fontconfig mailing list by a KDE developer that put the global font database into shared memory between processes. It wasn't accepted, but something similar will likely be done in the future.)
In the first place, having fonts without these values are cery bad and approximation from slant/weight and putting it globally may not be that bad. But since in the new patch that issue is not there as Owen said thsi is better. Sorry I did not remember the fontconfig versions which caused the issue. If this patch is approved, Jody could you pl. apply it, I'm off to a month vacation and won't be able to do much during this.
Comment on attachment 30724 [details] [review] patch Sounds reasonable.