Yep. If you go back and build version 0.3.0 from last fall, that's about
what you'd see. It wasn't until late December that I added all those
constants and got the math right for shadows and borders, etc.
>I was hoping that everything else
>was contructed in such a flexible way that it would be easy to add/change
>functionality.
I still share that hope. This is just a bigger problem, so it's going to
take more digging deeper in the layout code to solve it.
>While you probably grew up with actual paper, I, as a 14 year old, grew up
>with the Normal Mode of MS Word 5.1a for Macintosh. I think that the
>Normal mode is the best becuase it focuses on the relevant medium. When
>you're writting a document on a computer, you usually don't care about
>actual paper, which Page Layout simulates. The exception is before [if]
>you print the document, when you go through a Print Preview and make sure
>it will formatted nicely. In Normal mode, you don't loose valuable screen
>real-estate to pages and see more on the screen in a window of the same
>size. Even with columns - you get to type naturally and have the computer
>format it into however many columns you want instead of having to type in
>cramped columns.
Sigh. You just caught me being grumpy and trying to justify our decision to
not bother implementing the feature for a while. I'll relent now.
Of course there are advantages to using normal view, especially for folks
who are used to using it. As soon as someone can figure out a good way to
implement the feature, I'd love to have it as part of the product.
>I understand what you are trying to sugest, if that's your question. Right
>now, you know better than I do whether it is feasable from a prespective
>of the internal structure of AbiWord. I, of course, would love to go for a
>clever hack.
Actually, it's been so long since I trolled through that portion of Eric's
code that my recollection of what's feasible isn't worth all that much.
Plus which, it's always good to get some fresh eyes on a problem.
If you've got some time, why not take a few hours and dive deeper into the
layout code and see if you can figure out the answers to some preliminary
questions like:
- are the lower-level objects (lines and runs) still parent-relative?
- how do the column and page code work together right now?
That should be a manageable first step, and I'm sure Eric would be willing
to give you some pointers if you get lost. Given the answers to those
questions, it should be a lot easier to figure out whether the repositioning
trick will work.
After all, the nice thing about this approach is that it prevents us from
having to do a much more significant refactoring of the layout classes. I
really hope it turns out to have been a good idea.
>> PS: If this approach does turn out to be feasible, then we could apply a
>> similar principle to Page View so that zoomed pages could appear side by
>> side, rather than just always in a linear vertical sequence.
>>
>Side by side? Like a print preview? I don't quite understand why this has
>anything to do with a normal mode.
Sorry. I was just reasoning by analogy. The relevant difference beween
normal and page layout view is whether columns are laid out side-by-side or
vertically. If you think about pages rather than columns, there's a similar
difference between our current page layout view and print preview.
If we can solve the columns problem by switching coordinates at the column
level, then we ought to be able to do a similar thing for pages. But I'm
getting ahead of myself. That's not relevant to the current discussion.
Paul