[xep-support] Conditional Page Master Puzzle

From: W. Eliot Kimber (eliot@isogen.com)
Date: Mon Nov 04 2002 - 07:30:49 PST

[I originally sent this to support@renderx.com because of some
attachments. Here is my original message and David's response--E.]
In putting together a exercise for learning about conditional page
masters, I committed a subtle user error: specified "rest" when I meant
"any" in some of my conditional-page-master-reference elements. This had
the effect of leaving some pages with no available page masters. XEP
reported some of the instances where pages had no masters, but not all
of them. The spec clearly leaves fallback in this error condition up to
implemetnations, but I did find it useful that XEP reported the error
(it's a tough one to debug without that feedback) but I was surprised
that it didn't report all the conditions, I think, where no conditions
were met. I've attached the sample doc and formatted result. You'll see
that it consists of a bunch of one- and two-page sections, with each
section starting a new page sequence and forcing an odd starting page
number. The repeatable page master alternatives definition is shown below.

The mistake I made is that I specified "rest" for page-position on the
body-page-* and body-page-blank-* references, where I should have
specified "any". This mistake means that the second page of each
two-page section doesn't match any alternative:

1. body-page-first fails: page is not first
2. body-page-odd fails: page is not odd
3. body-page-even fails: page is last page in sequence, fails "rest"
condition (but XEP seems to be using this alternative)
4. body-page-blank-odd fails: page is not odd
5. body-page-blank-even fails: page is not blank

For the one-page sections (Appendix A and Appendix B), I do get a "no
page master" report (as shown below) and XEP doesn't create the page at
all (PDF goes from page 9 to page 11 with no page 10).

My question: why does XEP not fail when it looks like it should? XSL
Formatter does fail, but recovers in a way that I haven't figured out
the pattern for (also, when it fails to apply any master, it still
generates a full blank page, which may or may not be the better recovery
strategy, but it doesn't issue any warnings, which is definitely not good).




Here is the output from XEP:

(sequence [master-reference body-page-first](flow [page-number 1])
(static-content [page-number 1][page-number 2])
(sequence [master-reference body-pages](flow [page-number 3][page-number 4])
(static-content [page-number 3][page-number 4])
(sequence [master-reference body-pages](flow [page-number 5][page-number 6])
(static-content [page-number 5][page-number 6])
(sequence [master-reference body-pages](flow [page-number 7][page-number 8])
(static-content [page-number 7][page-number 8])
(sequence [master-reference body-pages](flow [page-number 9]
{!com.renderx.xep.cmp.NoPageMasterException: state: 74}
(static-content [page-number 9])
(sequence [master-reference body-pages](flow [page-number 11]
{!com.renderx.xep.cmp.NoPageMasterException: state: 74}
(static-content [page-number 11])
(sequence [master-reference body-pages](flow [page-number
13][page-number 14])
(static-content [page-number 13][page-number 14])
(generate [output-format pdf][page-number 1][page-number 2][page-number
3][page-number 4][page-numbe
r 5][page-number 6][page-number 7][page-number 8][page-number
9][page-number 11][page-number 13][pag
e-number 14]))


David Tolpin wrote:

> Eliot,
> XEP uses 'rest' alternative for the last page because of a general
> approach to a known last-page-does-not-fit problem.
> Imagine that at a certain formatted state, by applying 'rest' page-master,
> one finds out that the page is actually the last one.
> The page is then reformatted with 'last' page-master, and it may happen
> that the page's contents do not fit into that page-master. This means that
> the page, though last, cannot be formatted with 'last' page-master.
> This condition is chosen to be resolved by returning to the formatting result
> obtain before it was known that the page was last. The result you observe
> is the result of this resolution algorithm.
> It is correct that this particular case must be reported as error. Will
> do in a subsequent release.
> David

W. Eliot Kimber, eliot@isogen.com
Consultant, ISOGEN International
1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139
By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html

This archive was generated by hypermail 2.1.5 : Wed Dec 18 2002 - 08:41:28 PST