Pagination Issue: Removing White Space

[holosys]

If you were asked the simple question: "How do I remove blank pages?" you would likely answer: "Format | Page Layout | Pagination | Before Saving & Printing: Delete Empty Pages."

If you were asked a variation of that question: "How do I remove partially blank pages?" some might answer: "Huh?"

That's my question. I have this tendency to assume that a vacuum of information on the search engines means, sadly in answer to this question, "You can't remove partially blank pages."

Before you answer, here is what I'm specifically attempting to do with FrameMaker 9:

1)   I converted a user manual in Word 2007 to FrameMaker 9. The TOC contains several hundred headings (seven levels deep). Of course, the TOC includes chapters (heading1) at level 1, and topics (heading3 through heading7) for levels 2-7.

2)   I converted the text and graphics under each heading (heading1 through heading7) to separate FrameMaker 9 files. (Each heading and all child sub-headings are "topics" that describe part of the UI for a software product.)

3)   All of the converted FrameMaker 9 files were added to a FrameMaker 9 book. The TOC in this book is identical to the TOC of the original Word 2007 file.

Each of these headings is a separate FrameMaker 9 file representing a topic mapped to the UI:

CONSOLE MAIN SCREEN....................................... 63

Inventory Control..................................... 81

Intellectual Property............................. 82

Using the Intellectual Property Page......... 83

Viewing and Configuring................ 85

Configuring Filters.............. 87

View Settings.............. 88

4)   I have linked all these files to a project in RoboHelp 8, creating a RoboHelp master page to render the help topics with exact same headers/footers in the FrameMaker 9 file. Whenever I make changes to the FrameMaker 9 files, I can open RoboHelp 8 and compile a new help project for the UI. Sweet. (It works so well, as a matter of fact, that it’s worth the cost of the Adobe Technical Communications 2 suite!)

5)   For customers demanding a PDF version that looks EXACTLY like the previous PDF rendered in Word 2007, I print a PDF file from the FrameMaker 9 book for this user manual that looks almost exactly like the legacy PDF file rendered in Word 2007.

Why “almost” exactly?

As you may have guessed, if a topic ends with a paragraph at the top of the last page, there is blank space for the remainder of that page. Whereas in Word 2007, the next heading began immediately after the previous heading!

FrameMaker 9 only has a setting on the ‘Pagination’ dialog for eliminating blank pages, not eliminating partially blank pages.

I would like to render the PDF file, printed from the FrameMaker 9 book file, with each file in the book beginning on the line immediately after the preceding paragraph of the file before it in the book (unless the style such as heading1 dictates the line starts on a new page).

In some cases, the last page of a topic has just three sentences, leaving the rest of the page blank. It seems to me that to do what I’m attempting, the recursive effect of starting the next file after the paragraph on the last page of the previous file in the book, would be to reduce the PDF by several (or more) pages. This would require FrameMaker 9 to adjust the page numbering of the PDF file (which would no longer coincide with page numbering for the FrameMaker 9 book files).

This is no different of a problem than anyone with a book that contains 10 files (each file representing an entire chapter) would face. If a chapter ends with a page containing just three sentences, one would have to fiddle with the text to get those three lines to “bump” to the previous page. In the old days of technical writing, this typical pagination flaw was a thorn in my side. I had to print the document, and if the end of a chapter contained “orphaned” text (or even a small paragraph on an otherwise blank page) I had to reduce paragraph spacing to cause that rogue paragraph to bump to the previous page, eliminating the white space. I was kind of hoping that after almost three decades of computing, that basic problem was solved. In a small book with a dozen or less chapters, it’s not a real issue, but now that I have a book with several hundred files, I’m facing this dilemma for the first time.

Suggestions, anyone? (Thanks for your patience in torturing through this message!)

Message was edited by: holosys

Message was edited by: holosys

[FieryPantone]

If I've understood correctly, the nub of the problem is that FrameMaker will start outputting a new book-component on a new page. afaik, that's "just the way things are" and the way the book mechanism works. Pending more knowledgeable contributions, I'm wondering whether you might not be able to mimic the "assemble from components" behaviour with text insets. Also lurking seductively around my thoughts, unhampered by actually knowing anything about it, a more structured approach ‒ in my experiments with DITA so far, I've exploded chapters into topics and then reassembled them: but mostly, I admit, well outside FrameMaker.

[holosys]

Excellent ideas; Text Insets created through File Import eloquently solved the problem!

I created a separate book that I will use for rendering the PDF file for the user manual. In that book are files for entire chapters. In each chapter file are text insets for each heading file (which comprises an individual "topic" in RoboHelp).

