xsl-list
[Top] [All Lists]

Re: [xsl] flexibly sized region after

2010-08-17 08:29:11
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>
--~--

<Prev in Thread] Current Thread [Next in Thread>