GNOME Bugzilla – Bug 334392
improvement of font selection with PangoCoverage
Last modified: 2018-05-22 12:16:10 UTC
Copying from gtk-i18n-list: Date: Mon, 13 Mar 2006 02:38:41 -0500 From: Kenichi Handa <handa@m17n.org> To: gtk-i18n-list@gnome.org Subject: improvement of font selection Hi, I'd like to suggest the attached patch to pango/pango-context.c. Pango's shaper engine (struct _PangoEngineShapeClass) can have a callback function "covers", but it seems that it is not utilized that much. In the function get_shaper_and_font_foreach(), the return value of (PangoCoverageLevel) _pango_engine_shape_covers() is simply checked against PANGO_COVERAGE_NONE, and if any other value is returned, that font is accepted. I think it is better to try another font if PANGO_COVERAGE_FALLBACK or PANGO_COVERAGE_APPROXIMATE is returned here until PANGO_COVERAGE_EXACT is returned. That way, pango can use a font most preferred by a shaper engine while falling back to APPROXIMATE or FALLBACK font. What do you think? If the patch is accepted, the next step will be to modify each shape engine to supply proper "covers" function if the default "covers" function is not enough. For instance, indic shaper should accept only proper OTFs. --- Kenichi Handa handa@m17n.org *** pango-context.c 04 Apr 2005 14:07:57 +0900 1.74 --- pango-context.c 22 Jul 2005 16:59:41 +0900 *************** *** 867,872 **** --- 867,873 ---- GSList *engines; PangoEngineShape *shape_engine; PangoFont *font; + PangoCoverageLevel level; } GetShaperFontInfo; static gboolean *************** *** 884,894 **** level = _pango_engine_shape_covers (engine, font, info->lang, info->wc); ! if (level != PANGO_COVERAGE_NONE) { info->shape_engine = engine; info->font = g_object_ref (font); ! return TRUE; } } --- 885,899 ---- level = _pango_engine_shape_covers (engine, font, info->lang, info->wc); ! if (level > info->level) { info->shape_engine = engine; + if (info->font) + g_object_unref (info->font); info->font = g_object_ref (font); ! info->level = level; ! if (level == PANGO_COVERAGE_EXACT) ! return TRUE; } } *************** *** 926,931 **** --- 931,937 ---- info.wc = wc; info.shape_engine = NULL; info.font = NULL; + info.level = PANGO_COVERAGE_NONE; info.engines = state->exact_engines; if (state->enable_fallback)
I'm curious to know what issues this will solve at this point. I think it can fix bug 327854.
One more thing this helps solving is selection between say Graphite and OpenType Layout shapers.
What case may _pango_engine_shape_covers( ) return PANGO_COVERAGE_FALLBACK or PANGO_COVERAGE_APPROXIMATE?
(In reply to comment #3) > What case may _pango_engine_shape_covers( ) return PANGO_COVERAGE_FALLBACK or > PANGO_COVERAGE_APPROXIMATE? For instance, an Arabic shape engine will return PANGO_COVERAGE_EXACT on a font that supports mandatory GSUB featires plus GPOS feature "mark" for vowels, but may return PANGO_COVERAGE_APPROXIMATE on a font that doesn't support such a GPOS feature (e.g. FreeSerif.ttf), and return PANGO_COVERAGE_FALLBACK on a non-OTF font. By the way, I've thought that my proposal was rejected because there was no response for a long time.
(In reply to comment #4) > By the way, I've thought that my proposal was rejected because there was no > response for a long time. I'm generally interested in your proposal, but it's just part of a bigger change we need to make, and your patch as it stands now doesn't really fix the problem, as Owen already pointed out. The reason is that FcFontSort prunes fonts, assuming that the fonts it returns can be used. So, your approach doesn't really work. For example if you have two Arabic fonts, one the 10x20 bitmap and another the OpenType Nazli, if you FcFontSort already reports Nazli before 10x20, then you don't need any patch and Pango works. On the other hand, if 10x20 is listed first, then FcFontSort prunes Nazli as it doesn't cover any chars that 10x20 doesn't, so you don't get Nazli in the list at all. The result, you still have to render using the FALLBACK 10x20 font.
(In reply to comment #5) > I'm generally interested in your proposal, but it's just part of a bigger > change we need to make, and your patch as it stands now doesn't really fix the > problem, as Owen already pointed out. I'm not argueing that the change fix all font-selection problems. But, there surely are cases that the change improves Pango (for Indic and SEA fonts as I wrote in the mailing list). > The reason is that FcFontSort prunes > fonts, assuming that the fonts it returns can be used. So, your approach > doesn't really work. Yes, I understand that problem. So I suggested to use FcFontList (to trim off unusable fonts) and FcFontSetSort (without pruning) in the mailing list. That kind of change will make my approach work better.
Thanks for reminding of that. That's something I'll definitely take into account when trying to comeup with a new scheme for font selection (in the hope of avoiding FcFontSort as much as possible.)
behdad, which work will we need more to fix this bug?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/40.