Here is what I did:

1. Opened the book file containing cover, hundreds of topics and TOC, and Save Book As... [new book name] then delete all book files except for the cover and TOC.
2. After opening a new (blank portrait) FrameMaker 9 file, I applied all formats from my master stylesheet file.
3. Selected File | Import | Highlight the file | [Path\Name.fm of sequentially first FrameMaker 9 file in chapter] (select Import by Reference radio button) | Import. (The Import Text Flow by Reference dialog screen appears.)
4. Selected defaults (Body Page Flow: A (Main Flow) | Reformat Using Current Document's Catalogs | Automatic) and additionally selected Manual Page Breaks and Other Overrides (Under Reformat Using Current Document's Catalogs) then selected Import.
5. Moved the cursor to the end of the file. (This is important because the cursor is now positioned BEFORE the imported Text Inset, and the cursor needs to be positioned AFTER the imported Text Inset.)
6. Repeated above steps 3-5, selecting the file containing the next heading in the chapter, until the current file contains Text Insets for all topic files.
7. Save the file.
8. Add the file to the book as the first chapter.
9. Repeated above steps 2-8 until the book is populated with all chapters.
10. Update and print to PDF.

Problem solved: I obtained the desired results as per my original message in this thread.

The side question was asked as to why creating a separate FrameMaker 9 file for each heading and sub-heading (as described in my original message in this thread) is necessary. The answer is simply "budget" as the start-up company where I work wants to instantaneously generate a RoboHelp Flash Help project from the FrameMaker 9 book through linking FrameMaker 9 to RoboHelp 8, which is evidently a new function. Each heading and sub-heading of the user manual correlates to a UI screen or UI component. The User Manual was authored (before I arrived on the scene) with the intent of each heading and sub-heading in the User Manual TOC documenting a UI screen or UI component.

Therefore, instead of spending time creating a RoboHelp project in parallel, the company desired the elimination of costs associated with parallel development. Since the budget is non-existent for online help, pressing Help on any UI screen displayed a boilerplate screen instructing the customer to call customer support at a toll-free number, and a link to the PDF manual. Now, with minimal effort, the Help buttons are mapped to open the help topic for the corresponding heading in the user manual. Pressing Help opens the appropriate heading or "topic" and displays a TOC and search tabs as well (for full access to the documentation). This scheme requires little or no ongoing maintenance in RoboHelp 8 other than opening the help project, updating the links to FrameMaker 9, compiling the help project in Flash Help, and checking the help files in to Perforce for the nightly build.

Thank you once again for saving the day!

Message was edited by: holosys

[Van Kurtz]

From the point of view of creating just a FrameMaker book, I would not put each heading level in a file of its own. Typically, one puts the first level, say the chapter level, in one file along with all its subheadings. When a PDF is created, each chapter would begin at the top of the page, with there being partially blank pages only at the end of each chapter. If you were to want NO partially blank pages, then one would not create a book but have all the content in one file, which is probably what was done in Word.

That being said, I do not use RoboHelp, so I do not know what is required to output files for RoboHelp. Thus, I do not know whether each heading level MUST be in a separate file in order for RoboHelp to work correctly. If so, then I think Michael's suggestion of using text insets to create a "continuous" flow in FrameMaker may be what you need to do. Note that with text insets, you may have a problem getting all the cross-references to work as hyperlinks in the PDF file. To get around the latter problem, I suggest you look at InsetPlus from West Street Consulting.

[holosys]

As a side note in response to your comments on RoboHelp, I know technical writers who would not recommend this method because online help is often different from manuals. However, in this instance, the company's PDF user manual was constructed to substitute for context sensitive help. Instead of conveniently pressing "Help" the user was expected to download the PDF manual, find the relevant TOC entry, click on the TOC heading in the PDF and go to the topic that was intended to describe the UI screen in question.

On that basis, due to a tight budget, we opted to kill two birds with one stone.

I also realized that by constructing each FrameMaker 9 file in its own sub-folder hierarchy, I could store an "alternate version" of that file in the same folder (along with its linked graphics, reviewer notes, and other related info). That way if a situation occurs where the UI is described "differently" in the online help than in the PDF it's simply a matter of linking the help project to the alternate FrameMaker 9 file. That allows the alternate versions to have common text and graphics elements linked, while customizing the unique aspects of each version (online help vs. PDF manual).

It's not DITA, but it gets the job done within a budget. There's no point in my being a spoil sport, because if we stray outside the budget, game over.

Thanks for your suggestions!

Message was edited by: holosys