Bug 51484 - Empty section at end of file (generates blank page in openoffice)
Summary: Empty section at end of file (generates blank page in openoffice)
Status: CLOSED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: rtf (show other bugs)
Version: all
Hardware: PC Linux
: P3 normal
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-06 16:03 UTC by Roger
Modified: 2012-05-03 14:26 UTC (History)
1 user (show)



Attachments
The fo file I use to generate the rtf (551 bytes, text/x-xslfo)
2011-07-06 16:03 UTC, Roger
Details
the generated rtf (762 bytes, application/rtf)
2011-07-06 16:04 UTC, Roger
Details
Hack for RtfSection.java (1.04 KB, patch)
2011-10-06 10:11 UTC, Benjamin Riefenstahl
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Roger 2011-07-06 16:03:55 UTC
Created attachment 27266 [details]
The fo file I use to generate the rtf

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.
Comment 1 Roger 2011-07-06 16:04:14 UTC
Created attachment 27267 [details]
the generated rtf
Comment 2 Benjamin Riefenstahl 2011-10-06 10:11:24 UTC
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.
Comment 3 Glenn Adams 2012-04-07 01:41:29 UTC
resetting P2 open bugs to P3 pending further review
Comment 4 Glenn Adams 2012-04-08 05:20:49 UTC
(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.?
Comment 5 Glenn Adams 2012-04-24 05:44:51 UTC
(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
Comment 6 Benjamin Riefenstahl 2012-04-25 08:16:59 UTC
> 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.
Comment 7 Glenn Adams 2012-04-25 14:01:08 UTC
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)
Comment 8 Benjamin Riefenstahl 2012-04-26 09:10:25 UTC
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");
        }
Comment 9 Glenn Adams 2012-04-26 13:21:57 UTC
(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
Comment 10 Benjamin Riefenstahl 2012-05-03 13:59:31 UTC
Works for my test-case.  Thank you very much.