Subject: Re: Brewing a new backend
From: Martin Sevior (email@example.com)
Date: Tue Dec 26 2000 - 15:50:19 CST
On Tue, 26 Dec 2000, Jesper Skov wrote:
> Hi there! (and merry Xmas!)
> I've been thinking about making some serious hacking on the backend of
> AbiWord for a while now. There have been a lot of discussions of
> various rewrites/hacks of that part of AbiWord, but it's going to be a
> very big job - and I fear that it'll never happen if we don't get
> So to avoid breaking the existing backend and avoid holding up coming
> releases, I wonder if I could be allowed to clone the existing backend
> (abi/src/text) as abi/src/text2 and check it in. Adding a simple
> compile option would allow people to play with the new backend and
> more importantly allow me to check in changes piecemeal instead of
> waiting for a 100% rewrite to be completed.
This is a major shift for us. I have some questions I'll ask at
appropriate places in this email. You realize of course that there will be
major changes and additions to text/fmt/xp/* as we finalize version 1.0.
You'll have to track these of course. On the other hand if you're going to
this level trouble we should also make sure Abi's current formatting
deficiencies can be addressed by your new code.
> I've considered creating a CVS branch instead, but I'd rather have a
> separate directory - allowing people to switch backend with a compile
> option instead of faffing about with CVS.
One thing I'm concerned about is the number of compile options we
currently have. At some stage we should look to consolidate them as their
experimentalness is proven one way or the other. I guess in this case
though the code is really in a different branch of the tree.
> These are the issues I would like to address:
> o Improve documentation - both overview and API wise using
> Doxygen. [will happen as I fight^Wwork my way through the code]
This has got to be good.
> o Split existing view code into view and controller code.
You need to merge in all the code from pd_Document.cpp. This class is more
effectively the controller in Abi than the fv_View. The view class is more
like a convience wrapper around the pd_Document which connects the
curently active view to the controller. Did you see the email I sent Mike
Nordell and the list explaining my understanding of how abi works?
> o Updating/including Mike's Cursor class.
Keeping track of cursor motion has been a real pain and is easy to get
wrong. This could really help.
> o Fix fake-run/findPointCoords mess by introducing EOL/EOD runs.
On your way could you finish show paragraphs by showing the funky
backward P's at paragraph breaks?
> o Move attributes from content Runs to separate attribute
> Runs. Reduces data size, speeds up lookups, allows (if desired)
> full attribute show code feature as in WP.
> And eventually:
> o Look into caching IP searches on page/column/line levels reducing
> time spent traversing the document.
> o Look into representing the document using an AVL tree instead of
> the doubly linked list.
In addition to these improvements do you have ideas on how this code would
help the following deficiencies in Abi. MS Word has these but our current
formatting code cannot handle them at all.
1. Cannot place an image in the background of the document.
2. Placing an arbitary shaped object on a page and have the text flow
For 2 and 3 we will require some new class in our piecetable. Currently
the piecetable assumes that all content of the document flows sequently
onto the page. In the case of tables/frames/objects we have no structure
in place which can be used to place these at arbitary locations on a page.
Having played with Word a bit this a difficult thing to get right. The
formatter in Word constantly shuffles stuff around in a attempt to get
things close to what it thinks you want.
I had thought we could use attributes of sections to do these things but
if you're taking a fresh approach we should try to find the best way to
handle these cases.
This archive was generated by hypermail 2b25 : Tue Dec 26 2000 - 15:50:34 CST