DO NOT REPLY [Bug 41860] FOP crash on fixed-layout table with increasing number of cells/row

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=41860

Glenn Adams  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Glenn Adams  2012-04-01 06:55:24 UTC ---
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DO NOT REPLY [Bug 41860] - FOP crash on fixed-layout table with increasing number of cells/row

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  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.

Re: DO NOT REPLY [Bug 41860] - FOP crash on fixed-layout table with increasing number of cells/row

[Andreas L Delmelle]

On Mar 19, 2007, at 15:01, Vincent Hennebert wrote:



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

[Vincent Hennebert]

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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 [EMAIL PROTECTED]  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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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 [EMAIL PROTECTED]  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.