Subject: Re: Brewing a new backend
From: Leonard Rosenthol (leonardr@lazerware.com)
Date: Tue Dec 26 2000 - 18:32:51 CST
At 10:37 AM +1100 12/27/00, Martin Sevior wrote:
>On Tue, 26 Dec 2000, Leonard Rosenthol wrote:
> > At 8:50 AM +1100 12/27/00, Martin Sevior wrote:
> > >1. Cannot place an image in the background of the document.
>>
>> This should be easy enough to handle by simply having an
>> image blitted before drawing the text on top.
>>
>> Of course, with our current "too many redraws" problem, that
> > would slow things down even more - but it's certainly doable.
>
>We also have to worry about clearing the text. Right now we just rub it
>out with area clears.
That should be an easy change though, though you'll also need
to change the drawing mode of the text in the calls to the platforms,
so that they draw in Or rather than Copy modes.
>I was thinking along these lines but to me this constitues "major change".
I guess my point was that it doesn't effect the underlying
layout engine - it's a higher level change.
> > >3. Tables.
> >
>> Enough discussion on this one ;).
>
>I think we need a more powerful layout engine to handle tables too so we
>might as well think about what we need.
I am not sure that it needs to be more powerful, just changed.
>I think we have a choice of
>upgrading our present columns and page layout code, implementing nested
>columns or going along Mike Nordell's path of lines of overlapping text
>frames.
I missed Mike's suggestion, but I can tell you from
experience that using columns as a conceptual architecture isn't
going to work (well). You need to treat tables as a separate
concept, or at least a "subclass" of some existing ones. Otherwise,
you won't be able to support all the "cell merging options" available
with XHTML, and that users probably expect.
> > If that's the case, how do headers & footers work?
>>
>
>These are hardwired to fit into the top and bottom margins of each page by
>our per page formatter.
Oh!
>At present we have just a single pass
>page formatter once we have text frames/tables/footnotes etc we will have
>to allow a multi-pass formatter.
Agreed. Though it's not really multi-pass, it's multi-phase.
You first work at the page level (frames, floating objects,
headers/footers, etc.), then you work at the section level, then
finally the paragraph level.
Moving tables to the page level formatter (as opposed to the
paragraph or section level) would make the layout and rendering much
easier (since you could basically then treat each cell as a separate
document to render) - BUT it may make it harder to do cross-cell
selection.
>Optimizing this will be difficult I think.
If you design it up front, it shouldn't be too bad. But you
REALLY need to keep caching in mind, which apparently didn't happen
with our current paragraph formatter :(.
>Should I re-send the email I wrote on how headers/footers work?
>
Please!
Leonard
--
----------------------------------------------------------------------------
You've got a SmartFriend in Pennsylvania
----------------------------------------------------------------------------
Leonard Rosenthol Internet: leonardr@lazerware.com
America Online: MACgician
Web Site: <http://www.lazerware.com/>
FTP Site: <ftp://ftp.lazerware.com/>
PGP Fingerprint: C76E 0497 C459 182D 0C6B AB6B CA10 B4DF 8067 5E65
This archive was generated by hypermail 2b25 : Tue Dec 26 2000 - 18:44:10 CST