Re: Gnome text subsystems

[Lauris Kaplinski <lauris ariman ee>]

On 29 May 2000, Owen Taylor wrote:

> Lauris Kaplinski <lauris@ariman.ee> writes:
> 
> > 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?
> 
> Well, basically, Pango is only concerned with 1. (And font and style
> selection.)

OK.
Then I bet, the best continuing point in my shaping of gnome-font API, is:
1. Clean it up, keeping only
1.1. browsing and fetching of fonts (which will one day depend on server
  backend).
1.2. way to extract glyph metrics, both unisized and aligned
1.3. way to render single glyphs and positioned glyph lists (latter for
  efficency)
1.4. way to extract outlines
1.5. way to extract all other important data, such as ligatures, kerning,
  special glyph shapes, rebuses & so on. The semantic use of these will
  belong to Pango, but user needs these anyway.
2. Ensure, that there can be always one-to-one easy mapping from
  gnome-font to pango font. Not vice-versa, as pango is probably also
  interested in bitmap-only fonts

1.5 needs some good general API from pango-side also. For example a way to
signal pango, which of facultative glyph forms user is willing to use.
This is somewhat independent of font itself, as it can well apply to
different sizes and weights etc.

> So, I think having separate layout algorithms for "simple greedy case"
> and "complicated shaped paragraphs" is probably necessary. How the
> "complicated shaped paragraphs" part goes about determining the shape
> is a separate question.

Having possibility to subclass PangoLayout, using G(tk)Objects, would
certainly be all, that is needed :)

Best wishes,
Lauris