GNOME Bugzilla – Bug 166540
Truetype TTF fonts not loading correctly when having spaces in its names
Last modified: 2005-03-02 23:23:23 UTC
Please describe the problem: When using truetype fonts which have spaces in its names, e.g. "Wingdings 3", The Gimp will use another truetype font instead, in this case "Wingdings". Editing the TTF-file with an hexeditor and renaming the font without spaces (replace with a ".") and reloading xfs worked around the problem. Steps to reproduce: 1. Install some truetype fonts with spaces in its names, that have identical names until the first space (e.g. "Wingdings", "Wingdings 2", "Wingdings3") 2. Start the gimp 3. Try some characters and use a font with a space within its name (e.g. "Wingdings 3" Actual results: You will notice that characters of the first font will be used (e.g. "Wingdings" instead of "Wingdings 3" Expected results: Correct use of truetype fonts with spaces in its names. Does this happen every time? Yes Other information:
There are other fonts with spaces in their name - e.g. Arial vs. Arial Narrow, or Courier and Courier New - which don't have this problem. Maybe this is a different problem that gets solved by editing the font file? What happens if you change the font name to something else completely - maybe "Wingdings ABC" instad of "Wingdins 3"?
Please report this problem to the fontconfig developers. Fontconfig chooses the actual font that is being used. We cannot do anything about it.
@Michael: You are right, there is no problem with fonts that are named like "ABC ABC", only font named like "ABC 1" "ABC 2" are affected. @sven: Well, I couldn't find any other application having this problem with using TTF fonts. It's only The Gimp.
It isn't 100% obvious that this is not a GIMP problem -- if, for example, gimp_container_get_child_by_name() was finding the wrong child, it could give rise to a problem like this. (There is no reason to think that it is, though.) Nevertheless it might be worth pursuing this a bit further before dismissing it. The first question I have is, do the names of these fonts appear correctly in the fonts menu? I assume yes, but would like you to verify if you could.
Yes, they appear correctly there.
I can confirm that all fonts are presented correctly in the fonts menu.
Feel free to reopen if you want to investigate this further.
Created attachment 37210 [details] gfontsampler screenshot showing the correct usage of fonts with spaces and numbers in its name
Created attachment 37211 [details] the gimp screenshot showing the result of wrong usage of fonts with spaces and numbers in its name
Created attachment 37212 [details] the gimp screenshot showing font selection box. here you can see the problem too.
So, I have check several other applications. No problem there! So, i don't think it has something to do with fontconfig or pango or whatever. I have created some attachments for you to see the problem (screenshots, one made from gfontsampler and two made from GIMP.
I see exactly the same behavior for each font which end with <space><number>.
The problem is that the final number is being interpreted as a font size in the pagno font description, and not as part of the font name.
Created attachment 37221 [details] [review] Patch to fix pango_font_description_to_string This patch makes pango_font_description_to_string add a "," to the end of the description string, if the last character is a number, and no size is included. This makes sure the resultant description isn't ambigious wrt size and other parts of the name.
Oh, and the patch removes the result->len > 0 bit in the insert size code, since prior code guarantees that that will never be false.
Created attachment 37222 [details] [review] Revised patch, cares for trailing "." too
Made this change to gimp-2-2: 2005-02-08 Manish Singh <yosh@gimp.org> * app/text/gimpfont-utils.[ch]: new function to workaround pango bug #166450, by tacking on a ',' to font names that end in numbers, so pango_font_description_from_string doesn't interpret it as a size. * app/text/Makefile.am: add above files. * app/text/gimpfontlist.c * app/text/gimptext-compat.c: use new function. * app/text/gimptext-xlfd.c: also make sure font names pulled out from XLFD don't end in numbers. * app/text/gimpfont.c * app/text/gimptextlayout.c: remove some redundant checks. HEAD should be changed to use PangoFontDescriptions directly, instead of stringified versions, so I've not made this change there.
Looks like a more complex change to HEAD. I've applied the above to there now too.
Created attachment 37754 [details] [review] Possible replacement Your patch adds a comma in cases like: Wingdings3, 15 Wingdings 3, Bold 15 Which I don't particularly like. Can you test the attached? I haven't even tried compiling it, but it should only add a comma when needed. (Also noticed bug 168085 when I was writing this patch as related problem.)
Seems to do the trick, though your patch has typos.
Created attachment 37760 [details] [review] Revised patch that compiles
2005-03-02 Owen Taylor <otaylor@redhat.com> * pango/fonts.c (pango_font_description_from_string_: For family names that add in numbers add a , to distinguish them from family+size (#166540, debugging/testing by Manish Singh)