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 bu...@apache.org on 2007/03/16 11:28:27 UTC
DO NOT REPLY [Bug 41860] New: - FOP crash on fixed-layout table with increasing number of cells/row
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41860>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41860
Summary: FOP crash on fixed-layout table with increasing number
of cells/row
Product: Fop
Version: 1.0dev
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: page-master/layout
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: arno@dmxprint.nl
Rendering a table with fixed layout where the first row has two cells and the
second has more than two cells crashes FOP
Example FO document to show the bug:
<?xml version="1.0"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<fo:layout-master-set>
<fo:simple-page-master master-name="page">
<fo:region-body region-name="body"/>
</fo:simple-page-master>
<fo:page-sequence-master master-name="contents">
<fo:repeatable-page-master-reference master-reference="page"/>
</fo:page-sequence-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="contents">
<fo:flow flow-name="body">
<fo:block>
<fo:table table-layout="fixed" width="100%">
<fo:table-body>
<fo:table-row>
<fo:table-cell>
<fo:block>x</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block>x</fo:block>
</fo:table-cell>
</fo:table-row>
<fo:table-row>
<fo:table-cell>
<fo:block> </fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block>A</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block>B</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block>C</fo:block>
</fo:table-cell>
</fo:table-row>
</fo:table-body>
</fo:table>
</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Re: DO NOT REPLY [Bug 41860] - FOP crash on fixed-layout table with increasing number of cells/row
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 19, 2007, at 15:01, Vincent Hennebert wrote:
> <snip />
> We could mimic the HTML specification to a certain extent, that is:
> - if table-columns are specified, they fix the number of columns
> and any
> row having more columns would be considered erroneous;
> - otherwise, I see two possibilities:
> - either we use the row which has the most columns; this would have
> a potentially heavy impact on memory consumption since the table
> would have to be read in its entirety. IIC that's already the case
> today, but if we are to implement some producer-consumer model
> as we
> recently discussed about this will become noticeable. But that
> would
> be a nice-to-have for users who don't care about memory
> consumption
> or for simple tables. All the more than if they do care, they
> would
> just have to add fo:table-columns objects.
> - or we do as currently, that is rely on the first rows of each
> table-header/footer/body. But then we would have to take only the
> first table-body into account, to avoid a bad impact on memory.
>
> I'm personally in favor of the first solution, because it provides
> means
> to satisfy everyone: speed as well as flexibility.
The first solution seems acceptable to me, for fixed-layout. In
theory, it /could/ happen that the first row of the body/header/
footer has more cells than there are explicit columns, but I think we
can safely assume that to be an anomaly rather than the author's
intent. The message being: either use implicit or explicit columns,
but a mixture should be avoided.
For auto-layout, however, I even think that the maximum number of
columns could vary between one page and the next... but we're still
far from having auto-layout completely implemented, so we'll cross
that bridge once we get there.
Cheers,
Andreas
Re: DO NOT REPLY [Bug 41860] - FOP crash on fixed-layout table with
increasing number of cells/row
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi,
[Andreas]
> This should indeed be handled better, but your FO is actually very dubious...
> In fixed-layout, the number of columns and their respective widths are ultimately determined based on
> the cells in the first row. There is no obligation for an implementation of XSL-FO to even process the
> offending cells in the next rows...
It appears that I've been thinking about that recently. In the current
code, the number of columns of a table is the maximum number of columns
in the first rows of:
- the table-header, if any;
- the table-footer, if any;
- each (and every!) table-body.
AFAIK it is specified nowhere in the Recommendation how this number of
columns should actually be computed. The CSS2 spec doesn't tell anything
about this either. In the HTML 4.01 specification, it is stated that
(adapted to FO vocabulary) if there are fo:table-columns elements, they
fix the number of columns, otherwise this is the number of columns in
the row having the most columns.
We could mimic the HTML specification to a certain extent, that is:
- if table-columns are specified, they fix the number of columns and any
row having more columns would be considered erroneous;
- otherwise, I see two possibilities:
- either we use the row which has the most columns; this would have
a potentially heavy impact on memory consumption since the table
would have to be read in its entirety. IIC that's already the case
today, but if we are to implement some producer-consumer model as we
recently discussed about this will become noticeable. But that would
be a nice-to-have for users who don't care about memory consumption
or for simple tables. All the more than if they do care, they would
just have to add fo:table-columns objects.
- or we do as currently, that is rely on the first rows of each
table-header/footer/body. But then we would have to take only the
first table-body into account, to avoid a bad impact on memory.
I'm personally in favor of the first solution, because it provides means
to satisfy everyone: speed as well as flexibility.
WDYT?
Vincent
DO NOT REPLY [Bug 41860] - FOP crash on fixed-layout table with increasing number of cells/row
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41860>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41860
------- Additional Comments From a_l.delmelle@pandora.be 2007-03-16 09:11 -------
This should indeed be handled better, but your FO is actually very dubious...
In fixed-layout, the number of columns and their respective widths are ultimately determined based on
the cells in the first row. There is no obligation for an implementation of XSL-FO to even process the
offending cells in the next rows...
Going to leave the bug open, but just wanted to let you know this.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41860] - FOP crash on fixed-layout table with increasing number of cells/row
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41860>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41860
------- Additional Comments From arno@dmxprint.nl 2007-03-16 06:23 -------
Created an attachment (id=19721)
--> (http://issues.apache.org/bugzilla/attachment.cgi?id=19721&action=view)
Backtrace of fop crash
Produced with FOP-SVN at revision 518965.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41860] - FOP crash on fixed-layout table with increasing number of cells/row
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41860>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41860
vincent.hennebert@anyware-tech.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From vincent.hennebert@anyware-tech.com 2007-11-29 10:47 -------
This is now fixed in the Trunk. If the table doesn't have any fo:table-column
children then its number of columns will be set by the row having the most cells
(the second one in your example).
If the table does have fo:table-column children then rows are not allowed to
have more cells than the number of fo:table-columns. This is for performance
reasons, to be able to start the layout of the table before its end is reached.
Vincent
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.