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

[Owen Taylor <otaylor redhat com>]

ytang0648 aol com writes:

> Thanks for your reply. It help
> 
> So... I put down the following model
> 
> Paragraph
> segment of Paragraph (directional runs)
> String (several words)
> Character
> Glyph

The model of Pango looks something like:

 Paragraph  =>  Item          =>      Run
                Character  <cluster>  Glyph

In the first step of analysis paragraph is broken down into "items" by:

 - Directional run
 - Selected font and shape engine (determined by applied attributes)

Then each item is converted into glyphs. Line breaking may
turn a single item in to several "runs". Characters are related 
to glyphs in a N:M fashion by the idea of a cluster.

 N characters => 1 cluster => M glyphs

[ If this sounds familiar, this model fairly closes matches the windows 
  Uniscribe API, though the details are considerably different ]

> The high level pango api really deal with the first two levels right? 

The high-level API is mostly dealing with Paragraphs and characters;
it mostly hides items/runs/glyphs.

> FreeType2 deal with Glyph (and optionally Character) level .

Yes.

> Xft deal with both String level, Character level and Glyph level. 

Yes. Pango only really deals with Xft at the Glyph level.

> How about GDK/GTK? does it api deal with Paragraph level only?

Pretty much. There is no X/Xft-style DrawString/DrawChar/DrawGlyph.
(The idea has been floated to add this sort of simplistic API; the
reason for adding it would mostly for cross-platform API's sitting
on top of GTK+ that expect such a thing.)
 
> I think Graphite is really deal with Paragraph level. Althoguht I
> use it as the String level with Project SILA (see
> http://sila.mozdev.org). That is really an incorrect use of
> Graphite. Too lazy to change the Mozilla arch now.....  (and I am
> officially not working for Gecko now.... after spend 4+ years on
> hacking GFX....)

The place where I would hope you could insert Graphite is at the
level of converting:

 Font + Character string  =>  Glyph string

This is the:

  void (*script_shape) (PangoFont        *font,
			const char       *text,
			int               length,
			PangoAnalysis    *analysis,
			PangoGlyphString *glyphs);

method of PangoEngineShape. To cut in any higher:

 - Would mean major changes to Pango structure
 - Would cause problems when swapping with backends without 
   paragraph level knowledge.
 - Would affect the ability to use Graphite fonts mixed with 
   OpenType fonts.
 - Would mean that Graphite support wouldn't pick up the
   advanced-typographic features that Damon Chaplin is
   looking at adding.

I don't really see why Graphite support should need to come in
any higher, except in whatever is needed to select the Graphite
shaper and fonts when appropriate.

> I think ATSUI is also Paragraph level 

My memory of ATSUI is that it is fairly similer to the high-level
API of Pango, though the clearest API analogies are:

 PangoLayout     <=> Java2D text interfaces
 Low level Pango <=> Uniscribe
 
> Are those low level pango api really "internal private functions"?
> or they are still public function for upper level to call?
 
The ones I was referring to in my earlier mail are public and
supported API; the Pango interfaces comprise about 5 pieces:

 1) Public high-level API (PangoLayout)
 2) Public low-level API  (What is used to implement PangoLayout)
 3) Shape-engine only API (What, e.g., the arabic-xft shaper uses)
 4) Backend-only API      (What is used to implement libpangoxft)
 5) Internal Pango API

Headers are installed for 1-4), but 3) and 4) have lower levels
of compatibility degrees, and you need special #defines to 
use them.

(PANGO_ENABLE_ENGINE, PANGO_ENABLE_BACKEND)

Regards,
                                        Owen