page break in incorrect place in odt->pdf conversion

[GoogleCodeExporter]

Imagine a scenario:

We have an odt file template which spans 2 pages. We have some velocity 
$placeholders in this file

We process it via velocity and convert to pdf.

If some value replaced by a placeholder is lenghty or spans more than one line, 
page text will fill into second page. But we still have soft page break in the 
same place! So finally we have resulting pdf as below:

page1 - full of text from original page1
page2 - one or a few lines from original page1, rest of page is empty
page3 - full of text from original page2

In my opinion soft page breaks should be simply ignored as they represent only 
a hint where text should move to a next page. Process of $placeholder 
replacement may easily change the place where page break really should occur.
It is enough to modify function
public void visit(TextSoftPageBreakElement ele) {
  // do nothing 
}
in ElementVisitorForIText.java

I didn't test it but probably the same situation occurs in docx->pdf converter.

Of course explicit page breaks should be preserved - as it is now.

Regards
Leszek

Original issue reported on code.google.com by lesz...@safe-mail.net on 14 Dec 2011 at 11:03

[GoogleCodeExporter]

You mean that 

public void visit(TextSoftPageBreakElement ele) {
  // do nothing 
}

must be empty? If it's that I will study that.

Original comment by angelo.z...@gmail.com on 14 Dec 2011 at 1:15

• Changed state: Accepted

[GoogleCodeExporter]

exactly, this function should be empty to ignore soft page breaks.
Explictit page breaks are handled in paragraph conversion and are preserved

Original comment by lesz...@safe-mail.net on 15 Dec 2011 at 8:53

[GoogleCodeExporter]

Ok, I will try that.

Thanks

Original comment by angelo.z...@gmail.com on 15 Dec 2011 at 8:58

[GoogleCodeExporter]

Alternatively you can add an option 'preserveSoftPageBreaks' which defaults to 
false and break the page or not depending on how this option is set. This would 
be the best solution.

Original comment by lesz...@safe-mail.net on 21 Dec 2011 at 8:39

[GoogleCodeExporter]

Original comment by angelo.z...@gmail.com on 10 Jan 2012 at 3:11

• Changed state: Fixed