Re: pango.modules and Pango shapers

[Owen Taylor <otaylor redhat com>]

Chookij Vanatham <Chookij Vanatham sun com> writes:

> Hi Owen, others...
> 
> Just a quick question about Pango shapers and pango.modules file.
> 
> Each platform will have its own pangox.aliases.
> 
> Would that be the same that each plaform will have its own pango.modules
> and all various of pango shapers  ?

No, I wouldn't really expect this; if a different platform
had fonts encoded in a very different fashion, it might make
sense, but if the question is just the names or details of
the encoding, as it seems is suggested for:

 http://bugzilla.gnome.org/show_bug.cgi?id=79812
 http://bugzilla.gnome.org/show_bug.cgi?id=79813

It seems like overkill.

One reason that I want to avoid platform dependent shapers
for simple cases is that one of the features on the table
for pango-1.2 is moving the basic shapers into the core of
each backend so we can have a "simple font" API suitable for
applications that are trying to map the GTK+ font API onto
some old non-complex-text friendly system.

(We'd prefer if everybody used Pango properly, but in some
situations it just isn't practical.)

If all shapers are doing mapping characters to glyphs 1-1,
using a separate shaper for handling encodings the basic
shapers can't handle means that the simple API won't work
for these fonts for no particular good reason.

So, for a question of handling different encodings, or of
different encoding names on the server, I'd rather move in
the direction of making the basic-x backend (or the version
integrated into the X backend) more configurable than
suggesting that vendors use separate shapres.

In the medium term, I really want to be trying hard to move
to client-side OpenType fonts for complex-text languages,
because I think many of the problems we are having are
basically insoluble without having a more complete and
intelligent font format.

In the end, trying to run Pango on top of core X fonts is a
bit like putting kerosene in a Ferrari; it might sputter
along for a bit, but the advantages of the system are
largely lost.

Regards,
                                        Owen