Generating a TOC and converting the doc into a PDF ...

[Rajam]

Hi Martin, I don't mind sending you the original doc. Meantime, I'm trying to figure out what's going on.

From what I found , I can say this quickly, but it needs to be deeply investigated. The algorithms among the following factors -- "pagination" "footnotes" "bold face" italics" "widow/orphan control" "keep with next paragraph" ... etc., etc. -- are impacting one another, as far as I can see.

Plus, the TOC has to be generated more than once in order to get the right page indication. And, even after such an effort, the PDF doesn't generate accurately.

Please believe me, I'm not a stupid user! I have 17 years of experience in the IT industry.

I'll catch up with you soon. Thanks much, meantime.

[Hamid]

I have been following this thread with much interest, as I have encountered this nasty bug several times. One of my own workarounds is to create TOC as a separate file, correct wrong page number references, make a PDF of TOC, and then combine PDFs into a single PDF.

Rajam, if internal clickable links in the document don’t matter, open your original document (with widow/orphan control and keep with next paragraph) afresh and use the ‘Open PDF in Preview’ command and save the PDF.

Of the factors you mention, footnotes, widow/orphan control, and keep with next paragraph appear to be relevant. Other factors such as page margins and most of all what happens immediately after the Print command is applied is crucial.

I have suggested to Feedback to allow the user, in the Automatic Content Update Preferences pane, to disable updating of content before printing or saving a PDF, because this ‘updating’ may in fact be messing up the layout. Here is why:

All my automatic numbers are already set to update immediately. I check my entire document to see that each page is all right. I have, here in the example, a document of 358 pages which is exactly as I want it to print. As soon as I apply the Print command, the Automatic Content Update before Print feature kicks in and the number of pages jumps to 440, as you can see in the screenshots of the Statusbar.
Before Print:

BeforePrint.gif (7.58 KiB) Viewed 15989 times

After Print Command:

AfterPrint.gif (7.51 KiB) Viewed 15989 times

When I examine this document, the extra pages are distributed between the original 358 pages, resulting in large blank spaces between the last line of the body text and the first line of the first footnote appearing on each page. Needless to say the layout is no longer the same as before the Print command was applied.

[Rajam]

Hi Hamid,

Thanks for understanding my problem. Yes, there's quite a bit of white space created on certain pages in the PDF generation. I wish that would be controlled.

I feel a bit diffident to generate separate PDFs (for example, one for the TOC and another for the main document) and combining them all together later on.

Anyway, I'm hoping that the current problems are resolved as soon as possible,

Thanks,
Rajam

[Rajam]

This is certainly a gnarly bug! I'm trying to find my own work around while the Tech Support at Nisus would find a technical solution for it.

(When I have the time) I'll let you know what I find and what I do about it.

Thanks and regards,
Rajam

[glh]

There is another -- I think related -- issue I've found. If you generate a TOC, cut and paste it to a new document, and then make a pdf of that new document, the page numbers are all replaced by PAGE. The only way around this seems to be to paste the TOC into TextEdit and then copy it from there. I think this is problematic -- any suggestions? Thanks. George

[Rajam]

George,

The issue of the word "PAGE" appearing instead of a page number would happen even otherwise.

That is, when you edit the document and make changes to some titles/headings or whatever which had been already marked for a TOC by a different item/heading, and then you rebuild the TOC by just selecting the option "update page numbers only" you'll get PAGE in the TOC. In such case, we should have (!) selected the option "update all content" or whatever it is and then go for the next option "update page numbers only." It is not clearly stated in the User's Manual, unfortunately. .

That's ok, since I resolved the issue by trial and error.

++++++++++++

Generating a TOC just once and copying it directly to a separate Nisus file may show PAGE for all the numbers in the TOC.

Generating a TOC and copying it on to a TextEdit and transferring to a NIsus document would also do the same thing.

However, if we generate the TOC three/four times in the original document (using the "update page numbers only option") and then copy the TOC on to a new separate Nisus file, the TOC looks fine; no more PAGE syndrome.

++++++++++++++

There are other problems which I'll discuss later on. I'm tired.

Thanks,
Rajam

[martin]

