GNOME Bugzilla – Bug 152997
basic_engine_covers() always return PANGO_COVERAGE_EXACT
Last modified: 2004-12-22 21:47:04 UTC
In 1.6, basic_engine_covers() always return PANGO_COVERAGE_EXACT. As a result, some characters (e.g. Chinese) are rendered with font that doesn't cover them.
Indeed. Why are there two return statements after eachother? Probably just a mistake by Hans when he added the basic_engine_covers() function. But just removing the first unconditional "return PANGO_COVERAGE_EXACT", and relying on find_char() is not OK either. The function needs to take the language into account, too, because a font for Japanese shouldn't be used for Chinese, and ditto for the other CJK combinations. But the default implementation of the covers method in pango-engine.c does that (it uses the language-dependent font coverage as calculated by pangowin32, I assume), so I don't see why basic-win32.c needs to override the covers method at all? Hans?
In general, avoiding creating the PangoCoverage objects may be a performance win - pango_font_get_coverage() is essentially only ever called from the default implementation of covers(), so if you override it you can avoid creating the intermediate object. (The fontconfig-based backends do it) But the results of calling the engine's covers() method on a font should certainly be similar to the results of the default implementation.
Hi Tor, looking again at the current implementation of _covers it seems as if I've first tried find_char() similar to what basic-x.c does, noticed some problem (I dont't remember anymore) which disappeared after adding return PANGO_COVERAGE_EXACT - and forgot about it. Sorry for any incovenience caused, I'm definitely not a Pango expert ;)
Fixed in CVS, removed the implementation of the covers method in basic-win32.c.
*** Bug 156225 has been marked as a duplicate of this bug. ***
Now fixed in the pango-1-6 branch, too.