Thanks for posting this for me. Got a login so you didn't have to do the dirty work! 😃
Adepters, here's my problem:
Using Print Compose, I'm having trouble with pagesets not creating a "blank backing page" (rectobb) unless the page is followed by the start of another pageset. If any pageset is the last pageset in the document, Print Compose will end the document on a recto page. However, the same pageset will correctly end on a rectobb if it is followed by another pageset. Any ideas?
On Mon, Nov 21, 2011 at 1:10 PM, Joseph Migliore <-> wrote: > Using Print Compose, I'm having trouble with pagesets not creating a "blank > backing page" (rectobb) unless the page is followed by the start of another > pageset. If any pageset is the last pageset in the document, Print Compose > will end the document on a recto page. However, the same pageset will > correctly end on a rectobb if it is followed by another pageset. Any ideas?
First, a couple of questions to establish context. What version of Print Composer are you using? Are you authoring a FOSI by hand?
Now, to provide the best answer, it would help to know why it's important to have Print Composer produce the final page. What will appear on it? If it really is a blank page with no markings, then it doesn't seem that it would be important for it to be included in the composed document.
Using Arbortext 5.2. Not sure what version of Print Composer I have. Yes, we are developing a custom fosi for a MIL-STD delivery, which is why its important to have the pdf end on a verso page. Out mil spec deliveries are used for paper copy output and require backing pages for every page.
I used one of the prior suggestions regarding an ACL function but that only seems to work when the savetext has a literal conrule (i.e. <savetext textid="mytext.str" conrule="\2">. If I pass a stringdecl, the fosivar_value function doesn't return anything.
Thanks for taking the time to reply.
In Reply to Brandon Ibach:
On Mon, Nov 21, 2011 at 1:10 PM, Joseph Migliore @<-> wrote: > Using Print Compose, I'm having trouble with pagesets not creating a "blank > backing page" (rectobb) unless the page is followed by the start of another > pageset. If any pageset is the last pageset in the document, Print Compose > will end the document on a recto page. However, the same pageset will > correctly end on a rectobb if it is followed by another pageset. Any ideas?
First, a couple of questions to establish context. What version of Print Composer are you using? Are you authoring a FOSI by hand?
Now, to provide the best answer, it would help to know why it's important to have Print Composer produce the final page. What will appear on it? If it really is a blank page with no markings, then it doesn't seem that it would be important for it to be included in the composed document.
Print Composer is an integral part of Editor, so the version would be the same; 5.2, in this case.
I've done a fair bit of MIL-STD work, so I feel your pain. On that note, I realize that customer requirements might override reason, but if the blank verso is really blank (no "intentionally left blank" or other markings of any kind), does it matter if it's present in the PDF? I think most printers will produce a complete, double-sided sheet of paper, regardless.
One thing you might try (I had some qualified success with it, here) is to create a new <stringdecl> and populate it with a <savetext> in the <pageres> of each recto and verso page, setting it to empty on the verso pages and to a pseudo-element on the recto pages. The pseudo-element should trigger a new verso page. Add a <usetext<br/>placemnt="after"> to your document element to emit the contents at the end of the document, either doing nothing or triggering the final verso page, as needed.
You'll probably need to play with variations to consistently get the results you want. You might need to use a different page set than the one in use at the end of the document or you may need to generate a space inside the pseudo-element, in order to force the FOSI to actually generate the page. You may even need to have the pseudo-element (or the alternative page set it calls) generate the appropriate content to make the page appear as if it were a "blank" page, even though it has the single space as "content".
-Brandon
On Tue, Nov 22, 2011 at 9:30 PM, Joseph Migliore <-> wrote: > Brandon, > > Using Arbortext 5.2. Not sure what version of Print Composer I have. Yes, we > are developing a custom fosi for a MIL-STD delivery, which is why its > important to have the pdf end on a verso page. Out mil spec deliveries are > used for paper copy output and require backing pages for every page. > > I used one of the prior suggestions regarding an ACL function but that only > seems to work when the savetext has a literal conrule (i.e. <savetext<br/>> textid="mytext.str" conrule="\2\">. If I pass a stringdecl, the > fosivar_value function doesn't return anything. > > Thanks for taking the time to reply. > > In Reply to Brandon Ibach: > > On Mon, Nov 21, 2011 at 1:10 PM, Joseph Migliore > <-> wrote: >> Using Print Compose, I'm having trouble with pagesets not creating a >> "blank >> backing page" (rectobb) unless the page is followed by the start of >> another >> pageset. If any pageset is the last pageset in the document, Print Compose >> will end the document on a recto page. However, the same pageset will >> correctly end on a rectobb if it is followed by another pageset. Any >> ideas? > > First, a couple of questions to establish context. What version of > Print Composer are you using? Are you authoring a FOSI by hand? > > Now, to provide the best answer, it would help to know why it's > important to have Print Composer produce the final page. What will > appear on it? If it really is a blank page with no markings, then it > doesn't seem that it would be important for it to be included in the > composed document. > > -Brandon > > ----------
> Print Composer is an integral part of Editor, so the version would be > the same; 5.2, in this case. > > I've done a fair bit of MIL-STD work, so I feel your pain. On that > note, I realize that customer requirements might override reason, but > if the blank verso is really blank (no "intentionally left blank" or > other markings of any kind), does it matter if it's present in the > PDF? I think most printers will produce a complete, double-sided > sheet of paper, regardless. 😉
When we used to create the actual pages by hand and provide the camera ready copy we needed to make sure there were blank pages where needed to make it an even run.
In this case if they were composing by chapter (due to size), you would want to make sure the output had that last blank page so when you stack the chapters together the first page of the next chapter stays on the right instead of being on the left becasue the last blank was not produced.
On Wed, Nov 23, 2011 at 10:31 AM, Dan Vint <dvint@dvint.com> wrote: >> I've done a fair bit of MIL-STD work, so I feel your pain. On that >> note, I realize that customer requirements might override reason, but >> if the blank verso is really blank (no "intentionally left blank" or >> other markings of any kind), does it matter if it's present in the >> PDF? I think most printers will produce a complete, double-sided >> sheet of paper, regardless. 😉 > > When we used to create the actual pages by hand and provide the camera > ready copy we needed to make sure there were blank pages where needed to > make it an even run. > > In this case if they were composing by chapter (due to size), you would > want to make sure the output had that last blank page so when you stack > the chapters together the first page of the next chapter stays on the > right instead of being on the left becasue the last blank was not > produced.
Oh, I realize there may be very solid technical reasons for the final blank, though it wasn't clear from the description what they were, which could influence the choice of approach to solving the problem. The best software solutions usually derive from real requirements like "proper page stacking across multiple PDFs", rather than derived requirements like "even number of pages in each PDF" (with no clear justification) or, worse, "cuz someone said so".
Ultimately, though, given the PDF-as-a-route-to-paper context, I just couldn't resist the "half a sheet of paper... the front half" joke. 🙂
I, among others, have worked with DOD PDFs for a long time. The customer ALWAYS wants to know how many pages are in the PDF based on the LEP since every page is accounted for. The way to ensure that last page is properly accounted for, even though it's blank, is to add a "dummy" page that always prints one page at the end of the PDF. This single page will contain ONLY a space, always print, and because it is a 'new' pageset, will always close out the previous pageset.
We simply chop off the last page after the fact, but he internal numbers to the PDF always match, and always come out to an even number.
We do something similar, but that 'dummy' page contains the LARGE, blue legend, "REMOVE THIS PAGE". Helps assure that the page isn't overlooked for removal, even if the final review is cursory and superficial.
