Creating a Table of Contents for printing

[nochoice]

I have a large HTML document (updated often) with a large Table of Contents (that changes often as well). My clients frequently print this document instead of viewing it on their computer. Unfortunately, once it has been printed the table of contents is useless because there are no page numbers (too bad technology is not advanced enough to allow hyperlinks to work on paper).

Is there a script I can use to create a table of contents with page numbers for printing. It can be attached to a print button or anything else. Any suggestions........

It has to be dynamic (i.e. I don't want to enter page numbers every time I modify the document, it's over 200 pages!)

 

[EdwardMartinIII]

Have you considered making it a PDF that they can download? You can also maybe make it into a Word document, if you know the typical result is a printed document.

Cheers,


Edward

"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door

 

[nochoice]

I don't actually send the HTML to my clients, I convert it to a PDF first. I don't want to send it as a word DOC because it can be edited.

I need the original file to be HTML because not every client gets the full document and I breakup the document using a script. This is why I need the T of C to be easily created using a script. I don't want to make a new document table of contents for every client. I click several check boxes hit submit and my script creates a customized document. What I was hoping to do was send the PDF along with a hardcopy to my clients.

 

[EdwardMartinIII]

So you have, as a root document, an HTML page.

Someone (you or the user) selects what parts they want in their own personal version of the document via a series of checkboxes. The server uses these selections, prepares a PDF, and serves the document to the client machine. The end-user then typically prints off their own custom book.

This book has a table of contents that specifies page numbers and you want those page numbers calculated on-the-fly.

The tricky part is that one user might print up the whole 200-page book, in which case the pages are numbered 1-200, but the next user might decide to print only chapters 1 and 20 -- a total of 3 pages -- and the pages must be renumbered such that they're sequential.

Interesting.

This is why so many technical manuals don't bother with page numbers, you know. They use such references as Part, Chapter, Section, Paragraph, etc. Technical Manuals change all the time and in order to prevent Unspeakable Madness, a hierarchical pagination is used. You don't want Unspeakable Madness.

Have you considered going that route instead of sequential Arabic page numbers?

That way, you don't have to recalculate every time, just have absolute "addresses" for each atomic piece. "Replacing the head gasket" will always appear in Part 4: Chapter 8: Section 3 and will always be in the right order whether they print the whole Raze-Your-Car manual or just the Rebuild Your Engine part.

Likewise, your index can be similarly modified.

Cheers,


Edward

"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door

 

[nochoice]

I hadn't thought of that idea.

Unfortunately, it still doesn't work for my application. The documents I'm creating are being given to commissions, which have strict guidelines as to how documents are formatted. Each page must have a page number in the lower right hand corner.

What I considered was breaking the files into individual pages and creating the document from 200 single page files. This, however, is far too time consuming, and not flexible enough.

 

[EdwardMartinIII]

Do the page numbers have to be adjacent to each other, or can you skip, say, a bunch of numbers? Here's my silly suggestion: assign each "section" a number from 000 to 999 (or somewhere in between). Then, inside each section, number the pages from 001 to 999 or so. So, when you put all the sections (say, twenty sections, each of five pages) in order, the page numbers are
000001 (000 for section 1, 001 for page 1)
000002
000003
000004
000005
001001 (001 for section 2, 001 for page 1)
001002

and so on...

However...

I'm not as familiar with the PDF and postscript format as I would like to be, but it seems to me that another way of solving this would be to build a generic document. It has headers and footers as you need, and they apply specifically to the document. The footer, of course, includes the page count of the document.

As this is simply a container, the initial page count is 0.

Make each of your chapters (or however you're dividing your book) such that they contain no header or footer information, just content. But, they must also contain the necessary page breaks and section headers and titles and whatnot.

So, on the server side, you populate your container with the necessary pieces. The container properties include page count.

Okay, in theory, this idea is cool.

In practice, it depends on a few things, such as can PDF support a "container" which can be populated? Can PDF support a piece of dytnamic data in a document? Can a PDF document report its page count to an independent entity (such as your server app). Certainly you can build a postscript page and then pass it through Distiller, but my impression of your parameters is that you would need an online version of Distiller. This is totally possible, but may not be practical for you. And again, can Distiller do a piece of dynamic data such as "NOW how many pages do I have...?"

Another silly option is to figure out what combinations are most likely to occur and (gulp!) post individual PDFs of those on the website. Give 'em a choice of which documents they want. If you need more, hire an intern to make 'em. This can become a support nightmare, of course.

I'm afraid to say that I'm at my limit of knowledge on this one.

Hope that helps at all.

Cheers,


Edward

"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door

 

[jstreich]

Personally, this sounds a little too complicated for a script... I, personally would use Java, and iText to build a custom publishing aplication that meets these needs. Use a container to represent the document, as pages are added to the document, the size increses, the next section will be size + 1, and that should be written to the contents page (after the strin(link?) and then a series of tabs or .'s), latter to be prepended to the front at the END of publication. Then write out both the HTML and the PDF with a single button. Now, the source document would end up being either HTML or PDF content.

Actually, the simpler answer... Don't use scripts to piece the thing together, use Word, and save as HTML, and then use a PDF printer driver. Why re-invent the wheel.. granted that MS Words HTML output isn't very clean, but it works, sorta.

 

[ChrisHunt]

I'd do it in Word. You can store each section of the document in a seperate file, then build a number master documents, each with an automatic TOC and the relevant section files. Produce a PDF file from each of these and you're on your way. Search the Word help file for "Master Document" for more information.

If you're running on a Windows server you should be able to generate these documents on the fly using OLE (though don't ask me how!). If not, you'll have to pre-generate all the possible PDF files - this may produce a lot of files: n sections will mean 2ⁿ-1 files - but you can automate the generation process with a Word macro.

An example. Say my document has three optional sections. I would generate seven pdf files:

doc1.pdf
doc12.pdf
doc13.pdf
doc123.pdf
doc2.pdf
doc23.pdf
doc3.pdf

A script on the web site could pick the right pdf to send depending on whether the user selects 1, 2 or 3, or any combination of them (I'm assuming they have to have at least one ssection).

-- Chris Hunt
Extra Connections Ltd

http://www.extracon.com

The real world's OK for a visit, but you wouldn't want to LIVE there!

 

[nochoice]

Thanks for your help,

The word approach looks best, least time consuming and easiest. I am going to write a macro and see how that turns out.