At 2010-08-18 01:15 +1200, Trevor Nicholls wrote:
I have an xsl-fo stylesheet which successfully uses different page-masters
to produce a document with cover sheet, contents, chapters and index, with
headers and footers on appropriate pages. Now I have a requirement which
needs to introduce an additional level of sophistication and I'm not sure
how to do it.
One page master is currently defined as
<fo:simple-page-master master-name="Std-page"
xsl:use-attribute-sets="page.dim">
<fo:region-body xsl:use-attribute-sets="page.body" />
<fo:region-before extent="1cm" />
<fo:region-after extent="1cm" />
</fo:simple-page-master>
and it is used with an <fo:static-content flow-name="xsl-region-before"> to
format a header, a complementary <fo:static-content
flow-name="xsl-region-after"> to format a footer, and an <fo:flow
flow-name="xsl-region-body"> to display the main page content.
I would like to create a variation of this format in which the footer is of
unknown size, but its content, while formatted top down, is aligned bottom
up. I'm sure this is trivial
It isn't ... region extents are not elastic. You have to know ahead
of time. There is no feedback loop from the FO processor to the XSLT
processor, and there is no contingency semantic in XSL-FO to set to
accommodate this.
but I can't seem to find the magic that will do
it. The page will have content aligned top and bottom, with a variably-sized
gap in the middle. I suppose this is the kind of placement which footnotes
at the end of a chapter would have - but these are not footnotes.
Can somebody point me in the right direction (sorry, no pun intended)
please?
In one project I was on the after region was between one line and 10
lines long based on the content. I was obliged to estimate, my XSLT
stylesheet logic, how much room *might* be needed by the FO
processor. I erred on the heavy side (for example, in one case nine
lines of room were made available for only eight lines of content) so
as to avoid the situation where the region's content overflowed the region.
I based the calculation on the character count and page width, which
of course doesn't accommodate character width for a proportional
font, but does err on the heavy side which is why I was assured there
would be no overflow. I just wasn't assured there would be no wasted
white-space on the page.
It isn't precisely calculable ... you don't know what H&J the
processor is using nor the precise font metrics needed to do the arithmetic.
You aren't missing anything. I hope this helps.
. . . . . . . . . . Ken
--
XSLT/XQuery training: after http://XMLPrague.cz 2011-03-28/04-01
Vote for your XML training: http://www.CraneSoftwrights.com/s/i/
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--