Re: Gnome text subsystems

[Lauris Kaplinski <lauris ariman ee>]

On 28 May 2000, Owen Taylor wrote:

> 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.

I'll reply with my case in sodipodi:

User is presented with dialog, where he can enter some text, and specify
different fonts/styles/languages.

Now - it is impossible to render it The Right Way, using current Gnome
font API. So something better is needed - but I do not write ad hoc
implementation, but better to do something more generally usable.

What happens with text:
1 it should be converted to glyph-position tuples
2 glyph outline is converted to bezier path, and fed, as SVG path, to
  general shape item. Implementation of text item should know exactly,
  which part of string corresponds to which glyph.
3 item now renders its components to screen, using shape standard routines
4 in node editing context, user can now adjust exact glyph positioning
5 currently printing is implemented, using bezier paths, which is
  unsatisfactory. Instead, this should be done, feeding independent glyphs
  (as the position of these can be changed), to gnome-print.
6 it is absolutely necessary to have <1 pixel accuracy between printed and
  displayed variants.

Can you explain, which parts of that process should be handled by Pango?

> 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.

What about general callback-based layout. I.e. layout compositing inquires
user program about buffer, a la:
buffer_ask_hline (gint position, gdouble height, gdouble length)
position - top/bottom
which returns exact vertical position and maximum length of horizontal
line with given height. The negotiation goes on, until sufficent position
is neglected, or error condition met (no single glyph fits in buffer)
After that, pango can continue neglecting position of next fragment.

It is not very clearly presented, but bou probably can grasp, what I
meant. It is trivial for rectangle, but still can be used for bird-shaped
frame.

> 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.

I just wonder, why you do not use Gtk object system for pango?

> 
> 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,
Lauris