Fop
  1. Fop
  2. FOP-1948

Empty section at end of file (generates blank page in openoffice)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: renderer/rtf
    • Labels:
      None
    • Environment:
      Operating System: Linux
      Platform: PC
    • External issue ID:
      51484

      Description

      At the end of the generated rtf file a "\sect" is created.
      I believe this is wrong, it might however be a matter of definition and up to the reader how it should interpret it.

      The effect it currently has is that in libreoffice/openoffice a blank page is created at the end of the document.
      In Mirosoft Viewer there is no blank page.

      I have attached the fo file and the generated rtf file.

      Even if this is not considered a bug,
      I would be grateful for any hints how I can modify the source, to prevent this empty section to be generated.

      1. example.fo
        0.5 kB
        Roger
      2. example.rtf
        0.7 kB
        Roger
      3. sect.patch
        1 kB
        Benjamin Riefenstahl

        Activity

        Hide
        Roger added a comment -

        Attachment example.fo has been added with description: The fo file I use to generate the rtf

        Show
        Roger added a comment - Attachment example.fo has been added with description: The fo file I use to generate the rtf
        Hide
        Roger added a comment -

        Attachment example.rtf has been added with description: the generated rtf

        Show
        Roger added a comment - Attachment example.rtf has been added with description: the generated rtf
        Hide
        Benjamin Riefenstahl added a comment -

        Attachment sect.patch has been added with description: Hack for RtfSection.java

        Show
        Benjamin Riefenstahl added a comment - Attachment sect.patch has been added with description: Hack for RtfSection.java
        Hide
        Benjamin Riefenstahl added a comment -

        The RTF spec seems to say that FOP is right here and OpenOffice is
        wrong, see <http://www.biblioscape.com/rtf15_spec.htm#Heading27>.
        It's also worth linking here to the corresponding bug report for
        LibreOffice, <https://bugs.freedesktop.org/show_bug.cgi?id=39001>.

        OTOH the attached patch seems to fix the problem for me, I have not
        tested it thoroughly yet, though.

        Show
        Benjamin Riefenstahl added a comment - The RTF spec seems to say that FOP is right here and OpenOffice is wrong, see < http://www.biblioscape.com/rtf15_spec.htm#Heading27 >. It's also worth linking here to the corresponding bug report for LibreOffice, < https://bugs.freedesktop.org/show_bug.cgi?id=39001 >. OTOH the attached patch seems to fix the problem for me, I have not tested it thoroughly yet, though.
        Hide
        Glenn Adams added a comment -

        resetting P2 open bugs to P3 pending further review

        Show
        Glenn Adams added a comment - resetting P2 open bugs to P3 pending further review
        Hide
        Glenn Adams added a comment -

        (In reply to comment #2)
        > Created attachment 27708 [details]
        > Hack for RtfSection.java
        >
        > The RTF spec seems to say that FOP is right here and OpenOffice is
        > wrong, see <http://www.biblioscape.com/rtf15_spec.htm#Heading27>.
        > It's also worth linking here to the corresponding bug report for
        > LibreOffice, <https://bugs.freedesktop.org/show_bug.cgi?id=39001>.
        >
        > OTOH the attached patch seems to fix the problem for me, I have not
        > tested it thoroughly yet, though.

        could you provide additional input showing that the proposed fix is adequate to address this problem, doesn't introduce regressions, etc.?

        Show
        Glenn Adams added a comment - (In reply to comment #2) > Created attachment 27708 [details] > Hack for RtfSection.java > > The RTF spec seems to say that FOP is right here and OpenOffice is > wrong, see < http://www.biblioscape.com/rtf15_spec.htm#Heading27 >. > It's also worth linking here to the corresponding bug report for > LibreOffice, < https://bugs.freedesktop.org/show_bug.cgi?id=39001 >. > > OTOH the attached patch seems to fix the problem for me, I have not > tested it thoroughly yet, though. could you provide additional input showing that the proposed fix is adequate to address this problem, doesn't introduce regressions, etc.?
        Hide
        Glenn Adams added a comment -

        (In reply to comment #4)
        > (In reply to comment #2)
        > > Created attachment 27708 [details]
        > > Hack for RtfSection.java
        > >
        > > The RTF spec seems to say that FOP is right here and OpenOffice is
        > > wrong, see <http://www.biblioscape.com/rtf15_spec.htm#Heading27>.
        > > It's also worth linking here to the corresponding bug report for
        > > LibreOffice, <https://bugs.freedesktop.org/show_bug.cgi?id=39001>.
        > >
        > > OTOH the attached patch seems to fix the problem for me, I have not
        > > tested it thoroughly yet, though.
        >
        > could you provide additional input showing that the proposed fix is adequate to
        > address this problem, doesn't introduce regressions, etc.?

        Roger/Benjamin, I am still awaiting your input as requested above. if I see no further input by April 30, I will close this bug due to lack of requested information. Regards, Glenn

        Show
        Glenn Adams added a comment - (In reply to comment #4) > (In reply to comment #2) > > Created attachment 27708 [details] > > Hack for RtfSection.java > > > > The RTF spec seems to say that FOP is right here and OpenOffice is > > wrong, see < http://www.biblioscape.com/rtf15_spec.htm#Heading27 >. > > It's also worth linking here to the corresponding bug report for > > LibreOffice, < https://bugs.freedesktop.org/show_bug.cgi?id=39001 >. > > > > OTOH the attached patch seems to fix the problem for me, I have not > > tested it thoroughly yet, though. > > could you provide additional input showing that the proposed fix is adequate to > address this problem, doesn't introduce regressions, etc.? Roger/Benjamin, I am still awaiting your input as requested above. if I see no further input by April 30, I will close this bug due to lack of requested information. Regards, Glenn
        Hide
        Benjamin Riefenstahl added a comment -

        > Roger/Benjamin, I am still awaiting your input as requested
        > above.

        Sorry for not answering this earlier.

        >> could you provide additional input showing that the proposed fix is
        >> adequate to address this problem, doesn't introduce regressions,
        >> etc.?

        The short answer is, I can't.

        At the time I looked at the source, found a spot that seemed
        reasonable to fix the bug and gave you the patch. I am really not
        very knowledgeable in the library, in the RTF spec or in the usage of
        RTF in the wild. So no, I can't judge if this is a correct fix in
        general.

        Show
        Benjamin Riefenstahl added a comment - > Roger/Benjamin, I am still awaiting your input as requested > above. Sorry for not answering this earlier. >> could you provide additional input showing that the proposed fix is >> adequate to address this problem, doesn't introduce regressions, >> etc.? The short answer is, I can't. At the time I looked at the source, found a spot that seemed reasonable to fix the bug and gave you the patch. I am really not very knowledgeable in the library, in the RTF spec or in the usage of RTF in the wild. So no, I can't judge if this is a correct fix in general.
        Hide
        Glenn Adams added a comment -

        applied patch (with rewrite) at http://svn.apache.org/viewvc?rev=1330296&view=rev

        roger/benjamin, perhaps you can check if this resolves your problem (i don't use openoffice)

        Show
        Glenn Adams added a comment - applied patch (with rewrite) at http://svn.apache.org/viewvc?rev=1330296&view=rev roger/benjamin, perhaps you can check if this resolves your problem (i don't use openoffice)
        Hide
        Benjamin Riefenstahl added a comment -

        Thank you for looking into it.

        The code does not yet work. Currently it is testing that the current
        element is in the siblings, but what you want to check is, if it has a
        next after that, something like:

        List siblings = parent.getChildren();
        // write suffix /sect only if this section is not last section (see FOP-1948)
        Iterator iterator = siblings.listIterator ( siblings.indexOf ( this ) );
        iterator.next(); // Skip ourselfs
        if ( iterator.hasNext() )

        { writeControlWord("sect"); }
        Show
        Benjamin Riefenstahl added a comment - Thank you for looking into it. The code does not yet work. Currently it is testing that the current element is in the siblings, but what you want to check is, if it has a next after that, something like: List siblings = parent.getChildren(); // write suffix /sect only if this section is not last section (see FOP-1948 ) Iterator iterator = siblings.listIterator ( siblings.indexOf ( this ) ); iterator.next(); // Skip ourselfs if ( iterator.hasNext() ) { writeControlWord("sect"); }
        Hide
        Glenn Adams added a comment -

        (In reply to comment #8)
        > Thank you for looking into it.
        >
        > The code does not yet work. Currently it is testing that the current
        > element is in the siblings, but what you want to check is, if it has a
        > next after that, something like:
        >
        > List siblings = parent.getChildren();
        > // write suffix /sect only if this section is not last section (see bug
        > #51484)
        > Iterator iterator = siblings.listIterator ( siblings.indexOf ( this )
        > );
        > iterator.next(); // Skip ourselfs
        > if ( iterator.hasNext() )

        { > writeControlWord("sect"); > }

        ah, right; forgot to skip this section; here is an improved version that doesn't rely on iteration; please test, and if it resolves it, move this bug to closed... thanks!

        http://svn.apache.org/viewvc?rev=1330838&view=rev

        Show
        Glenn Adams added a comment - (In reply to comment #8) > Thank you for looking into it. > > The code does not yet work. Currently it is testing that the current > element is in the siblings, but what you want to check is, if it has a > next after that, something like: > > List siblings = parent.getChildren(); > // write suffix /sect only if this section is not last section (see bug > #51484) > Iterator iterator = siblings.listIterator ( siblings.indexOf ( this ) > ); > iterator.next(); // Skip ourselfs > if ( iterator.hasNext() ) { > writeControlWord("sect"); > } ah, right; forgot to skip this section; here is an improved version that doesn't rely on iteration; please test, and if it resolves it, move this bug to closed... thanks! http://svn.apache.org/viewvc?rev=1330838&view=rev
        Hide
        Benjamin Riefenstahl added a comment -

        Works for my test-case. Thank you very much.

        Show
        Benjamin Riefenstahl added a comment - Works for my test-case. Thank you very much.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development