Sick Document

Everything related to our flagship word processor.
Post Reply
levelbest
Posts: 21
Joined: 2018-04-04 06:29:10

Sick Document

Post by levelbest » 2019-08-20 08:52:40

I have a Nisus document that is not behaving as it should. Long ago Nisus had a Zap Dingbats command that was designed to kill any weirdness that could have worked its way into the code. I don't see this feature in the help menu.

I have several Nisus documents. The other Nisus documents are behaving as they should. Only the one is behaving oddly. It is taking a very long time to save. My other Nisus documents barely take a second to save. This document shows a blue saving progress bar along the bottom and it takes a few seconds, long enough to get a spinning beachball each time I save.

And, once I have closed the document, when I reopen it, my graphics are completely hosed. That is, several of about 6 - 8 graphics in the document have now become HUGE and are unreadable. That is, they take up the same space as before, but the visible part of the graphic seems set at 250 point font or some such.

I have taken the graphics from a different Nisus document as this one is a revision version of an earlier document. The graphics work perfectly and the saving time works perfectly in the other documents, but not in this one it seems.

I have tried making a copy of the document for testing, and the copy does the same thing. I have tried saving a new version, and the same thing happens.

Nisus has always been a very stable and reliable app. And the rest of my Nisus documents seem to be doing just as they always have. But this one .. I have no idea how this happened and even more important, I have no idea how to be rid of it.

It sucks to work so hard on a final draft, save it, e-v-e-r s-o s-l-o-w-l-y … and then when it is put away and later it is reopened, you have to redo all the darned graphics - AGAIN.

Any ideas? Thanks.

This is Nisus Writer Pro version 3.0.2
System: High Sierra 10.13.6
Pages, about 30
Filed in: The same documents folder as my other Nisus files.

martin
Official Nisus Person
Posts: 4586
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: Sick Document

Post by martin » 2019-08-20 09:16:23

I'm sorry you're having trouble with a particular document. From what you described regarding very slow saving, you probably have an embedded image that is very large in terms of its data size (in bytes). When you insert a graphic Nisus Writer preserves all of the original image data, even if you resize the image to appear smaller on screen.

Did you insert any large photos, PDFs, or schematics into your document? These days it's not difficult for a single image to be incredibly large. I've seen panoramic photos taken by my iPhone that are each around 30 megabytes in size.

One tool you can use to help you identify large images is the menu File > Image Analysis. It will show a summary information for the current selection and whole document, including the largest images. If you click the little arrow buttons next to the "Largest Image" labels you'll be shown a full list of all images in your selection/document, sorted from biggest to smallest.

I hope that helps you solve the problem, but if you need more help just let us know.

levelbest
Posts: 21
Joined: 2018-04-04 06:29:10

Re: Sick Document

Post by levelbest » 2019-08-20 09:35:12

Yes I was just looking at that. Although at this point I do not understand what is going to be an optimal size for an in line graphic in size.

What concerns me more though, is that when this happens, I open an earlier revision of the same Nisus file, copy the images again, and paste them into the new sick document. I am using the same graphics that the other Nisus document has no trouble with at all. So this leads me to ask about the old zap dingbats method that Nisus had long ago. Is there any way of applying something like this to this particular file?

martin
Official Nisus Person
Posts: 4586
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: Sick Document

Post by martin » 2019-08-20 10:08:14

levelbest wrote:
2019-08-20 09:35:12
Although at this point I do not understand what is going to be an optimal size for an in line graphic in size.
There isn't a single optimal image size in bytes. It will depend on a lot of factors, including the quality you need (eg: DPI) for whatever final output you intend. It can even vary by the image data format. A megabyte of data might be used more effectively by one format vs another (eg: JPEG vs PNG).

I would say that if you have images that are many megabytes in size you should think about reducing their size externally, outside of Nisus Writer. Perhaps a multi-megabyte image is appropriate for large visual output (eg: a book cover), but probably not for an inset graphic. But really it just depends.
So this leads me to ask about the old zap dingbats method that Nisus had long ago. Is there any way of applying something like this to this particular file?
You're probably thinking of old commands like "zap gremlins". That's unlikely to help here. The potential issues today are usually going to be different than olden times when a few invisible characters caused havoc.

