From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Wed Apr 24 2002 - 19:36:21 EDT
>
> Hi Martin (and Paul),
>
Hi Eric,
It's great to hear from you.
>
<snip>
>
> 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. :-(
I've always wondered about issues like this. It's an idea from his
head. Unless the algorithimn has been patented why can't he independently
reproduce it?
Actually I'm not particularly worried about table layout at this
point. The gtk table layout algorithm although 4 passs is simple, straight
forward and works well. My default idea was to simply steal that.
>
> 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.
>
The current plan is to have these two plus a table layout.
> 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.
Ahh This is *exactly* how gtk layouts out widgets. It works well and we
can steal the code if needed.
>
> 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.
>
The difference between laying out widgets or web pages and a page is that
a page has to pass content onto the next page. I hoped that we could
actually avoid this by generalizing the breakSection method you developed.
So I was thinking of only imposing horizontal contraints on containers and
relying on a generalized break section algorithim to make it fit
vertically.
> 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.
>
I fully agree.
> 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.
I've started this by reading the RTF specification. It appears they do
merged cells by actually placing the cell then merging the content from
another cell into it. This is different from how I thought of doing
things.
>
> 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.
>
I confess I haven't worked though this yet. At present my idea for text
around images/frames was to place the image in a table and fill the other
cells in the table with text.
It becomes tricky then to decide if a positioned image should be
positioned relative to a page or an embedded column.
> Some containers allow text to flow to the "next" container.
> Pages and columns work this way. Cells usually do not.
>
Right. I planned to generlize your "bumpLine" method to break and bump
containers.
> 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.
>
I was going to leave this for later...
> 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.
Thanks for your thoughts Eric. Did you get a chance to read the class
heiracy's I proposed for the next generation code?
I think that once they get in place we can actually start doing things.
Cheers
Martin
This archive was generated by hypermail 2.1.4 : Wed Apr 24 2002 - 19:37:46 EDT