> Aaron,
>
> Thanks for diving in and starting this project. I expected from my intro
> that you'd go for the less ambitious dialog work, so I'm impressed with your
> rapid start on this.
Thanks for telling me what's really involved. I was a little
over-optimistic becuase I found _draw() in FV_View and changed the margin
color to white. I compiled it, and supprizingly, it worked. The rest of
the code I wrote involved making pagebreaks visible and moving some stuff
from the global scope to members of FV_View so it could be easily derived
from and writting the actual subclass. It was pretty much a stroke of
luck. The rest of the work involved on a "normal" layout is probably
beyond me, but I'll take a look. Maybe today I'll figure out some of the
interface code and make menu items for switching between views or maybe a
dialog that hasn't been written yet.
Another feature that I'd be interested in trying to implement is
displaying of invisible characters. Word has an option that lets you
display paragraph signs after every line break and small grey dots for
spaces. How difficult would this be? Would it be smart to just paint PNG's
of these symbols in the appropriate areas, or would that be too heavy on
memory and speed?
> At 07:38 AM 6/11/99 +0000, Aaron Lehmann wrote:
> >I went ahead and played arround in src/text/fmt/xp and came up with a
> >partially-complete patch for a "normal" layout mode. Note that this patch
> >forces abiword to use normal mode, since I haven't even tried playing with
> >menu items and etc. yet.
>
> I haven't applied the current patch, because I think we first want to get
> closer to an implementation of Normal View that our target user, a church
> secretary, would think Just Works the way they expect:
>
> - don't draw borders or background (DONE)
> - top ruler starts at the left margin, not the left of the page
> - no left ruler
> - format all content as inline blocks in series (SEE BELOW)
> - labelled dotted or dashed lines for page / section / column breaks
> - still print like the existing "page layout" view
> - easy toggling between modes
>
> Not surprisingly, all the hard work remains. :-(
>
> One of the chief advantages of the current "page view" mode is that it's
> a totally WYSIWYG layout, which makes printing easy. Yes, we had to do a
> bunch of work to get all that math for page separation, margins, etc. in
> place so that drawing, selections, mouse hit-tests, etc. functioning
> properly, but at least it's done.
>
> Forgive the ASCII art, but this means that with the right set of section,
> column, and page breaks, we can render and print a layout like:
>
> Header
>
> Section 1 XXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXX
> XXXX
>
> Section 2, Column 2 X
> Column 1 X XXXXXXXXXX
> XXXXXXXXXX XXXXXXXXXX
> XXXXX XXXXXXXXXX
> XXXXX
>
> Section 3 XXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXX
> (forced page break)
>
>
>
> Footer
>
> ----------------------
>
> Header
>
> Sec. 3 cont. XXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXX etc.
>
> By contrast, doing a true normal view means that the same content needs to
> be formatted and rendered quite differently for online:
>
> Section 1 XXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXX
> XXXX
>
> (section break)
>
> Section 2,
> Column 1 X
> XXXXXXXXXX
> XXXXX
>
> (column break)
>
> Column 2 X
> XXXXXXXXXX
> XXXXXXXXXX
> XXXXXXXXXX
> XXXXX
>
> (section break)
>
> Section 3 XXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXX
>
> (forced page break)
>
> Sec. 3 cont. XXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXX etc.
>
> To accomplish this effect, you'll need to dive (much?) further into the
> formatter and make sure that everything occupies a single continuous flow.
> Page constraints will still apply (for calculating line and page breaks),
> but they have a very different affect on the layout and rendering. Worse,
> you'll need to find a way to still run the existing layout algorithms at
> print time, since nobody ever wants true WYSIWYG of a normal layout.
>
> There may also be some additional page-centric assumptions in the ruler
> code, but I expect that they'll be much easier to address.
>
> Note that we'll need a similarly significant refactoring of the layout and
> display algorithms to add outline mode. At first blush, I'd guess that the
> layout work would be harder in this case, but the printing would be easier
> (since that's a more WYSIWYG layout).
>
> Bottom line
> -----------
> To make either Normal or Outline view Just Work is a significant project
> because of the layout refactoring needed. Take another look at the code and
> you'll see what I mean. If you're still interested in going forward, that's
> great.
>
> If not, we totally understand. After all, we deliberately punted all this
> work to a future release, too. ;-)
>
> >And I must point out - Abi is one of the best organized large source trees
> >I had ever seen. I was able to dive into it and understand how everything
> >worked. Perhaps becuase it's good old C++ :).
>
> We've also worked on big bad source trees before, and we're trying to do
> better with this one. The fact that we started from scratch helped. :-)
>
> Thanks.
>
> Paul
>