[Gnome-print] Re: Gnome text subsystems

[Owen Taylor <otaylor redhat com>]

Lauris Kaplinski <lauris@ariman.ee> writes:

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

Well, basically, Pango is only concerned with 1. (And font and style
selection.)

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

I don't think this is sufficient for doing full-paragraph optimization,
and would be too slow when Pango needs to be really fast. 

(That is when editing a big text buffer, line wrapping and height
calculation is the slow part. GtkText* now does incremental rewrap,
which gives decent performance with the current Pango. But slowing it
down further really isn't an option.)

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

Well, since Pango is a GTK+ dependency, not vice-versa, I couldn't
depend on GTK+-object. But now that we have GObject, Pango _does_
use GObject.

(Only for PangoFont and PangoFontMap right now. But I'll be converting
more of Pango's objects over right now.)

Regards,
                                        Owen