Re: [xsl] [xsl-fo] Flexible Region-before size

Subject: Re: [xsl] [xsl-fo] Flexible Region-before size
From: Geert Bormans <geert@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 29 Jan 2013 23:31:34 +0100
Thanks Ken,

I understand now that I have to do some trial and error calculation on the character count.
I was hoping to avoid that, but I think I can get that close enough.

I don't think I can change the extent on the static-content, can I?
Out of curiosity... did you use a different simple-page-master per potential number of lines?

I did think about abusing the header of a table, but I ran into some issues with that,
so I think I go for the estimated guessing approach



At 18:26 29/01/2013, you wrote:
At 2013-01-29 12:12 +0100, Geert Bormans wrote:
On my pages I have a region-before with some header information
(to be precise, there are 4 fields in a small table that servers as the page header)

One of the fields in this header can range from some 10 characters up to 128
At some point this field breaks onto the next line. When that happens, part of the second line becomes invisible
(outside the region-before extent)

My customer likes the layout (so the region-before extent should not be bigger on most pages by default)
but when the header overflows to the next line, then the extent should be made bigger

Is there a simple way to do that?

You have to make some estimates on your part, and your customer needs to accept that there will be edge cases when the height of the page content is not as big as it could be.

I was presented with your very situation when printing US Intelligence documents where the header is between 1 and 10 lines long: having 9 blank lines most of the time is totally unacceptable. Yet the security classification can vary and be very detailed, but often is very short. The project is described here:

I ended up calculating the region-before height by first determining the content belonging in the header and then doing a character count. I simply divided the count by a "generous" interpretation of the number of characters in a line, and set the region height accordingly. Granted, there were some times that the actual rendered length turned out to be, say, 5 lines and I had reserved 6, but because of how I calculated the line lengths, that rarely happened. I erred on the side of leaving a one-line gap, rather than losing content (especially a security constraint!) on the page.

And it is only an estimate, as there is no access through the specification to the font metrics. If you happen to have outside access to the font metrics of the font you are using, then you can perhaps have a very accurate calculation of how much room you'll need.

If you don't have a page number in the variable sized bit, you could try putting your entire content into a one-column table with a table header that repeats on every page. That header can have any number of lines. And in subsequent page sequences (or table groups you decide on) you can have a different number of lines in your table header as a pseudo-page-header. And if you are using XSL-FO 1.1 (which I couldn't in 2005), you can use retrieve-table-marker in order to mimic retrieving page markers.

I hope this helps.

. . . . . . . . . Ken

-- Contact us for world-wide XML consulting and instructor-led training Free 5-hour lecture: Crane Softwrights Ltd. G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx Google+ profile: Legal business disclaimers:

Current Thread