Page 1 of 1

Typesetting bug 3.0.1 - all lost on any edit

Posted: 2019-06-20 11:38:22
by withoutFeathers
Hi,
I'm a long-time user of version 2 (many years), who just upgraded to 3.0.1.

I have a major issue that must be resolved (maybe it's a new setting, but could be a bug?):

Issue:
When working in PageView, whenever I make ANY edit in the document, all typesetting after a few pages is lost, and the typesetting begins to rebuild the entire document.

I've tried restarting, saving, and on two different documents.

This is something that never happened in version 2, because Nisus would wait for the entire document to be open (say, 500 pages), and then the whole 500 pages were stable and I could edit anywhere and scroll anywhere quickly.

Further details:
Say it's a 500 page document.
Now it opens immediately, and I can edit on page 5 right away, while the bottom indicator says "Page 5 of 52..." and the "52" keeps going up as the typesetting is loaded into memory.

So let's say it has gotten to 356, after a minute. If I make an edit, say add a comma or delete a word, the scroll bar on the right snaps back to large size and the bottom says "Page 5 of 16" and all the typesetting of the later pages is lost.

This is terrible. It's impossible to scroll around to later pages, and the jumping around of the scroll bar is annoying.

What's going on? How to fix?

WF

I'm on Mac 10.11 (El Capitan) on an iMac.

Re: Typesetting bug 3.0.1 - all lost on any edit

Posted: 2019-06-20 11:51:44
by martin
The short answer is that version 2 did very similar things as version 3, but simply didn't make it as apparent to the user. For instance, the page count would not reset and count back up as typesetting occurred in the background. However, version 2 did ultimately work very similarly. Making an edit on page 5 generally requires redoing layout for pages 6 onward, no matter what version of Nisus Writer you're using.

Users of version 3 have made it clear to us that they don't want to be aware of this kind of background activity. We understand it's distracting to have indicators like the page count or scrollbar position changing constantly. We are working on any update that should alleviate most of these problems. I'm sorry for any nuisance in the meantime.

Re: Typesetting bug 3.0.1 - all lost on any edit

Posted: 2019-06-20 15:13:57
by withoutFeathers
Martin, you have helped me many times, and I know you mean well here, but what you've said is fundamentally incorrect on my machine.

I just tested 2.1.10 against 3.0.1 on the same file.

To repeat, in more detail:
2.1.10 Loads the whole file, (which is 1007 pages, and takes two minutes) and then allows me to edit on page 3 and then scroll immediately to the very end, and back to the beginning, without more than a 2-second pause during my scroll to the end. The whole file REMAINS AVAILABLE even though I edit at the beginning.

WHEREAS:
3.0.1
When fully loaded (same 1007 page file), if I edit at the beginning, not only does it now report that I'm only loaded to page 4 and begins reloading, BUT THE REST OF THE FILE IS NOT AVAILABLE during the reload, which takes two minutes.

This is a fundamental difference between the two.

Please believe me this is unusable. It's apparently a bug if you think it should behave the same as 2.1.10. It's not just the reporting of the positions. It's access to the later pages which has been lost.

wf

Re: Typesetting bug 3.0.1 - all lost on any edit

Posted: 2019-06-21 10:34:07
by martin
Thank you for the extra feedback, and for sharing your experience.

What you've said can be true, but not always. If you make an edit in version 2 that shifts layout geometry you will still need to wait for complete repagination in Page View to scroll to the end. For example, creating a new paragraph in version 2 will always force complete repagination. It's the same if regular text editing changes the number of lines in an existing paragraph, or editing otherwise shifts line placement.

Only trivial edits that do not affect geometry or line placement will preserve existing pagination in version 2. For example, replacing a single word with another similarly sized word, or inserting new text into a line that doesn't overflow or expand that line.

It's true that version 3 does not permit this optimization when making trivial edits. Version 3 is more aggressive in requiring repagination, no matter the type of editing that occurred. That is behavior we could consider changing. It may be possible to restore the preservation of layout for trivial edits.

I hope that clarifies the situation. I'm sorry for any trouble the change in behavior causes you.

Re: Typesetting bug 3.0.1 - all lost on any edit

Posted: 2019-06-21 10:44:04
by withoutFeathers
Thank you and this clarifies slightly, but I just tested what you said in version 2, and I think you're still missing the major point about version 3's difference from version 2.

I mean:
I just added a new paragraph that was twenty lines long into a version 2 page near the start (of my 1007 page file). If what you say above is true, this is non-trivial and must force repagination, correct? Then I dragged the position slider to the end. Spinning beach ball for about 1 second, then allows me to access the final page.

In contrast, version 3 takes a full two minutes to access the final page after doing this. It has to reset the text fully.

Thus version 2 is somehow re-using the existing memory of the text layout and saving me that two minutes, even in non-trivial edits.

Can you verify that this difference exists on your machines?

This is a major difference that you still haven't referred to or explained.

Steven

Re: Typesetting bug 3.0.1 - all lost on any edit

Posted: 2019-06-21 11:18:54
by withoutFeathers
An addendum:

I've just noticed in version 2 that when I inserted a Section Break, next Odd page, the complete typesetting of the whole document is forced, and I have to wait for the typesetting to complete before I can access the end of the document. This is understandable to me because at least one full page has been added, possibly two.

This is the same behaviour I get in version 3 for adding a comma (or removing one).

wF

Re: Typesetting bug 3.0.1 - all lost on any edit

Posted: 2019-06-21 14:01:07
by martin
The operation you described (adding twenty lines) in version 2 should indeed require full repagination of your text in Page View. Even before my earlier reply to you I verified the behavior. I opened a test document that's about 400 pages. Version 2 took some time to paginate the whole thing when opened. I inserted a single new line of text on page 1, and then tried to scroll to the end. It took just as long to show the final page as it did to initially open the file.

However it's possible there's some further optimization being triggered for your particular document, or your older system version. How this all works depends not only on Nisus Writer, but also on the system text layout engine. Maybe there's a clean break at some point in your file where the layout system can synchronize and reuse prior layout information? Version 3 would prevent such reuse because it specifically forces discarding existing layout. This was done to prevent a whole host of layout bugs.

Theoretically it might be possible to restore such optimizations, depending on the exact layout situation. However, it's generally not practical and fraught with potential problems and complications. The reason for that is due to advanced options like footnotes, widow & orphan control, balanced columns, floating shapes, etc. For all those features (and others) layout really does need to be recalculated and verified for all text following any non-trivial edit.

I hope we can still eventually improve the behavior in version 3, so trivial edits don't trigger repagination. That should still be possible in the future, without reintroducing the bugs we fixed.

I hope that helps explain things better. Please let me know if you still have any questions.

Re: Typesetting bug 3.0.1 - all lost on any edit

Posted: 2019-06-21 16:43:55
by withoutFeathers
Thanks for the extra information.
Would Section Breaks be 'clear breaks'? (And are there other 'clear breaks'?).

I ask because I tested my document in version 2, and found I have four sections in the 1007 pages. Two of the breaks are within the first 40 pages, and the final one is at the very end.

However, when I tried the 'add a large paragraph' test again, and scrolled only within the single large central section, version 2 still moved me quickly to where I wanted to go. It didn't require rebuilding, even 500 pages away, within the same section.

Perhaps Version 2 has some other way of caching the material that isn't by Section breaks?

Anyway, I get the picture. I'm continuing to use version 2, and probably won't buy version 3 unless/until this behaviour changes. That's unfortunate because you've put a lot of effort into other things in it I know.

wF

Re: Typesetting bug 3.0.1 - all lost on any edit

Posted: 2019-06-26 10:52:27
by martin
withoutFeathers wrote: 2019-06-21 16:43:55 Would Section Breaks be 'clear breaks'? (And are there other 'clear breaks'?).
That's certainly possible. Page and section break characters are quite definitive in the way they reset the layout stream. They always force a new page or new text area. In that way they might be useful synchronization points for the Mac text layout system.

The only exception is a "same page" section break, since the text area after such a break is variable in size, depending on preceding text text content. I anticipate that kind of break wouldn't be as useful to the layout system.