You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2009/01/07 14:38:06 UTC
DO NOT REPLY [Bug 46489] New: page-position="last" can cause an
extra blank page.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46489
Summary: page-position="last" can cause an extra blank page.
Product: Fop
Version: 0.95
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: page-master/layout
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: bowditch_chris@hotmail.com
Created an attachment (id=23092)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23092)
Sample FO to reproduce bug
FO has been checked for obvious causes why blank page is added at the end of
the document, i.e. not caused by space-after, break-* properties or
force-page-count. Removing the fo:repeatable-page-master-alternatives element
in favour of a single repeating page master avoids the blank page. Sample FO
that reproduces the problem in trunk has been attached.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 46489] page-position="last" can cause an extra
blank page.
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46489
--- Comment #3 from Andreas L. Delmelle <ad...@apache.org> 2009-03-22 04:16:03 PST ---
Upon checking closer: the difference between the scenario with and without
tables is that, without tables the break-before has already triggered
addAreas() for the preceding parts. With tables, the forced break is included
in the complete list, but is preceded by another penalty which seems to confuse
things... The restartPoint is set to the point *between* the two penalties, so
when we restart the algorithm for the last page, it will encounter the forced
break too, as a first element, and produces two pages instead of only one.
I managed to hack the issue away locally by a adding a small check for this in
PageBreaker.doPhase3WithLastPage():
...
newStartPos = pbp.getLeafPos();
/* hack to avoid producing an extra page after the last */
if (((KnuthElement)effectiveList.get(newStartPos)).isForcedBreak())
{
newStartPos++;
}
...
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 46489] page-position="last" can cause an extra
blank page.
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46489
Andreas L. Delmelle <ad...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #5 from Andreas L. Delmelle <ad...@apache.org> 2009-03-22 12:22:55 PST ---
(In reply to comment #4)
> Therefore, I'm thinking that the newStartPos variable in
> PageBreaker.doPhase3WithLastPage() should unconditionally be set to
> (pb.getLeafPos() + 1).
This has been committed with r757239 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=757239 )
Thanks for reporting!
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 46489] page-position="last" can cause an extra
blank page.
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46489
--- Comment #2 from Andreas L. Delmelle <ad...@apache.org> 2009-03-22 02:57:24 PST ---
Created an attachment (id=23396)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23396)
modified sample; demonstrating the influence of tables
If we remove tables from the picture, the issue disappears as well.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 46489] page-position="last" can cause an extra
blank page.
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46489
Andreas L. Delmelle <ad...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Platform|PC |All
Version|0.95 |all
OS/Version|Windows XP |All
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 46489] page-position="last" can cause an extra
blank page.
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46489
--- Comment #1 from Andreas L. Delmelle <ad...@apache.org> 2009-03-22 02:20:45 PST ---
Some initial observations:
The issue is again with the last page-master. Commenting out only that one,
also produces the expected result. This time, it's the combination with the
last break-before in the document. Another way to avoid the issue for the
moment, is by moving that as a break-after to the last preceding block.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 46489] page-position="last" can cause an extra
blank page.
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46489
--- Comment #4 from Andreas L. Delmelle <ad...@apache.org> 2009-03-22 11:52:36 PST ---
In the meantime, I tracked the origin of the superfluous penalty to
BlockStackingLM.getNextKnuthElements() (line 350). Avoiding its creation and
insertion into the result list does not solve the matter, although we might
fare better in general if we only call addInBetweenBreak() in case the
returnedList, whose elements will be appended after that call, does not itself
already start with a forced break. (A similar thing happens in FlowLM, by the
way...)
The real issue is that the restarting point is set to the index of the penalty
representing the last page-break. Better put: the restarting point is always
set to right *before* the last page-break, instead of the immediately *after*.
No problem for a regular break-possibility, but this generates the side-effect
of the extra page if the break was forced.
Therefore, I'm thinking that the newStartPos variable in
PageBreaker.doPhase3WithLastPage() should unconditionally be set to
(pb.getLeafPos() + 1).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 46489] page-position="last" can cause an extra
blank page.
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46489
Glenn Adams <gl...@skynav.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #6 from Glenn Adams <gl...@skynav.com> 2012-04-01 06:35:49 UTC ---
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.