Re: Gnome text subsystems

[Nathan Hurst <njh hawthorn csse monash edu au>]

On Mon, 29 May 2000, Lauris Kaplinski wrote:

> 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 a bit trickier unfortunetly, and the cost of going backwards and
forwards would be prohibative I think.

Owen talked about greedy vers best.  I think he really was concerned with
local vers global effects.  My current version only affects text that
follows, or shares a line with, the edited text.  This is as good as one
could hope for in the worst case.  When I handle paragraphs(I am planning
to look at what pango offers in terms of spacing.  I implemented the TeX
spacing design, which is quite neat, but may not fit with international
support nicely) this could be extended to 'only affects the current
paragraph mostly' in many cases.  I am very interested in improving
incremental speed(for different reasons to Owen, but to the same ends) and
there are some obvious opportunities, and some less obvious ones(which I
haven't thought of yet :-).

> 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 have time to make a bird shaped paragraph so you are getting a
spiral and a pentagon instead.  I've tarred up a working demo(It was
working, last time I checked, anyway).
http://www.csse.monash.edu.au/~njh/phd/text2.tar.bz2

Oops. Damn!  It's an older version.  Have a play anyway, then we can
discus further.

njh