We definitely don't want users to have to work hard to get a correctly numbered TOC in a PDF. One should be able to just save a PDF without thinking about anything. We're working on getting this numbering bug (and unwanted whitespace expansion) fixed.

If you generate a TOC, cut and paste it to a new document, and then make a pdf of that new document, the page numbers are all replaced by PAGE. The only way around this seems to be to paste the TOC into TextEdit and then copy it from there. I think this is problematic -- any suggestions?

This is the expected behavior, though perhaps it's not obvious. The generated TOC numbers maintain an internal link back to their targeted content (ie: the headings marked for TOC inclusion), but the link is only valid within a single document. When you copy-paste the TOC to another file, the links are no longer valid (unless you also copy-pasted the targeted headings).

When you generate a PDF/printout of this copy-pasted TOC, the page numbers are automatically updated. But since the targeted headings are no longer in the same document, they display the missing "-PAGE-" placeholder instead.

To prevent this from happening, and prevent the automatic updating, you can select the whole TOC in Nisus Writer and choose the menu Tools > Automatic Content > Convert To Fixed Content.

[Nikolai]

I'm facing the same problem Hamid and Rajam described. When I use the print dialogue or export as PDF, the layout gets messy. Page numbers increase and random blanks occur.

I've been able to successfully use the workaround detailled above: If I turn widowing and orphaning-control off, everything is fine. But this should really only be a workaround...

Thanks for your consideration.

[martin]

I've been able to successfully use the workaround detailled above: If I turn widowing and orphaning-control off, everything is fine. But this should really only be a workaround...

Absolutely. Well, I think we have a handle on getting this bug fixed, but of course we'd like to make sure we cover all the cases. If you don't mind sending us your document (via the menu Help > Send Feedback), we'd be happy to have another test case. If your document is sensitive, we can promise to destroy it after we test, or you could scramble the content before you send it using our redaction macro. Thank you for your help and understanding!

[kstephens]

I submitted a document via Send Feeback some time ago with what I am sure has the same problem (Report ID 68306). My solution at the time was to generate a PDF via NWP 1.4.1 (not 1.4.2). I have since seen the same problem with another much longer document written by a friend of mine. I saw all the same issues: incorrect page numbers in the TOC after PDF/print, regenerating the TOC several times to get it right, repagination of the document, etc., all related to interaction between footnotes and widow/orphan control. I would be happy to resend my document and (with permission) the document which my friend wrote.

I am also sure this is related to the problem reported in this thread: http://nisus.com/forum/viewtopic.php?f=18&t=4517

[martin]

I saw all the same issues: incorrect page numbers in the TOC after PDF/print, regenerating the TOC several times to get it right, repagination of the document, etc., all related to interaction between footnotes and widow/orphan control. I would be happy to resend my document and (with permission) the document which my friend wrote.

If you could do that, we would appreciate it. We'd like to make sure we get this solved for good, and for all documents where the problem might occur. Thank you!

[kstephens]

I submitted several documents via "Send Feedback," report IDs 71830 and 71831, with descriptions of the behavior I am seeing, the steps I followed, and the PDFs which resulted at various stages. I am more than willing to be a test case supplier / guinea pig / beta tester for solving these problems, now that I have a tiny treasure trove of affected documents.

[martin]

Thank you very much for the reports/files kstephens. We'll be in touch privately.

[mbbntu]

I've been having the same problem. Unfortunately, turning off widow and orphan control is not really an option for me. I think part of the problem in my case is that I have a lot of shortish paragraphs with a title above them, and title and paragraph need to be kept together. The net result is that I get completely blank pages inserted into the document when I export to PDF. Sadly, the only option for me at the moment seems to be to use an old version of M$ Word (shiver), or Mellel -- I have to submit the document in a couple of days. I hope you get the problem solved.

Best wishes,
Martin.

[DanielNYU]

What is the status of this issue? I am having the same problems and am very, very frustrated. NWP 2.0.2

I finally generated a .pdf that is an accurate copy of the NWP document, but this involved the widow/orphan workaround. This is really inexplicable, though this works for me.

Has anyone had success converting the NWP doc to a Mellel doc and resolving this issue?

Daniel