GNOME Bugzilla – Bug 85341
Some characters are incorrectly displayed on Yelp.
Last modified: 2009-08-15 18:40:50 UTC
Some characters are getting incorrectly rendered in Yelp. I don't know if it is an issue in yelp-db2html, gtkhtml2 or pango. The XML source for these characters is: <quote> </quote> … — yelp-db2html converts the characters into: “ ” … — Apparantly, these are given to gtkhtml2, which then sends information on to Pango for final rendering. I will attach an image showing the characters as rendered in Yelp.
Created attachment 9237 [details] Image showing text associated with "“Cardinal”"
Created attachment 9238 [details] Image showing the text associated with the xml "seed…</b> — "
I should note, I don't know what specifies what font is shown in the Yelp window. The index display text seems to be controlled by the "Standard application font" in the Font Preferences dialog. However, the font selections in the Font Preferences dialog don't change the font in Yelp's content pane.
I guess this is more or less related to bug 63633 ... your font simply doesn't have those glyphs, but perhaps Pango could approximate them using standard ASCII. (What sort of font doens't have real quotes??? Maybe your font is just misencoded.) [ I assume you realize hat the "misrendering" is a box unicode codepoint in it ]
If someone could inform me how to determine which font is being displayed in the content pane of Yelp, I can take a look at the font and see what characters are there. Also, any other tips on checking the encoding would be appreciated. I'm not sure what you mean by "box unicode codepoint."
As I understand this problem, it only occurs if you are using a font without the extra glyphs found in Microsoft fonts (curly quotes, em dashes, etc). While it would be good to get pango to use substitutes when glyphs for ellipses, etc aren't available, it should be possible to work around this bug in Yelp, so I am assigning it there. By changing the entity declarations in yelp/stylesheets/docbook/dtd/ent/iso-pub.ent, so that things like … get replaced with "..." rather than "…". The curly quotes might not look as nice when using `` and '' with some fonts, but it is probably a worthwhile tradeoff (assuming that a fair number of users don't install Microsoft fonts on their systems).
An extra note: These glyphs are not Microsoft extensions or anything. They are listed on http://www.unicode.org/charts/PDF/U2000.pdf, but the Latin1 fonts that come with X don't include the glyphs, while most of the Microsoft ones do.
James, are you suggesting that this should be handled in the stylesheets? How will this show for users with fonts capable of displaying the glyphs?
I was actually suggesting a change in the DTD, so that those entites expanded to codepoints that the standard fonts that come with X support (in the PDF I linked to above, they have recommended substitutions). For people using fonts that support these glyphs, the change would have a slight negative impact -- no curly quotes, and em dashes wouldn't look as good. I doubt they would notice the difference for the ellipsis. As Owen pointed out, this should eventually get fixed upstream so that Pango does the appropriate glyph substitutions. My proposed fix is a temporary solution that works around the problem.
It should be noted that at the current versions of these fonts (now called "Luxi") _do_ have characters.
James, could you provide a patch with the changes needed? Louie, could this be marked 2.0.1?
Yes.
James, do you know what should be changed to fix this?
We have to make a trade off here. If we leave things like they are, people who use the Luxi fonts or the MS ones will have nice looking quotes, em dashes, ellipses, etc. People using just Latin1 fonts will see the "no glyph" box in place of those glyphs. This will go on until Pango can do the required glyph substitutions itself. The alternative is to modify the entity definitions in the DocBook DTDs so that we expand those entities to characters that are more likely to have the associated glyph in the chosen font. At first, I didn't realise that any of the fonts distributed with XFree86 included these glyphs, it seemed like a fairly good idea. However, since the Luxi fonts have the glyphs, maybe we should tell people to use them? If we do hack the DTD, we would want to undo the hacks when Pango can perform the glyph substitution. It may be easier to wait and see who else complains about this...
It's kind of a drag that RedHat doesn't ship XFree86 4.2.0 rpms for RH 7.2 / RH 6.2, yet. It makes upgrading for many people non-trivial. :-( I'd feel better about telling people to upgrade if they could do it without compiling XFree86.
Created attachment 10244 [details] [review] patch to change entity definitions for problem glyphs
Miles: does the above patch help with your problem?
Commiting to gnome-2-0 branch. Marking as fixed (Miles, can you verify or reopen). Will open a new bug for the HEAD branch which will depend on the pango bug. Thanks a lot!
Hmm.. reopening this one and marks it as depending on the other bug instead. Miles, please verify anyway. Louie, if verified by Miles we can remove the 2.0.1 keyword, right? Or should a new bug be created?
Sounds good. I'm assuming miles will verify :)
It appears to be fixed. I installed the 4.1.0 fonts and the glyphs looked fine. It is rather hard for me to know for sure, since I am now running XFree86 cvs HEAD with these fonts, rather than the XFree86 4.1 server. Also, I have pango and all that set up to work with XFree86 HEAD, so I am not really comparing apples with apples. Does someone want to mark this Fixed?
marking as fixed.