Re: [Silgraphite-devel] Re: Pango and SILGraphite was Re: Possible Pango 1.4 ideas

[Owen Taylor <otaylor redhat com>]

ytang0648 aol com writes:

> In a message dated 1/30/2003 10:22:46 AM Eastern Standard Time, otaylor redhat com writes:
> 
> > 
> > > One question. How does pango decide which shaper to use ? What is
> > > the algorithm (based on PangoCoverage ?) to dertermine which shaper
> > > to be used?
> > 
> > The current algorithm is that modules are registered by:
> > 
> >  Backend (Xft fonts, old style X fonts, win32 fonts, etc.)
> >  Covered ranges
> > 
> > And for a given backend, Pango always picks the same shaper for the 
> > same range.
> > 
> > This system would clearly need to be extended a bit if we 
> > had
> > different shapers for different subtypes of fonts (OpenType,
> > Graphite) fonts within the same Xft backend.
> > 
> > Regards,
> >                                         Owen
 
> hum... so the OT xft font currently is not a subclass of xft font
> backend ?  Are you saying that in 1.1.6 you will use the same shaper
> to deal with a Thai OpenType font and a Thai TrueType font ? ( I
> know the OpenType Thai is not supported, but in case you do, is that
> will be the case?)

Yep. For OpenType vs. "legacy hardcoded shaping", I don't think
this is a big problem. If we have code for both, they're is no
problem putting them into the same module. But clearly Graphite
would need some changes in this area.
 
> I guess backend take higher priority than the coverage, right ?

Backend *has* to match, so yes, it's higher priority. (Note
that it doesn't make sense for Graphite to be a different
*backend*; backends imply an incompatible font rendering technology,
and a new backend would require specific support in everything
that used Pango.)

> Since Graphite will be able to handle all unicode range without
> particular algorithm for a particular coverage, the better way to
> trigger (switch to) it's shapper is to check the availability of one
> uniq table ('Sil '). and if that table is available, use the
> Graphite Shaper for all the Unicode conde point that you can find in
> the 'cmap'.

The first thing you would clearly need to do is to add some
idea of what tables a font has to the information that fontconfig
queries from a font ... 'gsub','gpos','gdef', and 'Sil ' being
the ones that are immediately interesting.

Then you need to figure out how to work that information into
the query that Pango does against fontconfig. This is the
hard bit.

The code to do this query is currently in 
pangofc-fontmap.cI:pango_fc_font_map_get_patterns(), which
is called from pango_fc_font_map_load_fontset(), which is
called from pango-context.c:add_engines().

Then we go from the set of patterns to the single best
pattern with a call to pango_fontset_get_font().

One conceivable scheme:

 - Instead of determining a single shaper for the codepoint/script
   (See http://bugzilla.gnome.org/show_bug.cgi?id=91542 for 
   changing from codepoints to scripts in shaper selection), we
   determine a set of possible shapers.

 - We add a list of shapers as an optional argument to 
   PangoFontMap::load_fontmap. (The virtual function is
   ENABLE_BACKEND, so can be changed, there would have
   to be an extended version of the public function.)

 - We add an extra Xft-specific interface that Xft shaper
   engines implement to get a required table. (*)

 - We add those tables to the fontconfig query, so that
   fonts with a 'Sil ' or 'gsub' table sort before fonts
   without that table.

 - We add a "do you support this font" interface to 
   PangoEngineShape that we can use to pick the right
   shaper once we have the font. (Perhaps the current
   get_coverage() could be used, but if there is a better
   way of doing it, we could change that.)

Note also that this is also one of the really speed critical 
bits of Pango...

> I am not that clear about the PangoCoverage in the shaper code. Does
> that refer to the coverage of the hard wire logic? or does that
> refer to the coverage of a particular TrueType font? I guess in the
> case of the shaper api, it refer to the hard wire logic, right?
 
The get_coverage() shaper method is basically dead code.

The original idea was that a shaper module could get involved in
deciding the coverage of a particular font, so, say, if you had an
Arabic font without the proper tables.

But as the code ended up, the selection of font is done completely
with information that fontconfig queries from the fonts in
advance, so there is no real place for the shaper to get involved.

> Do you use the same PangoCoverage data type in other places refer to
> the Unicode code point coverage of a particular font ?

No. The coverage of a font is currently computed by the backend, not
by the shaper.

> Thanks for your help. 1.1.6 is the version I should look into, right?

Well, actually, the current version of Pango is 1.2.0 (1.2.1 very
shortly), but nothing has changed structurally since 1.1.6.

Regards,
                                        Owen

(*) Multiple ways of doing this. It might be the right time
    to switch PangoEngine over to a GObject, or we could
    do something ad-hoc.