Uploaded image for project: 'FOP'
  1. FOP
  2. FOP-1093

Multi-Column-Page Layout Issues

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Resolution: Fixed
    • 2.5
    • None
    • layout/unqualified
    • Operating System: Windows XP
      Platform: Other
    • 37468

    Description

      Hi, this is the first time I've used Bugzilla, so please bare with me, because
      I've got some real bug issues here. I've looked and looked everywhere I could
      possibly try on the internet, and I have not found any documentation on the
      internet regarding this issue. Actually, it's two issues (related, but most
      likely separate issues). I will work with anyone who's prepared to tackle
      this problem, and I can provide screen shots, code samples (of the
      intermediate FO) or whatever it will take to fix this. I'm working on a
      development project that will go into production soon, and I've already
      migrated my code to the newer trunk version (just recompiled the source
      yesterday, so I'm up to date.) I'm also running WinXP with JDK1.5, if that
      helps.

      Anyway, here we go..

      Issue 1 (Minor) - The page regions defined on multi-column pages does not
      position correctly, and always renders offset a specific amount.

      Every fo:region-body I set up with column-count set to more than "1" seems to
      create the column layout such that the columns on the right-hand side of the
      page are "smushed" into the page. (WORKAROUND: Big hint here.) I've found a
      workaround that corrects this problem, and will most likely help you determine
      where this bug is located. If the margin-right property for the fo:region-
      body is recalculated, all columns display correctly (correct widths, position,
      and gaps). From what I can gather, here is the way to determine what to
      change the margin-right property to: margin-right = intended-margin-right -
      offset. offset = (column-count - 1) * column-gap. (or, offset = num-gaps *
      column-gap).

      Example:
      Create a page & body with margin-left="0.0in" and margin-right="0.0in".
      Specify column-count="3" and column-gap="0.5in". (This will leave 7.5in for
      column space, giving columns of 2.5in each from page-edge to page-edge.) Fill
      up the page with one block filled with any text, and watch as the right side
      of the page shows a huge margin while the left side of the page is text to the
      edge like we intended. Now determine the offset, which is 2 gaps * 0.5in/gap
      = 1.0in. So with our intended margin-right of 0.0, set margin-right="-
      1.0in". Voila, it runs text to the edge of the page. Try this again with 6
      columns, 0.5in gaps. That should create 5 gaps with 0.5in each, 6 columns of
      1in each. The margin is off again, so recalculate margin-right to be "-2.5in"
      and again, it will display correctly.
      (I can provide my code that I'm using in my product, which shows the same
      thing above, just not as nice-looking numbers to do the math in your head
      for. Try it above with left-right margins set to 0.40625in (13/32in.) This
      workaround still works. Okay, thats enough of that issue.. It's an issue
      that I can live with the work-around for now.. my next issue I cannot solve
      myself, and it's a real pain.)

      Issue 2 (Major) - On multi-column pages, text inside fo:block with flow to the
      next column (or page, if filled last column), but fo:table and all other
      fo:table-level-elements will not flow to the next column on the same page.

      Fo:table will not continue to display on the current page once a break is
      detected (or the break is determined to be page-level and not column-level, as
      it should be). I've tried creating tables of all sizes, one-by-one tables,
      2x1 tables, 2xmany tables, 1xmany tables, nothing will force the table to
      appear in the next column, with the exception of a break-before or break-after
      found on fo:table-row within the fo:table-body. This property also needs to
      be set to "column" for it to work. My main problem is that I have a large
      table with a lot of rows, and a header I need display every time there's a
      break, so tables are necessary because the breaks cannot be determined
      manually. Instead of the intended behavior of the tables breaking to the next
      column and displaying the header, it will simply break to the next page,
      leaving the rest of the current page blank, and simply continue in the first
      column of the following page as if it's the next column it should appear. All
      other behavior appears correct (header displays, breaks when it should, but
      wrong break context.) I should point out that manually calling break-after or
      break-before WILL force the table to break to the next column CORRECTLY, and
      tables that begin in a column other than the first also appear correctly, but
      still break on the page every time, not column. The only time I can make it
      break in the column context is by manually calling break-before or break-after
      on specific table-rows. This is not an option for me because my table can
      start anywhere on the page and calculating breaks manually is impossible, so
      getting a working implementation of this is important (for all of us )

      Lastly, release version 0.20.5 appears to implement this correctly (as well as
      issue 1) but both bugs still appear in the trunk version.

      Okay all, I hope this was informative enough that these issues can be easily
      fixed. (it seems to be small fixes in the logic that used to work
      correctly). Please email me if more information is needed, or you can't
      reproduce the results I'm getting. Thanks everyone, good luck!

      Attachments

        Activity

          People

            fop-dev@xmlgraphics.apache.org fop-dev
            johnp@customcall.com John Peregrine
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: