from Eric Sink.
---------- Forwarded message ---------- Date: Wed, 24 Apr 2002 12:41:55 -0500 From: Eric W. Sink <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Paul Rohr <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
