GNOME Bugzilla – Bug 514021
Font Previews Not Displaying Correctly
Last modified: 2008-10-30 20:09:06 UTC
Please describe the problem: When I view the font dialog box in 2.4.3, at least half of the font previews are not displaying correctly (a default preview is displayed). The fonts do, however, type correctly. The same font previews are shown correctly in 2.2.17, so I know that this is not an error with the fonts. I searched both forums and Bugzilla to find any other similar reported problems, but I was unable to locate any. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
What operating system are you using? Do you detect any differences between the fonts whose previews work and those that don't?
I'm using XP. Standard fonts that come with MS Office (i.e. Arial, Times New Roman, etc) seem to work fine. Nearly all of the fonts that display incorrectly are those I've downloaded online. The odd thing is, it's not consistent over font sites or authors. Some fonts created by one person will display fine, while others by the same author display incorrectly.
Could you attach one of the fonts that preview incorrectly to this bug, please. Without that there isn't much we can do. (Choose one whose license allows you to do that.) Or at least provide a screenshot.
Created attachment 104354 [details] One of the fonts that won't preview correctly in 2.4.3 Here's an example of one of the fonts that won't preview correctly in 2.4.3. This font does preview correctly in 2.2.17, as will be shown in the screen shot.
Created attachment 104355 [details] Screen Shot of font displaying correctly in 2.2.17 Screen shot of font preview displaying correctly in 2.2.17. Indicated font is in a separate attachment.
Created attachment 104356 [details] Font Preview Not Displaying Correctly Screen shot of font preview not displaying correctly in 2.4.3. A separate screen shot shows font preview displaying correctly in 2.2.17. Font indicated is attached separately.
The peaggs.ttf font claims to support the Coptic, Greek, Cyrillic and Latin scripts, although as far as I can see using ftview, there are just Latin glyphs in the font. Please complain to the font designer that the so-called OS/2 table in the font file claims bogus Unicode range coverage. Feel free to point him/her to this bug report. (Anybody know of a better TrueType font dumper than fontconfig's ftdump and ftview?) The heuristics in gimp's app/text/gimpfont.c that chooses what sample string to use for a font has this: if (n_sr_alts > 0) { /* Use the highest priority subrange. This means that a * font that supports Greek, Cyrillic and Latin (quite * common), will get the Greek sample string. That is * capital and lowercase alpha, which looks like capital A * and lowercase alpha, so it's actually quite nice, and * doesn't give a too strong impression that the font would * be for Greek only. */ DEBUGPRINT (("=> at least one SR, use %.4s\n", scripts[sr_alts[0]].script)); return scripts[sr_alts[0]].sample; } /* Final fallback */ DEBUGPRINT (("=> fallback, use Aa\n")); return "Aa"; I.e. if the font claims to support several scripts, we choose the sample string for the highest priority one. This priority concept is defined in this same file, the scripts are ordered in a rough order from more "exotic" ones to more common ones. Latin is the last (lowest priority) script in the table. I.e., the point is that if a font claims to support any other script than Latin, we believe that it has probably been designed especially for that script. If it is common that fonts falsely claim to support Greek (or other non-Latin scripts) even if they don't contain any such glyphs, only Latin, I guess this code will have to be enhanced. Probably we need to actually verify that the font covers the script in question, and if not, then use the fallback sample Latin-only string "Aa".
I've written to the designer of the specific font I sent, and here's part of the response she gave me: "Here's the thing... I get what they're saying about support, etc. BUT... Font-makers don't use script like that sample string they sent you to make fonts. We don't use anything remotely *close* to that. LOL. Making fonts is more like using photoshop... You take a picture of a letter and paste it in! :) So I can't go edit script or anything like that... And I checked *all* the settings in my font program I use and there's no setting for me to change so that "the so-called OS/2 table in the font file" will not "claim bogus Unicode range coverage". lol. In other words, it doesn't have any optional settings for me to change about which languages it supports." I have hundreds of fonts that aren't working, and my guess is that they're hobbyists who are using font programs like she is (she uses Font Creator Pro 5.0) and not directly coding. After asking around different forums, I've heard responses from several people saying that this is a problem that frustrates others. Refering to Tor's last paragraph in the above comment, is there any chance that code can be enhanced for a future release?
"Font-makers don't use script like that sample string they sent you to make fonts." Hmm, does this refer to the very short sample strings shown in the GIMP font selector? Of course I know that typeface designers don't use those. The sample strings in GIMP have to be as short as possible to fit into the GUI nicely. It is not possible, I think, to have sample strings that would show all the features of a typeface in the GUI. And setting text isn't the main purpose of GIMP anyway, of course. Typeface designers use longer words to see all relevant features of the typeface, and how the letterforms fit together (one traditional such "word" for Latin typefaces is "Hamburgefonts", see http://en.wikipedia.org/wiki/Hamburgefonts ). Or whole paragraphs, often containing the "lorem ipsum" nonsense text (see http://en.wikipedia.org/wiki/Lorem_ipsum ) to get a feel of how the typeface looks when used to typeset larger amounts of text. "Making fonts is more like using photoshop... You take a picture of a letter and paste it in" Yeah, I am sure that's all there is to it. And writing a novel is just typing on a keyboard. I guess I will have to come up with more heuristics in the selection of the sample string to avoid the problem in this bug.
I am not sure but it might help to use pango_font_get_coverage() on the font in question, and then use pango_coverage_get() to find out if the preview characters are covered well enough by the given font. If the coverage is 'none' or 'fallback', then the search should be continued with a more common script.
Created attachment 105159 [details] [review] patch to implement check for font coverage I am not absolutely sure if this code is passing the correct index to pango_coverage_get(). We should probably ask Behdad if we are doing this correctly.
The patch fixes the problem for the font attached, yes. It also has the side-effect that for most fonts "Aa" is used, even for those (like Arial) where the original code displayed Αα (capital and lowercase alpha, looking like capital A and lowercase alpha). That isn't necessarily bad, though, maybe the alpha was misleading. Then of course, from the perspective of somebody looking for a font to use for Greek, the original behaviour was slightly better. But I guess there is no way to come up with short sample strings like this that would tell everybody all they need to know... For more "exotic" fonts, though, it does still display the sample string for the "exotic" script in question, good. Maybe the sample strings should also depend on the script of the UI language? Oh well, let's not overdo it.
Doesn't the font Arial provide coverage for the glyphs in "Αα"? Should the code perhaps allow PANGO_COVERAGE_FALLBACK ?
Created attachment 105206 [details] [review] simpler patch that just checks whether font has glyphs for the sample string This is a simpler patch that should also have less performance impact since it doesn't make use of PangoCoverage at all.
Yes, Arial has also Greek (and Cyrillic, Hebrew, and Arabic even). (Most of the standard fonts that come bundled with XP do.) The simpler patch fixes the immediate problem reported here for the Pea Girly Girls Script (what a name...) font. For other fonts, I don't see any really drastic changes. And anyway, the short sample strings in the current font chooser can never be perfect. Whatever we display as such sample strings, it won't tell the whole story about a font. What we would need is a more elaborate font chooser.
I have applied the simpler patch to both branches. Closing as FIXED. 2008-02-14 Sven Neumann <sven@gimp.org> * app/text/gimpfont.c (gimp_font_get_sample_string): check if the font has the glyphs from the sample string. Fixes bug #514021.