One other thing to check: do you have tracked changes enabled for your document? You might be accruing a huge amount of prior text or images, especially if you keep trying to fix your "sick" document by copy-pasting the images over and over. That could continually multiply the images in your document, further increasing its size.

If you still have trouble, maybe you could send us the problematic document? It's much easier to diagnose these things if we can see the actual file you're using.

levelbest
Posts: 21
Joined: 2018-04-04 06:29:10

Re: Sick Document

Post by levelbest » 2019-08-20 11:12:20

martin wrote:
2019-08-20 10:08:14
You're probably thinking of old commands like "zap gremlins". That's unlikely to help here. The potential issues today are usually going to be different than olden times when a few invisible characters caused havoc.
Oops, my bad, Yes indeed, zap gremlins. Zap dingbats is a font. Continuing with the idea that this is about some internal corruption in the file, One of the graphics I am using is getting all mangled when it is saved in one location, and the same graphic is used at another location in the same document, which is not getting mangled. I am posting a screen shot of the image evaluation screen FWIW.
martin wrote:
2019-08-20 10:08:14
One other thing to check: do you have tracked changes enabled for your document? You might be accruing a huge amount of prior text or images, especially if you keep trying to fix your "sick" document by copy-pasting the images over and over. That could continually multiply the images in your document, further increasing its size.
I have not used that feature although it is possible that it somehow became set without my knowledge by a random key command ... (?) I am posting a screen shot of how my track changed are set now and if this looks like it is doing as you were asking after, please let me know.

I turned on show invisibles and, if there is anyway I can learn about the problem and correct it myself, I will be happy to try out any suggestions. Mistakes are after all the best way to learn. Otherwise I will send you the file to review as you offered.

Thanks.

PS: The next thing I will try is to re-drag the graphics onto the document. Perhaps the ones I keep taking from the other Nisus document - even though they appear good in that document, are corrupting their internal identifiers and dragging in the graphics fresh will help?

Screen Shot 2019-08-20 at 12.56.55 PM.jpg
Screen Shot 2019-08-20 at 12.56.55 PM.jpg (77.92 KiB) Viewed 2000 times
Screen Shot 2019-08-20 at 12.51.14 PM.jpg
Screen Shot 2019-08-20 at 12.51.14 PM.jpg (17.57 KiB) Viewed 2000 times

martin
Official Nisus Person
Posts: 4586
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: Sick Document

Post by martin » 2019-08-20 12:07:12

Your screenshot of the tracked changes options window shows that you do not have tracking enabled. So that's unlikely to be a problem. It's still possible your file has tracked changes that were recorded earlier, but that's unlikely, especially if you didn't turn it on.

However, your screenshot of the image analysis does indeed show a huge image. Your largest image is 74 MB (megabytes). That is huge! Much bigger than you need, no matter what kind of output you're doing. And that's just a single image. If you have many images of that size in your document, you might even near a gigabyte of data just in images. That's definitely not what you want.

If you click the little arrow icons in the Image Analysis dialog it will open a list showing all images in your document. You can click through that list to highlight and select the offending images. You should resize them externally, so they are reasonably sized.

levelbest
Posts: 21
Joined: 2018-04-04 06:29:10

Re: Sick Document

Post by levelbest » 2019-08-20 12:37:34

martin wrote:
2019-08-20 12:07:12
However, your screenshot of the image analysis does indeed show a huge image. Your largest image is 74 MB (megabytes). That is huge! Much bigger than you need, no matter what kind of output you're doing. And that's just a single image. If you have many images of that size in your document, you might even near a gigabyte of data just in images. That's definitely not what you want.

If you click the little arrow icons in the Image Analysis dialog it will open a list showing all images in your document. You can click through that list to highlight and select the offending images. You should resize them externally, so they are reasonably sized.
Thanks. The other Nisus documents were not reacting to any of this so once again, I still think something else is going on here.

