Thanks, that did it.
Ron, fop.extensions didn't; I assume because I'm using DB5 and need fop1.extensions instead.
Lesson learned: turn on the processor extensions whether I think I'm using them or not. XEP has shown no symptom of needing them, but I'll keep them enabled.
Reflection: developing against two processors keeps turning up issues that the tolerance of one would leave as a trap for me later. Annoyingly slow, but probably, like keeping my HTML markup valid, worth the trouble.
SJT
2008/8/26 Bob Stayton <>
You need to set the 'fop1.extensions' parameter to
1 when using FOP 0.9*. That will eliminate the error about xsl:region-body
'blank'.
Bob Stayton
Sagehill Enterprises
----- Original Message -----
From:
Stephen Taylor
To:
Sent: Tuesday, August 26, 2008 11:15
AM
Subject: [docbook-apps] An informaltable
that chokes FOP
The attached short article renders perfectly in XEP but breaks
FOP. The source of the problem appears to be my customisation layer: with XSLT
against just the XSL distribution, the formatters produce identical results.
Or — is the problem with FOP's support for informaltable? If I change
the informaltable element to a table element, both FOP and XEP again produce
identical results against my customisation layer.
I haven't so far
attempted any customisation of tables. Is there something I've written in the
customisation layer that affects the informaltable element? Or is this a bug I
should report to the FOP project, and if so, in what terms?
FO for both formatters produced by xsltproc from
docbook-xsl-ns-1.74.0
versions.xml validates against docbook-5.0/dtd/docbook.dtd
FOP reports: java.lang.IllegalStateException: Flow 'xsl-region-body'
does not map to the region-body in page-master 'blank'. FOP presently does
not support this.
Stephen
---------------------------------------------------------------------
To
unsubscribe, e-mail:
For
additional commands, e-mail:
