🚀 go-pugleaf

David Meyer (dmeyer@tiac.net) wrote:
>part of a large document. This is somewhat true of any editor with even 
>the most minimal page formating features, like word wrap or page break, 
>but the WYSIWYG programs suffer more and those with a multitude of 

This is not really fully correct. A WP/editor does not have to be
noticably slower when editing the start of a larger text.
Considering a reasonable WP text memory implementation, a WP has to
relayout more than the current paragraph only when the line count
changes. Let's assume that we add or delete a line in the beginning
of a document with n pages. This means that we have to check at
most n+1 paragraphs for a relayout and even there we don't actually
have to fully relayout the current text in the current paragraph.
The other n paragraphs only need to be updated in terms of the page
break location. All the paragraphs that don't need to be checked
for a relayout at a page break only need to be updated via a Y
offset addition which needs to be updated itself at most once per
page. Assuming that we use a linked list of paragraphs (of course
we do, don't we?), we'd need an estimated 2*(n+1) list insertions
deletions and n+1 field updates for a reasonable implementation. No
lengthy text fit or length calculations involved at all as the
line representation of a vertically moved paragraph doesn't change
at all. For anchored or text flow graphics, additional calculations
are obviously needed. But even there it can usually be reduced to
placement checks and Y coordinate or list position updates. No need
to move large memory blocks. And if a forced page break is inserted
after a paragraph on e.g. page n/2, it might very well be that we
can cut short all the calculations at page n/2 beause the following
pages won't change. For page cross references, we can avoid an n!
like update algorithm by remembering them in a list and do one
final linear update. For typical documents, I feel that 1ms per
paragraph update (not relayout) on an A3k is plenty. That is only a
"top of my head worst case" feeling, so you'd notice a bad slowdown
per line insertion only for fairly huge sections. It is probably
easy to cut down the typical check to a lot less than 1ms per page.

Note that display time is needed only once, and even there it is a
partial screen scroll, and an update of the scrolled areas. Display
time is not an issue here.

So if a WP gets slow on large amounts of text, the implementation
for internal text memory handling needs to improved. I know that
FW4 currently has this problem and I hope that something has been
done about it for FW5. I do not say "it so easy to fix this or
that" because I know it hardly ever isn't. I hope for the best,
though, because I'd like to use FW for larger documents, too. I
don't like to start a new section every 10 pages. :^)

Two other annoying things that I hope to see fixed is that marking
text with the keyboard is wasting my time with really excessive
block marker redraws and that I can't configure the keyboard
mapping. I'd like to change at least the qualifiers for
cursor key movement.

>FW5 in our hands first before we start pleading for more. Woody & crew 
>were pretty good about the FW5 lists posted here.

Yes. I'll update as soon as possible, too. I like FW.

-- 
Heinz Wrobel        Private Mail:   heinz@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email