But you offer a good perspective and, I take your point. I just sent an email to the creators of Acorn, my goto graphics program about this very point. I am making heavy use of Acorn, importing (single page) PDF documents at 600 dpi, making key text stand out using layers and filters, and saving as png files. I started doing this because it was far easier to place a graphic in my text document than to put a PDF in line. I discovered a great way of highlighting text in the process.

But now that I have this process down, I need to begin thinking about how large a file really needs to be when I am done. GraphicConverter will set a target to reduce a file too, I don't think Acorn can currently do this. I am open to what a reasonable file size would be in a Nisus document? When I used to do web sites, most graphics were enough at 72 dpi as most browsers can't show the difference. I initially converted the PDF at 600 dpi so that all my text was crisp and it showed nothing different from the PDF it came from.

A document has a final destination in my use as either a printed document or saved as a PDF and becoming and emailed PDF document. Most of these images that are blowing up are just parts of a scanned PDF document such as the top section of a page with highlighted text using B&W in layers, punching up the text I like, erasing away the other layer, and merging the layers. So this should not have to be a very large file when all is said and done.

Given this information, can you suggest a high and low optimum size that I my try?

Thanks.

martin
Official Nisus Person
Posts: 4586
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: Sick Document

Post by martin » 2019-08-20 13:11:26

levelbest wrote:
2019-08-20 12:37:34
The other Nisus documents were not reacting to any of this so once again, I still think something else is going on here.
The difference might be explained by the way in which you originally inserted images. If you just link to the image then its data won't be stored in the document; only a reference to the image on disk will be saved. This option is available in Nisus Writer's image insertion dialog, if you turn off the "include copy of image data in document" option. Just be sure that you don't mind storing your images external to your Nisus Writer document, and that your publisher can handle receiving documents using these options.

Or maybe you're using RTFD for the other document, instead of RTF? That's more efficient for storing images on disk, though with images whose size is over 50 MBs I expect you'll eventually run into trouble using any file format.
I am making heavy use of Acorn, importing (single page) PDF documents at 600 dpi, making key text stand out using layers and filters, and saving as png files.
This is almost certainly the cause of your trouble. Although it depends on the exact nature and content in your PDF, it's most often the case that converting a big PDF to PNG will hugely balloon the image size. The reason is that PDFs can encode their text and other line forms using font data or mathematical equations. Those are going to be tiny compared to a PNG, which always encodes data using pixels. That's especially true if you're using high DPI. Most data in a PDF uses the same amount of (small) space on disk no matter what the output scaling. PNG data sizes will increase with the output resolution.

Try it: convert a single page PDF to a PNG image and compare their file sizes on disk. I expect the difference will be immediately noticeable to you. You'll probably see at least a 10x increase in file size.
Given this information, can you suggest a high and low optimum size that I my try?
Ideally you would leave these PDFs intact as PDF images. If you convert them to PNGs you're always losing data. Even if you use a high quality image conversion (eg: 600 DPI) and don't lose any visual fidelity, you lose semantic information and potentially lose functionality.

Mostly I'm referring to the intrinsic "text" property of the data. If you insert a PDF image into a Nisus Writer document, and then export the full document as a PDF, the text-ness of the original PDF image will be intact. That is, you can still interact with that original PDF text as text, eg: select it, copy it, etc. Once you convert the image to a PNG the data is no longer text. Exporting your final document as PDF no longer results in text, just an image. I hope that makes sense.

levelbest
Posts: 21
Joined: 2018-04-04 06:29:10

Re: Sick Document

Post by levelbest » 2019-08-20 17:15:33

I now see this as some sort of an internal bug in Nisus. Two things have occurred for me to have arrived at this conclusion.

