Bug 39443 - Long tables stop spanning in multiple columns after first page
Summary: Long tables stop spanning in multiple columns after first page
Status: CLOSED WORKSFORME
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: page-master/layout (show other bugs)
Version: all
Hardware: Other All
: P2 major
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-28 08:33 UTC by Adam
Modified: 2012-04-30 00:19 UTC (History)
2 users (show)



Attachments
Big table spanning 2 columns (126.58 KB, text/plain)
2006-04-28 08:36 UTC, Adam
Details
Example FO using latest Trunk version (23.76 KB, application/pdf)
2006-04-28 14:32 UTC, Adam
Details
Bugfix for 0.95 (23.66 KB, patch)
2009-12-01 00:59 UTC, Sergey
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam 2006-04-28 08:33:57 UTC
When the column-count is greater than the default 1 column, very long tables
(multiple pages) that have span="all" block around it stop spanning after the
first page and revert back to column mode. 
The table flows in the orginal column count and the width is is still span="all"
width. Major overlapping text.

<fo:region-body column-count="2" column-gap="1cm" ....
...

<fo:flow flow-name="xsl-region-body">
...
  <fo:block span="all">
                <fo:table ....



This was working but seems to of come up since the 0.91 release.
Comment 1 Adam 2006-04-28 08:36:54 UTC
Created attachment 18198 [details]
Big table spanning 2 columns

Here is a XSL FO file that gives and example of what I mean.
Comment 2 Adam 2006-04-28 14:32:46 UTC
Created attachment 18199 [details]
Example FO using latest Trunk version
Comment 3 Jeremias Maerki 2006-05-07 12:23:01 UTC
Bug fixed in Trunk: http://svn.apache.org/viewcvs?rev=404751&view=rev
Comment 4 Sergey 2009-10-23 07:51:30 UTC
reproduced on Apache FOP Version 0.95
Comment 5 Sergey 2009-11-30 14:12:40 UTC
This was originally attachment ID 24629 that was lost as part of the issues.apache.org data loss on 2009-11-26/27.

Note that this attachment ID has since been re-used.

The original attachment comment was:
Bugfix for 0.95
Comment 6 Vincent Hennebert 2009-11-30 15:02:13 UTC
(In reply to comment #5)
> This was originally attachment ID 24629 that was lost as part of the
> issues.apache.org data loss on 2009-11-26/27.
> 
> Note that this attachment ID has since been re-used.
> 
> The original attachment comment was:
> Bugfix for 0.95

Thanks for your patch. The FO document attached to this bug report renders fine with the latest Trunk, so the issue has somehow been fixed meanwhile. If you can test the Trunk and have a document that doesn't render well with it, feel free to attach it to this bug report (and re-open that latter) and we are going to have a further look at it.

Meanwhile, your patch may be useful to users who must stick with 0.95.

Thanks, Vincent
Comment 7 Sergey 2009-12-01 00:59:30 UTC
Created attachment 24650 [details]
Bugfix for 0.95

This is originally attachment ID 24629 that was lost as part of the
issues.apache.org data loss on 2009-11-26/27.

(In addition to comment #5)
Comment 8 Harsha 2011-05-26 13:09:17 UTC
This has come back in apache fop version 6.X
Comment 9 Vincent Hennebert 2011-07-04 16:46:49 UTC
I can't reproduce the issue with the attached example. Can you provide a sample FO file illustrating the problem with the latest Trunk?

Thanks,
Vincent
Comment 10 Glenn Adams 2012-04-01 16:11:09 UTC
vincent reports irreproducible in trunk; since no further information has been providing, i'm moving to resolved+worksforme
Comment 11 Glenn Adams 2012-04-30 00:19:39 UTC
batch transition resolved+worksforme to closed+worksforme; if you believe this
remains a bug and can demonstrate it with appropriate input FO file and output
PDF file (as applicable), then you may reopen