[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: Andrei Bondarenko <abacus@xxxxxxxxxx>, "FrameSGML List" <FrameSGML@xxxxxxxxxxx>, "Free Framers" <framers@xxxxxxxxx>
Subject: Generating a List of Effective Pages (was Running H/F) (Long)
From: Dan Emory <danemory@xxxxxxxxxxxx>
Date: Tue, 30 May 2000 03:23:14 -0700
In-Reply-To: <LYRIS-25280-17465-2000.05.29-21.53.58--danemory#primenet.com@lists.frameusers.com>
References: <3932D9DB.541C7775@home.com><3932D9DB.541C7775@home.com>
Sender: owner-framers@xxxxxxxxx
At 08:56 AM 5/30/00 +0400, Andrei Bondarenko wrote: >Hello Richard, > >The problem is that I need to collect so-called "List of Effective >Pages", one columns of which is the date of specific page revision. This >date is filled by "Running H/F #". And I have to extract the value of >"Running H/F #" variable for each page in document. And I must do it >with Frame Development Kit. ============================================ 1. ANALYSIS OF THE PROBLEM I suspect it would be quite difficult (if not impossible) to generate a List of Effective Pages (hereafter called a LOEP) using the FrameMaker FDK. to extract it from the individual page values of the running header/footer variable. Here's an alternative method you might try. First, I assume that the LOEP has the following form: Page No. Revision Date I assume that all pages in the initial issue of the book would have the word "Original" for the revision date, that, in the first revision to the book, all pages where changes are made will have the same date, all pages changed in the second revision will have the same date but that date differs from the date for the pages changed in revision 1, and so on up to the most current revision. Let's assume that the page numbers run consecutively from the beginning to the end of the book (if this is not the case, I have a modified solution discussed at the end of this treatise). I also assume that, if a change to a page causes some text on that page to overflow to the next page, all of the overflow text will appear on a new page of its own (a point page). That is, the overflow text is not allowed to overflow into the following original page, which must remain exactly as it was before the overflow occurred. Consequently, if the page preceding the new point page was page 52, the point page will have page number 52A, and page 53 will be the unaffected page that followed page 52 before the point page was added. If that is the way it must be done (and that's the only way I know of that it can be done if the LOEP is to have any useful purpose), then you are confronted with the fact that the page numbers in the running footer cannot be derived from FrameMaker's system variable, Current Page#. So, if there are going to be point pages, you must find some other way to produce page numbers in the Running Footer throughout the book. You will also use this new source of page numbers to generate a LOEP without resorting to the FDK. 2. DESCRIPTION OF THE METHOD The method described below will allow you to produce a LOEP by generating a List of Paragraphs (LOP). However, how you do this gets complicated because you must find a way to deal with problems such as point pages. There is a way to produce point pages in FrameMaker, using a "feature" known as "Freeze Pagination". This feature, however, is undocumented in V5.5 and up, and has messy problems of its own. More relevantly, however, it doesn't provide any solution to generating an LOEP. So, I discard Freeze Pagination as part of the solution. A. Variable Definitions First of all, you must set up a user-defined variable for the original issue, and a new user-defined variable for each revision. The variable for the original issue has the value "Original", and the variable set up for each revision has a date value (e.g., 5/29/00). Once such variables have been set up, they should never be changed. Each time you start a new revision, you must create a new variable for that revision. B. Special Paragraph Tags You're going to have to use an autonumbered (arabic nunber) paragraph tag for this purpose, and this paragraph tag will also be the source of the page number in the LOEP. You're also going to have to use another autonumbered paragraph tag for point pages. Finally, a third autonumbered (roman number) paragraph tag will be required if the front matter in the book uses roman numeral page numbers. In addition to their autonumbers, these paragraph tags must have the following attributes: 1. They must be small and invisible. 2. They must force a page break, so that they will always appear at the top of the page. 3. Every single page in the book must have one and only one of these paragraphs. You must never allow two or more of these paragraphs to appear on the same page. Let's name these three paragraph tags as follows: ArabicPage = the one which produces non-point page, non-roman, arabic page numbers PointPage=the one which produces combination arabic/alpha page numbers for point pages. RomanPage=the one which produces lower-case roman page numbers for front matter. Now, here is how the autonumbering specifications for these pages must be declared in the Numbering panel of the Paragraph Designer: The ArabicPage para tag has this autonumber: P:<n+> < =0> The PointPage para tag has this autonumber: P:<n>.<A+> Notice that the second counter in the autonumber chain for ArabicPage resets the point page counter to zero, thus point pages always begin with n.A The RomanPage para tag has this autonumber: R:<r+> In addition, for each of these para tags specify the following in the Paragraph Designer: a. Under Pagination set Start to Top of Page. b. Under Default Font set the Size to 2.0pt (the minimum allowable size), and set the Color to White. This makes the content invisible. NOTE: The series labels P: and R: must be unique. Never use those series labels in the autonumbering specification for any paragraph tag other than ArabicPage, PointPage, and RomanPage. C. Running Header/Footer Variables Now, to get the page numbers and revision date into the running header/footers, insert into the applicable running header/ footer variable: <$paranumonly[ArabicPage,PointPage,RomanPage]> to produce the page number, and <$paratext[ArabicPage,PointPage,RomanPage]> to produce the revision date. D. Generating the LOEP The LOEP is produced by generating a List of Paragraphs (LOP) in which only the ArabicPage, PointPage, and RomanPage paragraph tags are included. On the LOP reference page, set up each of the three paragraph tags (ArabicPageLOP, PointPageLOP, RomanPageLOP) identically, as follows: <$paranumonly><TAB><$paratext> Where <TAB> means to insert a tab character, using the Paragraph Designer to set up the tab stop. 3. THE PROCESS When the original issue of the book has been finalized, determine where the page break should be on each page. You should try to leave spare space at the bottom of each page (at least 3 or 4 lines if possible). This means there will be no page breaks in the middle of paragraphs. Then, you insert the applicable paragraph tag (either ArabicPage or RomanPage, because there won't be any point pages yet) at the top of each page. Next, with the cursor in the inserted paragraph, you insert the predefined variable Original. NOTE: By turning on feathering, it should still be possible to make the text on each page go all the way to the bottom of the text frame, even though each page is short a few lines. When you've done all this, all the page numbers are set in concrete. The only place non-point pages can be added is at the very end of the book (or, if page numbering restarts at 1 in each chapter or section, at the end of a chapter or section). Any page added anywhere else must be a point page. What this means is that the content of page 72 of the original issue will continue to be on page 72 in all subsequent issues. Thus, if page 72 never gets changed in subsequent revisions, the LOEP will show that page 72 is Original (i.e., has never been revised). And if Page 73 was Original up to revision 6, when it was first changed, the user can compare the LOEP in his current version of the book with the LOEP in the new revision 6 to see if there has been a change. That's the whole purpose of a LOEP. Because point pages are used, pages 72 and 73 retain their content identity throughout the life of the book (or at least until it is reissued, which usually occurs when too many point pages have accumulated). Each time you start a new revision, clear all previous change bars, then turn on Automatic Change Bars. This will allow you to identify all pages that are changed in the new revision. Next, create a new Revision variable, and enter the revision date as the value. Wherever you find a page with a change bar, put your cursor into the ArabicPage, PointPage, or RomanPage para tag at the top of the page and double-click it to open the Variable dialog, which displays the old revision date (or Original). Apply the new variable, and click Replace. The revision date of the page has now been updated, and will appear in the running header or footer. If the changes to a page produce a page overflow, insert a PointPage paragraph at the point where you want to force the page break, such that it will appear on a line immediately following the end of a paragraph. Insert the variable for the new revision into the text of the PointPage paragraph. 4. UNDESIRED CONSEQUENCES. As long as you have no point pages, the page numbers produced in the running footer by the running header/footer variable having the content <$paranumonly[ArabicPage,PointPage,RomanPage]> should be identical to what would have been produced if the Current Page# variable had been used instead. However, once you've inserted point pages, the page numbers will no longer agree with the page numbers known to FrameMaker, thus Tables of Contents and indexes, as well as cross-references that include a page number, will be incorrect. If you avoid cross-references with page number references, and there is no requirement for an index, and only the Table of Contents must be fixed manually, the problem is manageable, otherwise it is not. 5. IF PAGE NUMBERING RESTARTS AT 1 WITHIN EACH CHAPTER: My assumption at the beginning was that page numbers (excluding roman numeraled front matter) run consecutively from the beginning to the end of the book. If, instead, page numbers restart at 1 within each chapter, and the page numbers are prefixed with the chapter number, then the autonumbering scheme for the three paragraph tags (ArabicPage, Point Page, and RomanPage) needs to be changed. You'd have to put the counters for the ArabicPage and PointPage paragraphs at the end of the counter chain that contains the chapter autonumber. Let's suppose the existing counter chain that includes the chapter number is as follows: H:<Chapnum><head1><head2><figureno><tableno> You'd change it to: H:<Chapnum><head1><head2><figureno><tableno><ArabicPage><PointPage) Where: the autonumber specification for Chapnum would be: H:<n+>< =0>< =0>< =0>< =0>< =0>< =0> (resets all counters, including the 2 new ones) the autonumbering specification for ArabicPage would be: H:<n>-< >< >< >< ><n+>< =0> (producing a page number such as 1-1) and the autonumbering specification for PointPage would be: H:<n>-< >< >< >< ><n>.<A+> (producing a page number such as 1-1,A) ==================== | Nullius in Verba | ==================== Dan Emory, Dan Emory & Associates FrameMaker/FrameMaker+SGML Document Design & Database Publishing Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com 10044 Adams Ave. #208, Huntington Beach, CA 92646 ---Subscribe to the "Free Framers" list by sending a message to majordomo@omsys.com with "subscribe framers" (no quotes) in the body. ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **