FOP
  1. FOP
  2. FOP-1889

Incorrect pagesequence passed to renderer

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: unqualified
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All
    • External issue ID:
      50635

      Description

      The current code passes the current pagesequence to the renderer, but there can be more than one pagesequence in processing.

      So, when a page from an older page sequence is resolved, the current instead of the old page sequnece is started.

      1. pageseq.patch
        0.8 kB
        Martin Koegler

        Activity

        Hide
        Glenn Adams added a comment -

        batch transition to closed; if someone wishes to restore one of these to resolved in order to perform a verification step, then feel free to do so

        Show
        Glenn Adams added a comment - batch transition to closed; if someone wishes to restore one of these to resolved in order to perform a verification step, then feel free to do so
        Hide
        Andreas L. Delmelle added a comment -

        (In reply to comment #3)
        > To simplify my work, I wrote a new renderer, which creates a ZIP file
        > containing each page sequence as its own PDF file [each startPageSequence call
        > creates a new IFRender for PDF]. As the file name is derived from the page
        > sequence object, I noticed, that startPageSequence is called with incorrect
        > page sequences [eg. some are started twice].

        OK, I see. Cool job, btw. Very interesting case.

        So, I took your word for it, and committed the change in r1063022 (http://svn.apache.org/viewvc?rev=1063022&view=rev)

        Thanks for reporting, and the patch!

        Show
        Andreas L. Delmelle added a comment - (In reply to comment #3) > To simplify my work, I wrote a new renderer, which creates a ZIP file > containing each page sequence as its own PDF file [each startPageSequence call > creates a new IFRender for PDF]. As the file name is derived from the page > sequence object, I noticed, that startPageSequence is called with incorrect > page sequences [eg. some are started twice] . OK, I see. Cool job, btw. Very interesting case. So, I took your word for it, and committed the change in r1063022 ( http://svn.apache.org/viewvc?rev=1063022&view=rev ) Thanks for reporting, and the patch!
        Hide
        Martin Koegler added a comment -

        I'm not sure, if it affects any in-tree renderer.

        It can only affect renders not supporting out of order processing [if (!renderer.supportsOutOfOrder() && ...)]

        To simplify my work, I wrote a new renderer, which creates a ZIP file containing each page sequence as its own PDF file [each startPageSequence call creates a new IFRender for PDF]. As the file name is derived from the page sequence object, I noticed, that startPageSequence is called with incorrect page sequences [eg. some are started twice].

        Show
        Martin Koegler added a comment - I'm not sure, if it affects any in-tree renderer. It can only affect renders not supporting out of order processing [if (!renderer.supportsOutOfOrder() && ...)] To simplify my work, I wrote a new renderer, which creates a ZIP file containing each page sequence as its own PDF file [each startPageSequence call creates a new IFRender for PDF] . As the file name is derived from the page sequence object, I noticed, that startPageSequence is called with incorrect page sequences [eg. some are started twice] .
        Hide
        Andreas L. Delmelle added a comment -

        I am wondering...
        Would it be possible to construct a small testcase to show that this leads to wrong output? Or is this not the issue, and is it more of an optimization? Just checking to see if this is a regression that can be tested for, so we can make sure it does not reoccur.

        Thanks!

        Show
        Andreas L. Delmelle added a comment - I am wondering... Would it be possible to construct a small testcase to show that this leads to wrong output? Or is this not the issue, and is it more of an optimization? Just checking to see if this is a regression that can be tested for, so we can make sure it does not reoccur. Thanks!
        Hide
        Martin Koegler added a comment -

        Attachment pageseq.patch has been added with description: Patch

        Show
        Martin Koegler added a comment - Attachment pageseq.patch has been added with description: Patch
        Martin Koegler created issue -

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development