Fop
  1. Fop
  2. FOP-1182

Long tables stop spanning in multiple columns after first page

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Cannot Reproduce
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: page-master/layout
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: Other
    • External issue ID:
      39443

      Description

      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.

      1. eg.fo
        127 kB
        Adam
      2. eg.pdf
        24 kB
        Adam
      3. PageBreaker.java
        24 kB
        Sergey

        Activity

        Hide
        Adam added a comment -

        Here is a XSL FO file that gives and example of what I mean.

        Show
        Adam added a comment - Here is a XSL FO file that gives and example of what I mean.
        Hide
        Adam added a comment -

        Attachment eg.fo has been added with description: Big table spanning 2 columns

        Show
        Adam added a comment - Attachment eg.fo has been added with description: Big table spanning 2 columns
        Hide
        Adam added a comment -

        Attachment eg.pdf has been added with description: Example FO using latest Trunk version

        Show
        Adam added a comment - Attachment eg.pdf has been added with description: Example FO using latest Trunk version
        Hide
        Jeremias Maerki added a comment -
        Show
        Jeremias Maerki added a comment - Bug fixed in Trunk: http://svn.apache.org/viewcvs?rev=404751&view=rev
        Hide
        Sergey added a comment -

        reproduced on Apache FOP Version 0.95

        Show
        Sergey added a comment - reproduced on Apache FOP Version 0.95
        Hide
        Sergey added a comment -

        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

        Show
        Sergey added a comment - 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
        Hide
        Vincent Hennebert added a comment -

        (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

        Show
        Vincent Hennebert added a comment - (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
        Hide
        Sergey added a comment -

        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)

        Show
        Sergey added a comment - 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)
        Hide
        Sergey added a comment -

        Attachment PageBreaker.java has been added with description: Bugfix for 0.95

        Show
        Sergey added a comment - Attachment PageBreaker.java has been added with description: Bugfix for 0.95
        Hide
        Harsha added a comment -

        This has come back in apache fop version 6.X

        Show
        Harsha added a comment - This has come back in apache fop version 6.X
        Hide
        Vincent Hennebert added a comment -

        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

        Show
        Vincent Hennebert added a comment - 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
        Hide
        Glenn Adams added a comment -

        vincent reports irreproducible in trunk; since no further information has been providing, i'm moving to resolved+worksforme

        Show
        Glenn Adams added a comment - vincent reports irreproducible in trunk; since no further information has been providing, i'm moving to resolved+worksforme
        Hide
        Glenn Adams added a comment -

        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

        Show
        Glenn Adams added a comment - 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

          People

          • Assignee:
            fop-dev
            Reporter:
            Adam
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development