Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xsl] FO 1.1 floating-page tables: is PSMI still needed?

From: "G. Ken Holman" <gkholman@-------------------->
To:
Date: 10/1/2007 5:55:00 AM
At 2007-10-01 12:48 +1000, Deborah Pickett wrote:
I should start by saying that I am familiar with Page Sequence Master
Interleave (PSMI) (http://www.cranesoftwrights.com/resources/psmi/).
Since FO 1.1 processors are rather thin on the ground, this is more of a
theoretical question.  I came away from reading the FO 1.1 spec not
knowing if it supports this.

There is no new functionality in FO 1.1 to replace PSMI.



But new functionality in some processors is satisfying the use case 
in the exemplar for PSMI such that PSMI isn't needed for that 
particular use case.  I note that Antenna House successfully 
paginates a rotated block-container whose length overflows the width 
of the page.  It was this use case that triggered the need for PSMI 
in the first place.



One of the consequences of the way PSMI does its thing is that it isn't a
true float: the landscaped table page is in line with the flow on the
adjacent pages.

Indeed.



In practice, that means that the preceding page will not be full.

True.  Given the functionality of page sequences and that PSMI 
triggers new page sequences, this is in fact the case.



Certainly, a block cannot straddle the table page (say, a
paragraph starting at the bottom of the preceding page and continuing at
the top of the following page).  It's this kind of floating-page table
that I want: the table sits on a page near its reference point ("see Table
1"); it may be rotated; it may extend over more than one page; the regular
flow of the body text is not affected.

From my experiments, Antenna House now supports most of what you are 
asking for ... but not quite all:  a rotated block container in the 
flow with a table that is longer than the page width will trigger 
pagination of multiple pages:



            <block>This is a test</block>
            ...
            <block>This is a test</block>
            <block>This is a test (followed by table)</block>
              <block-container inline-progression-dimension="100%"
                               reference-orientation="90">
                <table>
                  <table-body>
                    <table-cell>
                      <block>table cell block</block>
                      <block>table cell block</block>
                      ...
                      <block>table cell block</block>
                      <block>table cell block</block>
                    </table-cell>
                  </table-body>
                </table>
              </block-container>
            <block>This is a test</block>
            ...
            <block>This is a test</block>

I do note, however, that a before float with a rotated block 
container in the flow with a table that is longer than the page width 
will not trigger pagination of multiple pages:



            <block>This is a test</block>
            ...
            <block>This is a test</block>
            <block>This is a test (followed by table)</block>
            <float float="before">
              <block-container inline-progression-dimension="100%"
                               reference-orientation="90">
                <table>
                  <table-body>
                    <table-cell>
                      <block>table cell block</block>
                      <block>table cell block</block>
                      ...
                      <block>table cell block</block>
                      <block>table cell block</block>
                    </table-cell>
                  </table-body>
                </table>
              </block-container>
            </float>
            <block>This is a test</block>
            ...
            <block>This is a test</block>

So ... you still get the gap at the bottom of the break before the 
table ... when you use float to get rid of the gap, the float does 
not trigger pagination.



XSL 1.1 has flow maps and other enhancements to page sequences, but I
don't know if it knows enough to do what I want.  Is this kind of
processing simply beyond the expressiveness that FO 1.1 is capable of?

Oh, FO 1.0 *expressed* the breaking of pages with rotated blocks ... 
there just were no processors at the time that supported it.



I need more time that I have available this morning to think about a 
float ... my intuition is that a float with a rotated block container 
that is longer than the page width should paginate just fine ... but 
I note that a float with a block container that is not rotated but is 
too long for the page length doesn't paginate 
either.  Hmmmmmmmm....... that would indicate that *no* float too 
long for a page will paginate.  I need more time to figure out what 
FO says about floats that are too big.  Non-rotated footnotes that 
are too big wrap to the next page ... my experiments show this cannot 
be used for a full-page footnote, and a rotated one appears not to 
paginate either.



I'm OK about using XSLT to munge the FO source a la PSMI.

I gather many people are ... this has been a popular free download 
from our collection of free developer resources.



I hope this helps.



. . . . . . . . . . . Ken



--
Upcoming public training: UBL and code lists Oct 1/5; Madrid Spain
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Jul'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent