PDF: Add an empty page only on odd pages

[ptc-1698327]

Hi everyone!

I'm using Arbortext PE to create PDFs, and in a special case I'd like to have certain elements start on an even page only (the left hand side, so to speak). For that to work, I added a function that would create a page break that should kick in if the last entry was created on an even page aswell, therefore creating an empty page on the next odd page so that those certain elements would now land on an even page again. Additionally, I want to avoid creating new page sets on their own (which would in turn be specifically designed to only begin on such even pages) for performance reasons.

Specifically, that should work in XSL:FO and I tried to use an fo:block withbreak-before="even-page" (and, as explained before, avoidforce-page-count="end-on-odd" in the page-sequence). This works only partially: it creates either 1 new page (as intended), or 2 new pages instead of 0 (ie. if the document would end on that page anyways and no empty page is needed). If I had used the force-page-count, it would work as intended, but this is not applicable here.

Can anyone think of a better way to approach this?

On the another hand: is that a feature in the PE or a bug? Is it really supposed to create 2 pages instead of 0?

Thanks in advance for any of your input!
Martin

[bibach]

For starters, which version of PE are you using? Are you creating
your XSL-FO stylesheet by hand, or using a tool, such as Styler?

I'm not completely clear on your goal, here. When you say you want
these certain elements to always start on an even (left-hand, or
verso) page, do you mean that there should always be a break before
the element, so it starts at the top of an even page, or it should
start in the middle of the current page, if that page is even?

When you say that it generates 2 new pages, do you mean it ends the
current even page, generates a blank odd page, then puts the content
of the element on a new even page? Or, does it generate 2 blank
pages? Are there particular circumstances under which this occurs?

-Brandon 🙂

[ptc-1698327]

Hey Brandon! Thanks already 🙂

We're using 5.4m070 and want to switch to 6.0m010 soon. The stylesheets are XSLT 2.0 stylesheets producing FO output, created by hand.

I think I messed something up in the explanation. Those elements (mostly graphics) should always start on an ODD (not even) page, the right hand side. Those elements always need to be the first to appear on that site.

In order to create such a thing, FO allows for a page break to force elements to start on an odd page, which is what we want. But the problem is what it now actually generates.

There are practically 2 possibilities: the content before those certain elements either end somewhere on an odd page, or on an even page.

- if the content before ends somewhere on an ODD page already, we're actually fine: the "special" page break works, one single empty page is created (which is then on an even page), and the certain element/graphic then lands again on an odd page. So all is fine.

- if the content before ends somewhere on an EVEN page, there is no empty page needed: there should a simple page break, and the graphic automatically should land on the next page now, which is an odd page. But instead of creating 0 empty pages, the PE creates 2 completely empty pages, and THEN inserts the graphic. The content does correctly land on an odd page, but those 2 empty pages in between are unintentional.

Sorry I wasn't clear enough, if you need further info: anytime. 🙂

In Reply to Brandon Ibach:

For starters, which version of PE are you using? Are you creating
your XSL-FO stylesheet by hand, or using a tool, such as Styler?

I'm not completely clear on your goal, here. When you say you want
these certain elements to always start on an even (left-hand, or
verso) page, do you mean that there should always be a break before
the element, so it starts at the top of an even page, or it should
start in the middle of the current page, if that page is even?

When you say that it generates 2 new pages, do you mean it ends the
current even page, generates a blank odd page, then puts the content
of the element on a new even page? Or, does it generate 2 blank
pages? Are there particular circumstances under which this occurs?

-Brandon 🙂

[ebenton]

Does anyone know if PTC has a published list of claimed benefits or advantages of the 64-bit version Arbortext Editor 6.0 over the 32-bit version? Or is it just a repetition of the Microsoft list of benefits for 64-bit Windows 7 over the 32-bit version?
A URL for this would be nice...

[bibach]

I tried to recreate your issue in 5.4m050. I had Editor create a new
XSL-FO document (there's a DTD for it that you can browse to under the
"doctypes" folder of your Editor installation) as a starting point. I
wrapped this up in an XSLT transform and added template rules for
"para" (just an fo:block with space-before and space-after of 12pt)
and for "image" (which was really just a paragraph in my input, and
got an fo:block with break-before="odd-page").

I created a free-from XML document with some "para" elements, then an
"image" element. A print preview showed the "image" starting at the
top of page 3, with page 2 blank (except for the page number). Adding
enough "para" elements to fill the first page and part of the second,
the "image" still started on page 3, with no blank pages.