First, I discovered that one of the problem graphic files, when I right clicked on it, asked if I wanted it restore it to its original size (don't have a screen shot of that menu so I am paraphrasing). When I said yes, the image returned to readable.

And second, I have compared the same files in the previous revision, also a Nisus document. Those files are in kilobytes, not megabytes. One or two are low megabytes, 2.1 or some such and I will pay better attention on shrinking those file sizes in the future. However, the key point here as I am seeing it, is that for some unexplained reason, this Nisus document has ballooned some of the graphics files hugely, to over 70 mb in size.

That was done by Nisus, not by me. Once again, the files that I copied from, were in kilobytes (for the most part) and were no where near the size that they ballooned into in this "bugged" Nisus document.

All I can do now is to report this as a bug report to the Nisus developers and very carefully, recreate a fresh document with all my revisions and changes. I am a fan of Nisus. But in this case, I don't see any rhyme nor reason why the graphics files would balloon to this degree - or in fact to any degree at all.

I can pick up the thread as to why I am using graphics instead of a PDF (for very good reasons), but at this point, it seems like a distraction taking us away from the main point of this thread which I now believe, is showing something very odd and very internal as to why Nisus would so severely balloon its graphics in a file.

martin
Official Nisus Person
Posts: 4586
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: Sick Document

Post by martin » 2019-08-20 20:19:12

Since you feel this is a bug in Nisus Writer we'd be happy to take a look at your files to confirm or deny that hypothesis. Can you please share both of your files with us somehow? It would be best if we could see both the smaller file and the larger file. Since one of your documents is very large you'll likely need to use some kind of file sharing service (eg: DropBox, Firefox Send, etc). Once you have the files ready please contact us privately via email at:
Image

levelbest
Posts: 21
Joined: 2018-04-04 06:29:10

Re: Sick Document

Post by levelbest » 2019-08-21 06:27:02

Thanks, I will have to get back to you on that. I made a copy of the problem revision and I have a copy of the file to compare it with. But right now I am under the gun with this project - and the next one. So I will have to come back to doing this. As I stated, I know I did not drag in a 70 plus meg file so I don't know how this happened. This is the first time I have had this issue. I still have absolute confidence in Nisus so I will continue.

I have been copying all my date, text and images, and pasting it into a Notes file so that I can walk outside with my iPad and do further editing. Then I resynch to my Notes on my desktop and paste my edits back into my Nisus document. Sometimes I have probably copied the images back from Notes as well. It could be that in this process, Notes reverted the file to a larger size and Nisus … I don't know … tweaked the image even more? I will get back with you on this but I have to get back to my project right now and I think I at least have learned something from all of this.

Regarding my process of creating image files from PDFs to highlight my documents, it is a brilliant strategy if I say so myself. What I have learned in all of this is that, as the final image is going to be an in-line graphic in a Nisus file, all I really need to do is to take a screen shot of the finished document once I have made my changes and highlighted my text. By taking a screen shot I have a perfectly acceptable 72 dpi image, low file size, that is suitable for printing in my document.

My process is quite simple.
  • I import a single page of a PDF at 600 dpi.
  • I use duplicate layers and I increased the gamma setting to punch up what I want highlighted on the bottom layer.
  • I then erase the top layer areas that are covering the text I wanted to highlight, to see it stand out.
  • If I really want a contrast I can also use the gamma settings and bring down the top layer so that it is even softer and the bottom punched up layer stands out even more.
  • I use gamma settings because this increases and decreases the whole value of the B&W text in that, no matter how bold or how washed out it becomes, it never pixelates but remains clear.
  • Take a screen shot of the finished image for insertion into a Nisus document.
I came up with my solution after going through years of old medical records and service files. Many of these PDFs are old medical records which include lots and lots of doctor’s hand written notes. It is not always easy to pick out one sentence or one date among all the other items written on a page.

People in this day and age think in Tweets and prefer to communicate in very short sentences. To make my points in a document that has a whole lot of other information in it, it has been extremely useful to highlight my points and to back up my arguments in this way.

As these doctors notes are often in multiple sections, each with a different date stamp, I also make good use of the crop tool as I don't need more than the information I am highlighting to make each point to the reader. This is another reason why this method is far better than just dragging in a whole PDF page.

My method allows each point to be easily seen and therefore, the arguments I am making can be communicated and clarified and can be shown to be fully supported by the evidence. I plan on including each full PDF as an attachment for anyone to review and verify.

Now with all my images as screenshots, my file sizes are around 130 - 230 kb. The long saving time interval has also gone away. It was the huge, bloated image files that were causing all the trouble. How they got there, we will have to revisit at a later time.

Thanks very much.

Post Reply