Removing blank back-up pages

[JasonBuss]

Hello all, I have an odd issue, using Editor/Print Composer 5.4 M100 with FOSI stylesheets.

We developed our FOSIs to create PDF print masters, so of course, blank backing pages were always a necessity.

I have been working a project to generated hyperlinked/bookmarked PDFs for web display. With these PDFs, it has been requested that all blank pages be removed.

The documents I am producing contain chapters, which contain a list of effective pages, and table of contents, followed by one or more ATA-style pageblocks.

I would have thought this would have been as easy as removing the blank page specs from my pagesets, and setting startpg="next" instead of "recto". This worked just fine for the LEP, the TOC, and the chapter title page. But the pageblocks with an odd number of pages still generate a blank.

The only difference I could see in e-i-c for the LEP and TOC, and the e-i-c for the pageblock is that the LEP/TOC e-i-c had the newpage declared in the charsubset of the e-i-c, while the pageblocks selected from two different newpage elements by way of an attribute rule.

However, when I negated the attribute rules and put a new page directly in the charsubset, I am still getting blank pages.

Anyone have an idea of what I'm missing here? I can't help but think I'm overlooking something small (but probably obvious, I've been tooling with this FOSI for a while now).

Thanks,

-Jason

[ebenton]

I have had a similar problem in the past when there was an e-i-c that always occurred on the first page of a chapter (such as a <title>) and this e-i-c- had the startpg="recto".

[JasonBuss]

I considered that, backed-up my FOSI, and grepped all my startpg to "next", and it didn't work.

Now, I have noticed one curious thing. My blank pages are carrying a header and footer, like they are still being formatted with the pageset for the pageblock documents, it even increments the folio counter. I do have floats enabled for graphics, is it possible I'm running into an issue by allowing floats? Some of these documents don't contain a <graphic> element, and that's the only e-i-c that triggers the float.

[ptc-1908075]

What page models do you have for pageblocks?

Ignoring any rectobb, versobf, and blank pg page models, page models are typically set up with an opening recto page and then facing recto and verso pages such as this:

<rectopg>...<pagespec pgid="body.recto0"...&lt;/">
<rectopg>...<pagespec pgid="body.recto1"...&lt;/">
<versopg>...<pagespec pgid="body.verso1"...&lt;/">

Try adding an opening versopg that is the same as the opening rectopg:

<rectopg>...<pagespec pgid="body.recto0"...&lt;/"><versopg>...<pagespec pgid="body.verso0"...&lt;/">
<rectopg>...<pagespec pgid="body.recto1"...&lt;/">
<versopg>...<pagespec pgid="body.verso1"...&lt;/">

Then when next is specified, there is a versopg page model available.

Hope this helps!

Suzanne Napoleon
www.FOSIexpert.com
"WYSIWYG is last-century technology!"

[JasonBuss]

I had a quint with a recto and verso defined. I did set up a second quint for that pageset, but that didn’t seem to have any effect.

As far as I remember, you can’t set up a quint that doesn’t have a recto page.

[ptc-1908075]

The issue is whether you have an opening rectopg. If so, you need an opening versopg as well. 

In the following case, when next is specified, it will always call the opening rectopg page model, inserting a blank page if necessary because no opening versopg page model is available. body.recto0 will be used first, then body.verso1, then body.recto1.

<rectopg>...<pagespec pgid="body.recto0"...&lt;/">
<rectopg>...<pagespec pgid="body.recto1"...&lt;/">
<versopg>...<pagespec pgid="body.verso1"...&lt;/">

However, when an opening versopg model is also available, the formatter will call either the opening rectopg or the opening versopg depending on which is appropriate, and a blank page will not be inserted. body.recto0 could be used first, then body.verso1, then body.recto1. Or body.verso0 could be used first, then body.recto1, then body.verso1. 


<rectopg>...<pagespec pgid="body.recto0"...&lt;/">
<versopg>...<pagespec pgid="body.verso0"...&lt;/">
<rectopg>...<pagespec pgid="body.recto1"...&lt;/">
<versopg>...<pagespec pgid="body.verso1"...&lt;/">

Note that in the first case, you could define an opening versopg, but if the page call always specifies recto, the versopg page model will never be used, so it isn't included. In the second case, either opening page model can be used as the next page. 

Suzanne



>----------
>>

[JasonBuss]

*SIGH*

I found the problem. Completely outside the scope of page sets (but it did help me fix a different issue, so not a total wash).

Do you ever look at some really old code and go “there’s no way I did something that silly. That couldn’t have possibly been me”, but know in the back of your mind it was so long ago that you’re not really sure.

Anyway, thanks folks…