When I've run into cases like this, I find it very useful to make
copies of the document and transform, then start cutting them down
until I have the smallest possible setup that still exhibits the
problem. Often times, the problem will disappear somewhere during
this process and then it just becomes a matter of backing up a few
steps (save lots of interim versions as you cut it down) to determine
what part you removed that fixed the issue.

Feel free to check back if you cut things down as far as you can and
still have the problem or if you've narrowed it down but don't know
why a particular configuration is still showing the problem.

-Brandon 🙂

[GarethOakes]

Come on Ed, everyone knows 64 bits is better than 32. Why? The number is
bigger! 🙂



-G

[ebenton]

I guess it's like in the Spinal Tap movie, where the amplifiers go up to 11 instead of 10. "It's one higher now, innit?"

[ptc-1698327]

Hey!

That's awesome, thanks Brandon and all the readers for your effort 🙂

With some more tweaking, it really did work that way. A colleague of mine discovered, that with

break-after="even-page"

instead of before/odd those unnecessary pages were gone.

There's one problem with that though: in the full-size project the problem persists, even though in a different matter. What we're trying to do (in addition to the blank page) is that every page has its current page number on it. Well, so far, so good and simple.

But, if there is a blank page on the next page, the page number of the blank page has to be also included in that (previous!) page; for instance, content ends somewhere on page 5, page 6 is a blank page, because of our tweak. While on page 4 the footer has to show something like "Page 4", the footer on page 5 needs to read "Page 5/6", while the blank page stays completely empty.

For that to work, my current solution needs some kind of ID on the blank page (which is of course some kind of a contradiction); what I did before (which seems to be the "best" solution with those 2 blank pages; otherwise, their would be more) was:

<fo:marker<span> marker-class-name="emptymarker{generate-id()}"><fo:inline>/<fo:page-number-citation<span> ref-id="empty{generate-id()}"/></fo:inline></fo:marker>
<fo:block<span> break-before="odd-page" id="empty{generate-id()}"></fo:block>

Because I don't know beforehand if there's going to be a blank page, I need to put that at the end of pretty much any page-sequence. Now, because of the break-before, an empty page should be added - but only IF NEEDED. That fo:block with the non-breaking space and the "emptySomethingId" actually seem to be on that blank page now - I know that, because the retrieve-marker points to the blank page. Now, when I retrieve the page count for the footer in the static-content:

<fo:page-number/>
<fo:retrieve-marker< span="> retrieve-class-name="emptymarker{generate-id()}" retrieve-boundary="page-sequence"/>

All seems fine if an empty page was needed ("Page 5/6"); BUT, if there was actually no need for a blank page to be added, then two get inserted instead and I get something like "Page 4/6". If I wouldn't print a non-breaking space, the block with the ID would simply move forward to the next (or previous) page-sequence, showing "Page 4/1". What I want is "Page 4/4" and no empty page. (I don't have that retrieve-marker for even pages, but that's what it should show ;))

If i use the method that works without those blocks, I get 3 or 2 pages instead of 1 or 0 pages. The one posted here adds 1 or 2 pages.

In short - the break-after even-page does actually work, but not with the addition of those page markers and blocks.

Maybe there's an easier way to get that page number or somehow work around the page insertion problem, but I didn't manage to find that myself 😞

Thanks again so much for your comments! 🙂

Martin

In Reply to Brandon Ibach:

I tried to recreate your issue in 5.4m050. I had Editor create a new
XSL-FO document (there's a DTD for it that you can browse to under the
"doctypes" folder of your Editor installation) as a starting point. I
wrapped this up in an XSLT transform and added template rules for
"para" (just an fo:block with space-before and space-after of 12pt)
and for "image" (which was really just a paragraph in my input, and
got an fo:block with break-before="odd-page").

I created a free-from XML document with some "para" elements, then an
"image" element. A print preview showed the "image" starting at the
top of page 3, with page 2 blank (except for the page number). Adding
enough "para" elements to fill the first page and part of the second,
the "image" still started on page 3, with no blank pages.

When I've run into cases like this, I find it very useful to make
copies of the document and transform, then start cutting them down
until I have the smallest possible setup that still exhibits the
problem. Often times, the problem will disappear somewhere during
this process and then it just becomes a matter of backing up a few
steps (save lots of interim versions as you cut it down) to determine
what part you removed that fixed the issue.

Feel free to check back if you cut things down as far as you can and
still have the problem or if you've narrowed it down but don't know
why a particular configuration is still showing the problem.

-Brandon 🙂