From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Wed Apr 24 2002 - 18:24:36 EDT
from Eric Sink.
---------- Forwarded message ----------
Date: Wed, 24 Apr 2002 12:41:55 -0500
From: Eric W. Sink <eric@sourcegear.com>
To: msevior@mccubbin.ph.unimelb.edu.au
Cc: Paul Rohr <paul@evohr.org>
Subject: Comments on AbiWord layout engine
Hi Martin (and Paul),
I'm not currently a subscriber to the Abiword-dev mailing
list. My subscription got all screwed up in the move
from Parsons, so I usually just read the archive with
a browser now. Anyway, I can't post to the list, but
feel free to post these comments if you find them
useful.
I've read several of the design messages you've
posted to the mailing list. I'm not doing a thorough
review of your proposals, as you are obviously farther
down the clue path than I am at this point. I just
thought I would read your stuff and look for any
obvious problems, or anything which sticks out as
something which should definitely be affirmed.
First of all, about the legendary 2-pass table layout
algorithm: It was actually done by Jeff Hostetler,
and he was at Spyglass when he did it, not at SourceGear.
Unfortunately the technique is proprietary and now owned
by OpenTV. It is even more unfortunate that this
particular evidence of Jeff's genius is now locked
away in a place where nobody will be able to appreciate
it and he will never get the credit he deserves for it.
Bottom line: You can't have it, and neither can we. :-(
The obvious thing to affirm is that containers need to be
more generic than they are in the current design. The
question is always: "How generic?"
Some layout systems only have two kinds of containers:
vertical and horizontal. The vertical ones stack lines
until full. The horizontal ones stack chars until full.
This always seemed like a gross oversimplification to
me.
When trying to design this stuff I usually got hung up
trying to figure out whether containers have their size
imposed upon them, or if they determine their own size
and communicate it to the outside world. The answer is
both, definitely. I have come to suspect that containers
could be made VERY generic if there were a well-designed
algorithm which would allow a container to negotiate
with hits environment for space. In the end, the
environment always gets final say.
Page: Column, how big do you want to be?
Column: I want to be 4 inches wide.
Page: Bzzzzt! Wrong answer. Thank you for playing.
Now that I know you want to be 4 inches wide, I have
decided you can be 3.5 inches wide.
Column: Geez, if I can only be 3.5 inches wide, I
really only need to be 3 inches wide. Can I be that?
Page: Nope. It's 3.5 or nothing. Have a nice day.
Layout of a page ends up being a large number of
conversations which resemble this one. I have obviously
left out lots of detail. Most containers need to ask
questions of their sub-containers before they can answer
their parent's question.
I do think that a table is a container, but it obviously
has a VERY special and customized algorithm for laying out
the cells within it.
Cells end up being rather simple containers. Try to keep
them ignorant of the algorithm the table uses to lay them
out. You'll want to replace that algorithm 4 times during
the next year, so life will be much easier if you find a
way to keep it very localized. Define a protocol for the
conversation between tables and cells and don't let the
cells do any mind-reading.
Your email postings suggest to me that you need to think
more about exactly what kind of table model you want. Word's
tables are fundamentally different from the tables of HTML 3.2,
and I believe later versions of HTML introduced table concepts
which are even trickier. Think now about whether you want
the row-oriented approach of HTML with rowspan and colspan.
Study's Word's table support and find tables which can be
easily represented in one model but not the other.
Text flow around boxes or images is a drag, since these concepts
essentially introduce the need for overlapping containers,
with layers and Z order and the need for one layer to know
what happened in the upper layers.
Some containers allow text to flow to the "next" container.
Pages and columns work this way. Cells usually do not.
A very early version of the AbiWord layout engine was capable
of flowing text into a circle. It was cool, but it didn't
survive beyond the next rewrite. :-) Still, if I was trying
to design a second-generation layout engine for AbiWord, I
would at least try to consider non-rectangular containers as
I designed the space-negotiation protocol between containers
and subcontainers.
This note is longer than I planned (as most of my notes are)
and I don't know if it's helpful or not. Feel free to take
it with grain of salt.
Good luck!
-- Eric W. Sink Software Craftsman eric@sourcegear.com
This archive was generated by hypermail 2.1.4 : Wed Apr 24 2002 - 18:26:01 EDT