After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 458674 - Get HarfBuzz engine order via fontconfig
Get HarfBuzz engine order via fontconfig
Status: RESOLVED OBSOLETE
Product: pango
Classification: Platform
Component: general
1.14.x
Other Linux
: Normal enhancement
: ---
Assigned To: pango-maint
pango-maint
Depends on:
Blocks:
 
 
Reported: 2007-07-20 14:45 UTC by Owen Taylor
Modified: 2018-05-22 12:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The patch (20.85 KB, patch)
2007-07-20 14:47 UTC, Owen Taylor
none Details | Review

Description Owen Taylor 2007-07-20 14:45:43 UTC
The attached patch allows the explicit specification of shape engine
order via:

 A) For Fontconfig, a custom fontconfig key "pango-engine" (multiple
    values can be provided)

 B) As a fallback, or on non-fontconfig systems, via a pangorc key
    Pango/ShapeEngineOrder

Any engines not listed in either of those two mechanisms will be
used in random order.

This is done by moving the engine selection into PangoFont with a 
new (PANGO_ENABLE_ENGINE ... maybe better as PANGO_ENABLE_BACKEND,
or public) method pango_font_get_engine(), which in fact, is pretty
similar to the old unused pango_font_find_shaper(), but a little
different in detail.

Then there is a new virtual function font->get_engine_order() which
returns am array of engine-ids, and pango_get_default_engine_order() 
to get the list from the pangorc key.

Additional comments on the patch:

 - I think it should be pretty neutral in performance; caching of
   the last list of engines is moved from the shape context to the
   font (internal, so lockable in the future), in some cases this
   will be less efficient ... we do the computation once per font
   rather than once globally ... and in other cases, more efficient ...
   the computation is shared across multiple itemize calls for the
   same font, or multiple ranges of the same font in the same 
   itemize call.

 - I noticed when doing this patch that script/lang influence font
   and engine selection, but we don't take that into account in
   the caching of font/shaper we do on fontsets in pango-context.c
   (unless I missed something). I didn't try to fix that.
Comment 1 Owen Taylor 2007-07-20 14:47:20 UTC
Created attachment 92049 [details] [review]
The patch
Comment 2 Behdad Esfahbod 2007-07-20 16:05:53 UTC
Looks generally good.  Needs testing only.
Comment 3 Daniel Glassey 2007-07-20 21:17:11 UTC
Thanks :)

Is the idea that it will use fragments like this to check for the opentype tables before a shaper will be used? e.g. 

<match target="font">
        <test name="capability" compare="contains">
                <string>otlayout:arab</string>
        </test>
        <edit name="pango-engine" mode="prepend">
                <string>ArabicScriptEngineFc</string>
        </edit>
</match>


Comment 4 Owen Taylor 2007-07-22 01:23:51 UTC
Doing things like that is certainly possible. It wasn't my intention
though. My thought that you'd usually use ordering globally:

 This is a SIL field worker's laptop, always prefer the Graphite
 shaper if it works with a selected font

 (this could be done either in the pangorc or fontconfig, 
 fontconfig has the advantage of the fonts.conf.d directory
 where you can just drop a file and have it merged in.)

Or per-font:

 This is SIL Doulos, we know that the Graphite shaper does more
 with the font than the OpenType shaper can, so prefer it

Try to do the ordering based on the OpenType features of the font runs into
the problem that there isn't a logical ordering when the font
has multiple types of tables .. we have *capability* for both,
but which renders better?
Comment 5 Martin Hosken 2007-12-17 09:43:57 UTC
I have failed so far to get this patch to do anything that shows it is working.

I:
. built a patched version of 1.18.2 and installed as 1.19
. installed the package and rebooted.
. removed the graphite references from the module-files.d to make the patch do the work
. copied pango-graphite.so /usr/lib/pango/1.6.0/modules
. created a ~/.fonts.conf to turn on the capability globally with:
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>

<!-- test pangomodule match -->
<match target="font">
<!--    <test name="capability" compare="contains">
                <string>ttable:Silf</string>
        </test> -->
        <edit name="pango-engine" mode="prepend">
                <string>GraphiteScriptEngineShape</string>
        </edit>
        <edit name="pangobreaker" mode="prepend">
                <string>GraphiteScriptEngineLang</string>
        </edit>
</match>
</fontconfig>

. ran gedit and typed in Burmese to get Padauk to be used
. got Padauk but with OT rendering and no graphite.

Adding graphite back into the modules.alias structure reenabled graphite.

I checked that fontconfig was applying the capability via FC_DEBUG.

I can quite believe this is user error, but so far I can see nothing that implies the patch is doing anything.

BTW what would I add to my ~/.pangorc to try enabling graphite that way?

Yours,
Martin
Comment 6 Behdad Esfahbod 2014-05-08 18:50:25 UTC
This is pretty obsolete now.  But would be nice to allow setting HarfBuzz shaper order via fontconfig.
Comment 7 GNOME Infrastructure Team 2018-05-22 12:31:40 UTC
-- 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/86.