recovered files, glossaries (ngloss), and zrtf

[credneb]

(A) Perhaps it is due to how quickly I edit glossary files, but I can fairly reliably cause NWP to crash when editing and saving glossary files. (without actually trying) It seems related to commands, particularly Save and Close Window commands, being asserted too quickly. That is not the problem, or question.

Anyway, when re-opening Nisus, I select Recover and Show. I just noticed that the recovered files are all .zrtf, even though I always work with the document type set to rtf.

Glossary files (ngloss) are _not_ recovered, even though they are text files.

I have never noticed a difference in the behavior noted in (A) above when working with zrtf instead of rtf files.

So, when the file format is set to rtf, does Nisus do a round trip from rtf disk file -> zrtf -> [on screen editing] -> rtf -> Save -> back to zrtf for editing again?

Is glossary files not being Recovered a feature (if so, why?) or a gub?

Is working with zrtf files more efficient for Nisus than rtf? The compression step would seem to indicate the reverse. When does compression occur?

Mainly just curious...

Cliff

[martin]

(A) Perhaps it is due to how quickly I edit glossary files, but I can fairly reliably cause NWP to crash when editing and saving glossary files. (without actually trying) It seems related to commands, particularly Save and Close Window commands, being asserted too quickly. That is not the problem, or question.

Perhaps that's not the question, but we'd still be grateful if you could submit a feedback report after such a crash. Just relaunch NWP and use the menu Help > Send Feedback. Be sure to enable diagnostics and checkmark the option to send along your crash reports.

Is working with zrtf files more efficient for Nisus than rtf? The compression step would seem to indicate the reverse. When does compression occur?

ZRTF files are more efficient in terms of disk space, not only because of the zipping/compression, but also because NWP uses several optimizations to customize the RTF codes inside the ZRTF. We have a FAQ on large files that describes some of the techniques employed that make ZRTF more efficient.

It's true that compressing the ZRTF does take processing time, but overall it's still likely to be faster than saving the equivalent RTF, even ignoring other potential ZRTF optimizations. This is because writing to disk is incredibly slow when compared to CPU processing time. If you have less data to write to disk, you save a lot of time. That's why NWP uses ZRTF for crash recovery purposes.

So, when the file format is set to rtf, does Nisus do a round trip from rtf disk file -> zrtf -> [on screen editing] -> rtf -> Save -> back to zrtf for editing again?

No, that's not what happens.
1. Save a document as RTF: document on screen -> RTF codes -> file on disk
2. Save a document as ZRTF: document on screen -> optimized RTF codes -> compressed data -> file on disk

Is glossary files not being Recovered a feature (if so, why?) or a gub?

If you have a glossary file with unsaved changes and your autosave period has elapsed, and then NWP crashes, the backup should be recovered just as with any other file. You mentioned that you edit your glossaries very quickly, so my first question would be: has NWP had a chance to make a backup since you made your edit?