Re: Gnome text subsystems

[Owen Taylor <otaylor redhat com>]

Lauris Kaplinski <lauris@ariman.ee> writes:

> Hello,
> 
> What about following logical structure?
> 
> 1. User has
> - text (in some supported encoding)
> - language
> 
> 2. Given language and preferences, he/she or system selects available
> GnomeFont
> 
> 3. It gives text + font + language to Pango, and gets back PangoGlyhString
> (or list of strings)
> 
> 4. These strings are fed to:
> - gnome->X font finder, then X font rendering
> - canvas engine
> - raster rendering engine
> - outline extracting
> - gnome-print
> ...

Let me explain the big picture of Pango:

The core Pango library provides:
 
 - API's for font handling and for layout
 - Implementations of the language-generic parts of the layout
   algorithms.
 - Infrastructure for loading modules.

The rendering system provides:

 - An implementation of the font-handling API
 - Functions to render PangoGlyphString and PangoLayout
 - A private API for shape modules to access when converting
   from characters to glyphs.

The modules provide:

 - Language-specific text handling (computation of line
   break points, etc.) (language modules)
 - Language-and-rendering-system specific code for conversion
   of characters into glyphs. (shape modules)

So, the way that GnomeFont/Text/Print fits into this is that
it needs to provide the rendering system stuff, and people
need to write shaper modules for various languages on top
of whatever font technology GnomeFont is using.

Now, probably, the exact API's in Pango need some modification
for high-quality-typographic rendering - so far the X renderer
has been the only one getting work. But I think the general
division of labor is good.

> Problems:
> - if text is in multiple languages, then single GnomeFont is not
> sufficent. So there should be something bigger, like GnomeFontSet

The way Pango deals with this is that:

 - To make X fonts look moderately decent, the X font layer for
   Pango includes the concept of aliases, where a big bunch
   of X fonts are grouped together and called "Sans".

 - Otherwise, when itemizing text, you can specify a family list
   like "Times,Serif Bold 14". This sort of mechanism isn't
   important for documents - people will specify the fonts they
   want. But it is important for things like dialogs (or web
   pages) where people want to specify a particular font and also 
   allow for fallbacks.

   This is roughly based on the CSS font mechanisms, but I've
   omitted almost all of the complexity of the CSS2 web-fonts
   stuff, because I don't think it actually would be useful
   enough to have the font matching and syntheses stuff in
   Pango to be worth the complexity. (And most of it isn't even
   doable with the technology and fonts available now for
   Linux.)
   
> - How to deal with attributed text?
> - How complicated text is Pango able to layout - i.e. if should it handle
> super/subscripts, possible hyphenations, multiple languages, multiple font
> sizes and attributes in single text segment?

Yes.

Well, currently, it is "sort of, no, yes, yes, yes".

But PangoLayout is meant to be a pretty comprehensive layout engine
for attributed, multi-lingual text.

How far that goes - I don't know. That is, does someone use
PangoLayout to render bird-shaped paragraphs with drop caps, and
global paragraph optimization? I'm not sure. I don't want to try to
make the basic PangoLayout complex enough for anything anybody would
ever want to do.

So, I see two approaches to making it possible to go beyond
PangoLayout.

 - Require people to write PangoLayout replacements. There is nothing
   mandatory about using PangoLayout - but replacing it right
   now is a bit painful, because it contains a lot of complex
   algorithms for hit-testing, cursor motion, etc that would
   need to be reimplemented.

   But it would probably be possible to move some of these
   algorithms out of PangoLayout into convenience functons.

 - Make it possible to subclass PangoLayout and replace the 
   portion that does line-layout. The line Layout code is
   maybe 500 lines of code out of 2500.

Right now, I would lean toward the latter. It would require saving
a bit more per-line information - currently the x and y offsets
per line are recomputed when needed instead of being stored
in the PangoLayoutLine structure. 

The advantage of the latter approach is that the user only
needs to learn PangoLayout once, and it also means that there
is a better separation between the "user level API" and the
"implementor API".

Regards,
                                        Owen