You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Bertrand Delacretaz <bd...@codeconsult.ch> on 2001/04/05 22:10:11 UTC
fo:table infinite loop when cell is too high
I thought this had been fixed, but I have a simple example that shows the
problem: FOP 0.18.1-DEV gets into an infinite loop, apparently when a table
cell is too high to fit on one page.
The example is at
http://www.codeconsult.ch/download/fop/
fop-018-table-problems/fop-018-infinite-loop-problem.fo
Follow the instructions in the fo file to "activate" the problem.
Any clues? We might be able to help fixing the problem given some pointers
about where to start looking.
--
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: MORE INFO: fo:table infinite loop when cell is too high
Posted by Karen Lease <ka...@club-internet.fr>.
Bertrand,
Thanks for the test file and the debugging. I got your file and will try
to fix it. I see it is still broken after my latest changes.
-Karen
Bertrand Delacretaz wrote:
>
> FWIW: continuing on my "infinite loop in table cell" example (see below), I
> did some experiments with FOP 0.19.0-CVS and here's what I found:
>
> a) when FOP gets into an infinite loop, I see the same TableCell redoing the
> layout of the same Block over and over
>
> b) the Block correctly sets its Block.marker at the end of the first page,
> but when Block.layout is called by TableCell.layout on the next page, the
> Block.marker has been reset to zero which seems to be the cause of the
> infinite loop
>
> c) If I disable Block.resetMarker() by overriding it with an empty method:
> -the infinite loop is gone
> -the page that should have the first part of the table cell is present but
> blank
> -the next page correctly contains the rest of the table cell
>
> At this point I'm stuck - maybe this can help someone fix this problem (or
> someone can help me fix it :-) ?
>
> The example is at
> http://www.codeconsult.ch/download/fop/
> fop-018-table-problems/fop-018-infinite-loop-problem.fo
> And it contains a line that must be commented out to activate the infinite
> loop.
> --
> -- Bertrand Delacrétaz, www.codeconsult.ch
> -- web technologies consultant - OO, Java, XML, C++
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Table cell infinite loop and widow/orphan properties on
table
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 09:02 AM 4/13/01 +0200, Karen Lease wrote:
>DISCUSSION
>Now before fixing this, I want to discuss using these properties on
>tables. My reading of the XSL-FO CR is that widows and orphans only
>apply to Line Areas in a Block Area. This is in fact the usual
>typographical meaning of these terms. It's true that in sections 7.18.6
>and 7.18.7, the CR says that the properties apply to "block-level
>elements". However the note after 7.18.7 says:
>
> 'In XSL the "orphans" property specifies the minimum number of
>line-areas in the first area
>generated by the formatting object.
> The "widows" property specifies the minimum number of line-areas in
>the last area generated by the formatting object.'
>
>That seems clear to me. So I would interpret "block-level elements" as
>meaning fo:block, period. In fact, in chapter 6, the widow and orphan
>properties are only listed for fo:block.
I consider the property listings by FO to be definitive. So I agree with
you: "widows" and "orphans" are simply not applicable to anything other than
fo:block, by what I consider to be a non-ambiguous reading of the spec.
Note that the "Applies to" tag in the property descriptions is usually more
precise if it's an XSL property, for example if you look at the keeps, as
opposed to CSS2 properties such as these two, where the description is taken
right from the CSS2 spec.
Also, reading Section 4.5 makes it pretty clear what line areas are intended
to be, and we know that "widows" and "orphans" apply to line areas only
(from the XSL-specific part of the property description).
>PROPOSAL
>I therefore propose to stop handling widow and orphan propeties on table
>rows. (NOTE: they can have an effect if we break table cells, because
>they can affect how the cell contents are broken.) Instead, if one
>wants, for example, to force the first two rows to be kept together, one
>can just use keep-with-next="force" on the first row. Similarly, to
>force at least two rows to be together in the last table area, on should
>use keep-with-previous="force" on the last row. Note that this says
>nothing about areas other than the first or last if the table is broken
>into more than two parts. (Strictly speaking, neither does widow or
>orphan, even for block-areas. See above quote.)
I agree, on all points. Because the 2 properties simply do not apply,
according to spec, to anything other than fo:block.
The multi-part bit about widows and orphans for fo:block is a valid point,
although when you think about it, for situations where the fo:block
generates content across umpteen pages and/or columns, since each normal
area that it generates must occupy its own unique column-reference-area or
span-reference-area, it's not really an issue.
>There is already support for keep-with-next and keep-with-previous on
>table-rows. I will make sure that these function as intended and do not
>lead to the infinite loop problem. In fact, what we must do is _not_
>respect keep properties if the "keep set" in question is too large to
>fit in any column-area.
>
>In the table cell-example, if a sequence of rows which are supposed to
>be kept together will not fit together, and if the first row in the
>sequence is already the first in its parent table-body area, and the
>table-area and all of its ancestors are first in _their_ parent areas
>(ie, the table-area is at the top of the column), then we must "violate"
>keeps, either by putting the last row in the sequence in the next area,
>or by breaking it. This latter decision should depend on the value of
>"keep-together" which isn't yet supported.
Right. I mean, if it doesn't fit then it doesn't fit. :-)
>COMMENTS and REACTIONS?
>Please speak up!
Done. :-)
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: fo:table infinite loop when cell is too high SOLVED?
Posted by "Seshadri G.K." <se...@mindfiresolutions.com>.
The contents of a block fo are (#PCDATA|%inline;|%block;)* as specified in
6.5.2 of the XSL spec. Here %block includes block level form,atting objects
which means tables can occur inside fo:block. Then there is the question of
how a table can span the entire page on a 2 column page-layout. There seems
to be no span property for tables. Putting the table inside a block with
span="all" does span the table with it, but then the infinite loop problem
still remains.
seshadri
----- Original Message -----
From: Bertrand Delacretaz <bd...@codeconsult.ch>
To: <fo...@xml.apache.org>
Sent: Tuesday, April 10, 2001 1:05 AM
Subject: fo:table infinite loop when cell is too high SOLVED?
> Seems like the following construct in our fo files caused the problem:
>
> <fo:root>
> <fo:flow>
> <fo:block>
> <fo:table>
>
> Putting the fo:table directly under the fo:flow solves the problem with
FOP
> 0.18 DEV.
>
> If I understand the w3c spec well, an fo:block cannot contain an fo:table.
> This is accepted by the experimental renderX xsl:fo DTD, though.
>
> --
> -- Bertrand Delacrétaz, www.codeconsult.ch
> -- web technologies consultant - OO, Java, XML, C++
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
fo:table infinite loop when cell is too high SOLVED?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Seems like the following construct in our fo files caused the problem:
<fo:root>
<fo:flow>
<fo:block>
<fo:table>
Putting the fo:table directly under the fo:flow solves the problem with FOP
0.18 DEV.
If I understand the w3c spec well, an fo:block cannot contain an fo:table.
This is accepted by the experimental renderX xsl:fo DTD, though.
--
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: MORE INFO: fo:table infinite loop when cell is too high
Posted by "Seshadri G.K." <se...@mindfiresolutions.com>.
Iam looking at this problem too. There is something else apart from the
infinte loop. The table breaking mechanism isnt satisfactory. If the last
row exceeds the page boundary, only the last row should be put in the next
page, but what happens is the last but one also goes there. I'll tell you
when i make some progress.
seshadri
----- Original Message -----
From: Bertrand Delacretaz <bd...@codeconsult.ch>
To: <fo...@xml.apache.org>
Sent: Monday, April 09, 2001 9:26 PM
Subject: MORE INFO: fo:table infinite loop when cell is too high
> FWIW: continuing on my "infinite loop in table cell" example (see below),
I
> did some experiments with FOP 0.19.0-CVS and here's what I found:
>
> a) when FOP gets into an infinite loop, I see the same TableCell redoing
the
> layout of the same Block over and over
>
> b) the Block correctly sets its Block.marker at the end of the first page,
> but when Block.layout is called by TableCell.layout on the next page, the
> Block.marker has been reset to zero which seems to be the cause of the
> infinite loop
>
> c) If I disable Block.resetMarker() by overriding it with an empty method:
> -the infinite loop is gone
> -the page that should have the first part of the table cell is present but
> blank
> -the next page correctly contains the rest of the table cell
>
> At this point I'm stuck - maybe this can help someone fix this problem (or
> someone can help me fix it :-) ?
>
> The example is at
> http://www.codeconsult.ch/download/fop/
> fop-018-table-problems/fop-018-infinite-loop-problem.fo
> And it contains a line that must be commented out to activate the infinite
> loop.
> --
> -- Bertrand Delacrétaz, www.codeconsult.ch
> -- web technologies consultant - OO, Java, XML, C++
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Table cell infinite loop and widow/orphan properties on table
Posted by Carlos Villegas <ca...@uniscope.co.jp>.
Karen Lease wrote:
> PROPOSAL
> I therefore propose to stop handling widow and orphan propeties on table
> rows...
>
> COMMENTS and REACTIONS?
> Please speak up!
How about not handling widows/orphans directly but converting them to
keep properties. So you can go ahead and remove the code if it is
complicating things, but add some preprocessing to convert to keep
conditions. I'm not so sure whether the spec is effectively ruling out
windows/orphans for table rows. I think they're nice properties to have.
Otherwise you need some extra logic in your stylesheet. Nevertheless, as
long as there's a way to produce the same effect...
Carlos
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Table cell infinite loop and widow/orphan properties on table
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Fri, 13 Apr 2001 09:02:18 Karen Lease wrote:
> Hi all,
>
> I've figured out why this happens (only when fo:table is a child of
> fo:block).
> It's because of the handling of the properties "widows" and "orphans" on
> the table (actually on the table-body). The code tries to applies these
> to rows. There are a few bugs so in some cases, it leads to the infinite
> loop that is frequently reported.
>
My fault..
> DISCUSSION
> Now before fixing this, I want to discuss using these properties on
> tables. My reading of the XSL-FO CR is that widows and orphans only
> apply to Line Areas in a Block Area. This is in fact the usual
> typographical meaning of these terms. It's true that in sections 7.18.6
> and 7.18.7, the CR says that the properties apply to "block-level
> elements". However the note after 7.18.7 says:
>
> 'In XSL the "orphans" property specifies the minimum number of
> line-areas in the first area
> generated by the formatting object.
> The "widows" property specifies the minimum number of line-areas in
> the last area generated by the formatting object.'
>
> That seems clear to me. So I would interpret "block-level elements" as
> meaning fo:block, period. In fact, in chapter 6, the widow and orphan
> properties are only listed for fo:block.
>
In my view this says that if the first area under an fo:block generates
consists of line areas then it should apply.
The table generates a block area and it doesn't say what type its child
areas area. I suppose that the child areas are not line areas but
absolutely positioned children (or something like that).
> PROPOSAL
> I therefore propose to stop handling widow and orphan propeties on table
> rows. (NOTE: they can have an effect if we break table cells, because
> they can affect how the cell contents are broken.) Instead, if one
> wants, for example, to force the first two rows to be kept together, one
> can just use keep-with-next="force" on the first row. Similarly, to
> force at least two rows to be together in the last table area, on should
> use keep-with-previous="force" on the last row. Note that this says
> nothing about areas other than the first or last if the table is broken
> into more than two parts. (Strictly speaking, neither does widow or
> orphan, even for block-areas. See above quote.)
The code should probably be removed.
>
> There is already support for keep-with-next and keep-with-previous on
> table-rows. I will make sure that these function as intended and do not
> lead to the infinite loop problem. In fact, what we must do is _not_
> respect keep properties if the "keep set" in question is too large to
> fit in any column-area.
Currently there is a problem with TableRow class, the attached file should
fix this (as well as some other things), I can't commit right now - network
problems.
>
> In the table cell-example, if a sequence of rows which are supposed to
> be kept together will not fit together, and if the first row in the
> sequence is already the first in its parent table-body area, and the
> table-area and all of its ancestors are first in _their_ parent areas
> (ie, the table-area is at the top of the column), then we must "violate"
> keeps, either by putting the last row in the sequence in the next area,
> or by breaking it. This latter decision should depend on the value of
> "keep-together" which isn't yet supported.
The problem is to know when to violate the keeps.
>
> COMMENTS and REACTIONS?
> Please speak up!
>
> Regards,
> Karen Lease
Re: Table cell infinite loop and widow/orphan properties on table
Posted by Karen Lease <ka...@club-internet.fr>.
Bertrand,
Yes, I agree that keep-together is important. It's on my list too. In
general, I think that table-rows almost always want to be kept-together,
except when they are being used as a workaround for some other missing
FO feature (side-by-side composition of some kind...)
But for now, most of the keeps and break work is sort of a band-aid. We
really need some major work on making intelligent layout decisions.
Arved and a few of the rest of us are cogitating....
Regards,
Karen Lease
Bertrand Delacretaz wrote:
>
> > PROPOSAL
> > I therefore propose to stop handling widow and orphan propeties on table
> > rows.
>
> Agreed - I think it makes sense to differentiate between "keeping text
> paragraphs together" (which I'd consider to be typography) and "keeping table
> elements together" (which tends to be more "document structure").
>
> I'd like to be able to "keep-together" the contents of a table row, however
> (ASAP ;-), as I think the following scenario is very common in business
> documents:
> -first column contains a short title
> -second column contains several items (text, image, table) that all belong to
> the same short title
>
> In such a case, if the cell in second column does not fit on the current
> page, I'd like the whole row to be moved to the next page (assuming it
> fits on a page, otherwise it must be broken up).
>
> -- Bertrand Delacrétaz, www.codeconsult.ch
> -- web technologies consultant - OO, Java, XML, C++
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Table cell infinite loop and widow/orphan properties on table
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
> PROPOSAL
> I therefore propose to stop handling widow and orphan propeties on table
> rows.
Agreed - I think it makes sense to differentiate between "keeping text
paragraphs together" (which I'd consider to be typography) and "keeping table
elements together" (which tends to be more "document structure").
I'd like to be able to "keep-together" the contents of a table row, however
(ASAP ;-), as I think the following scenario is very common in business
documents:
-first column contains a short title
-second column contains several items (text, image, table) that all belong to
the same short title
In such a case, if the cell in second column does not fit on the current
page, I'd like the whole row to be moved to the next page (assuming it
fits on a page, otherwise it must be broken up).
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Table cell infinite loop and widow/orphan properties on table
Posted by Karen Lease <ka...@club-internet.fr>.
Hi all,
I've figured out why this happens (only when fo:table is a child of
fo:block).
It's because of the handling of the properties "widows" and "orphans" on
the table (actually on the table-body). The code tries to applies these
to rows. There are a few bugs so in some cases, it leads to the infinite
loop that is frequently reported.
DISCUSSION
Now before fixing this, I want to discuss using these properties on
tables. My reading of the XSL-FO CR is that widows and orphans only
apply to Line Areas in a Block Area. This is in fact the usual
typographical meaning of these terms. It's true that in sections 7.18.6
and 7.18.7, the CR says that the properties apply to "block-level
elements". However the note after 7.18.7 says:
'In XSL the "orphans" property specifies the minimum number of
line-areas in the first area
generated by the formatting object.
The "widows" property specifies the minimum number of line-areas in
the last area generated by the formatting object.'
That seems clear to me. So I would interpret "block-level elements" as
meaning fo:block, period. In fact, in chapter 6, the widow and orphan
properties are only listed for fo:block.
PROPOSAL
I therefore propose to stop handling widow and orphan propeties on table
rows. (NOTE: they can have an effect if we break table cells, because
they can affect how the cell contents are broken.) Instead, if one
wants, for example, to force the first two rows to be kept together, one
can just use keep-with-next="force" on the first row. Similarly, to
force at least two rows to be together in the last table area, on should
use keep-with-previous="force" on the last row. Note that this says
nothing about areas other than the first or last if the table is broken
into more than two parts. (Strictly speaking, neither does widow or
orphan, even for block-areas. See above quote.)
There is already support for keep-with-next and keep-with-previous on
table-rows. I will make sure that these function as intended and do not
lead to the infinite loop problem. In fact, what we must do is _not_
respect keep properties if the "keep set" in question is too large to
fit in any column-area.
In the table cell-example, if a sequence of rows which are supposed to
be kept together will not fit together, and if the first row in the
sequence is already the first in its parent table-body area, and the
table-area and all of its ancestors are first in _their_ parent areas
(ie, the table-area is at the top of the column), then we must "violate"
keeps, either by putting the last row in the sequence in the next area,
or by breaking it. This latter decision should depend on the value of
"keep-together" which isn't yet supported.
COMMENTS and REACTIONS?
Please speak up!
Regards,
Karen Lease
Bertrand Delacretaz wrote:
>
> FWIW: continuing on my "infinite loop in table cell" example (see below), I
> did some experiments with FOP 0.19.0-CVS and here's what I found:
>
> a) when FOP gets into an infinite loop, I see the same TableCell redoing the
> layout of the same Block over and over
>
> b) the Block correctly sets its Block.marker at the end of the first page,
> but when Block.layout is called by TableCell.layout on the next page, the
> Block.marker has been reset to zero which seems to be the cause of the
> infinite loop
>
> c) If I disable Block.resetMarker() by overriding it with an empty method:
> -the infinite loop is gone
> -the page that should have the first part of the table cell is present but
> blank
> -the next page correctly contains the rest of the table cell
>
> At this point I'm stuck - maybe this can help someone fix this problem (or
> someone can help me fix it :-) ?
>
> The example is at
> http://www.codeconsult.ch/download/fop/
> fop-018-table-problems/fop-018-infinite-loop-problem.fo
> And it contains a line that must be commented out to activate the infinite
> loop.
> --
> -- Bertrand Delacrétaz, www.codeconsult.ch
> -- web technologies consultant - OO, Java, XML, C++
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Sorry no user list...
Posted by Alistair Hopkins <al...@berthengron.co.uk>.
Can I just check I have this right?
I have a webapp which uses XSLT to generate web & plaintext content.
It has a controller servlet which loads the relevant logic class and does
whatever. The output of the logic is an XML tree, which contains the state
of the manipulated objects after the logic is executed: ie it contains all
the data necessary to display to the user.
The controller servlet then loads & applies an XSLT transformation which
results in a ByteArrayOutputStream, which is written to the response. The
controller also sets the correct content-type.
I now want to be able to generate pdf documents for certain documents: eg
invoices: which need to be of print quality.
I deduce that the best way to do this is to insert a conditional block after
the xslt transform which checks the content type, and if it is
application/pdf, converts the resultant bytes from the XSLT process (which
contain the necessary fop markup combined with the data) into an InputSource
and processes again into the bytearrayoutputstream, at which point it can
rejoin the normal http processing (setting headers, writing to response,
etcetera)
if (tx.getContentType()=="application/pdf")
{
//do secondary processing of pdf here
resource.log.debug("Do secondary fop processing");
InputSource foFile = new InputSource(bytes); //not
worked out how to do this yet
bytes.reset();
Driver driver = new Driver(foFile, bytes);
driver.run();
}
Is this the most efficient way, or can I do it in a single step?
Thanks,
Alistair.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
MORE INFO: fo:table infinite loop when cell is too high
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
FWIW: continuing on my "infinite loop in table cell" example (see below), I
did some experiments with FOP 0.19.0-CVS and here's what I found:
a) when FOP gets into an infinite loop, I see the same TableCell redoing the
layout of the same Block over and over
b) the Block correctly sets its Block.marker at the end of the first page,
but when Block.layout is called by TableCell.layout on the next page, the
Block.marker has been reset to zero which seems to be the cause of the
infinite loop
c) If I disable Block.resetMarker() by overriding it with an empty method:
-the infinite loop is gone
-the page that should have the first part of the table cell is present but
blank
-the next page correctly contains the rest of the table cell
At this point I'm stuck - maybe this can help someone fix this problem (or
someone can help me fix it :-) ?
The example is at
http://www.codeconsult.ch/download/fop/
fop-018-table-problems/fop-018-infinite-loop-problem.fo
And it contains a line that must be commented out to activate the infinite
loop.
--
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org