force-page-count
hello
I tried to implement the force-page-count property. It looks like
someone had already prepaired many things and it looks easy, but
there is a showstopper: I had no luck using the
getSucceedingPageSequence function of
/fop/fo/pagination/Root.java from
/fop/layoutmgr/PageSequenceLayoutManager.java by calling
nextPageSeq = pageSeq.getRoot().getSucceedingPageSequence(pageSeq)
it always returns null. In detail the
currentIndex = pageSequences.indexOf(current)
part of the getSucceedingPageSequence function always returns -1
Because i am not very familiar with java and the
getSucceedingPageSequence function is not used elsewhere i want
to ask if it is working as expected or if i called it in a wrong
manner.
Though the work is not ready and not tested at all i venture to
append the patch because it is very little to give you a larger
picture of the circumstances.
gerhard
--
.''`. gerhard oettl on Debian/Gnu Linux
: :' :
`. `'` gpg key: 1024D/D59131AA 2002-06-18
`-
Index: src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java
===
--- src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java
(Revision 360063)
+++ src/java/org/apache/fop/layoutmgr/PageSequenceLayoutManager.java
(Arbeitskopie)
@@ -21,6 +21,7 @@
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.fop.apps.FOPException;
+import org.apache.fop.datatypes.Numeric;
import org.apache.fop.area.AreaTreeHandler;
import org.apache.fop.area.AreaTreeModel;
@@ -146,6 +147,8 @@
int flowBPD = (int)getCurrentPV().getBodyRegion().getRemainingBPD();
breaker.doLayout(flowBPD);
+checkForcePageCount();
+
finishPage();
pageSeq.getRoot().notifyPageSequenceFinished(currentPageNum,
(currentPageNum - startPageNum) + 1);
@@ -888,4 +891,90 @@
}
}
+
+
+
+/*
+ * check if the page-number of the last page suits to the force-page-count
property
+ */
+private void checkForcePageCount() {
+// if (curPage != null) {
+// finishPage();
+// }
+
+int forcePageCount = pageSeq.getForcePageCount();
+PageSequence nextPageSeq;
+int nextPageSeqStartPageNum;
+int nextPageSeqPageNumberType = 0;
+Numeric nextPageSeqInitialPageNumber;
+ int nextPageSeqStartingPageNumber;
+
+log.warn(blabla oettl);
+
+// xsl-spec version 1.0 (15.oct 2001)
+// auto | even | odd | end-on-even | end-on-odd | no-force | inherit
+// auto:
+// Force the last page in this page-sequence to be an odd-page
+// if the initial-page-number of the next page-sequence is even.
+// Force it to be an even-page
+// if the initial-page-number of the next page-sequence is odd.
+// If there is no next page-sequence
+// or if the value of its initial-page-number is auto do not force
any page.
+
+
+// if force-page-count is auto then set the value of forcePageCount
+// depending on the initial-page-number of the next page-sequence
+if (forcePageCount == Constants.EN_AUTO) {
+if ((nextPageSeq =
pageSeq.getRoot().getSucceedingPageSequence(pageSeq)) == null) {
+log.warn(no next pageseq);
+forcePageCount = Constants.EN_NO_FORCE;
+} else {
+nextPageSeqInitialPageNumber =
nextPageSeq.getInitialPageNumber();
+if (nextPageSeqInitialPageNumber.getEnum() != 0) {
+// auto | auto-odd | auto-even
+nextPageSeqPageNumberType =
nextPageSeqInitialPageNumber.getEnum();
+if (nextPageSeqPageNumberType == Constants.EN_AUTO_ODD) {
+forcePageCount = Constants.EN_EVEN;
+} else if (nextPageSeqPageNumberType ==
Constants.EN_AUTO_EVEN) {
+forcePageCount = Constants.EN_ODD;
+} else { // auto
+forcePageCount = Constants.EN_NO_FORCE;
+}
+} else { // integer for explicit page number
+int nextPageSeqPageStart =
nextPageSeqInitialPageNumber.getValue();
+nextPageSeqStartingPageNumber =
+(nextPageSeqPageStart 0) ? nextPageSeqPageStart : 1;
// spec rule
+if (nextPageSeqStartingPageNumber % 2 == 0) { //
explicit even startnumber
+forcePageCount = Constants.EN_ODD;
+} else {// explicit odd startnumber
+forcePageCount = Constants.EN_EVEN;
+}
+}
+}
+}
+
+log.warn(forcePageCount + forcePageCount);
+
+if (forcePageCount == Constants.EN_EVEN) {
+if ((currentPageNum
DO NOT REPLY [Bug 37639] - [PATCH] Whitespace handling revised
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37639. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37639 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-12-30 14:35 --- No vetoes received on this one, so committed: http://svn.apache.org/viewcvs?rev=360083view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/
On Fri, 30 Dec 2005 09:38 pm, Andreas L Delmelle wrote: On Dec 30, 2005, at 14:33, [EMAIL PROTECTED] wrote: snip/ Case not covered by the altered code (but I didn't think it to be a showstopper): If you have: fo:block fo:inlinesome inline text _ /fo:inline_ __/fo:block Currently, the first series of underlined white-space is not completely suppressed. It will at most be collapsed to a single space. The second series --between endInline() and endBlock()-- is completely suppressed because handleWhiteSpace() was called from Block.endOfNode(). Hmm, isn't that a step backwards from the status before you applied the patch? I explicitly excluded fo:leaders from white-space handling, because for example: fo:leader leader-pattern=use-content xxx /fo:leader Collapsing the three spaces to one may produce unintended results. OTOH, if you have a nested inline in a leader, then the white-space for the inline will be treated... Is there an indication in the spec that whitespace around use-content leader patterns should be treated any different? If not, I would include it into the normal white space handling. For the rest only a few minor updates to related test-cases: - block_white-space-collapse_2.xml: see info disabled-testcases.xml - leader_text-align.xml / leader_toc.xml: update of the expected ipd values; they seemed to ignore preserved spaces Didn't your patch fix the marker_bug.xml testcase? If so it can come out of the disabled-testcases. snip/ Cheers, Andreas Regards Manuel
Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/
On Dec 30, 2005, at 14:54, Manuel Mall wrote: On Fri, 30 Dec 2005 09:38 pm, Andreas L Delmelle wrote: snip/ Case not covered by the altered code (but I didn't think it to be a showstopper): snip / Hmm, isn't that a step backwards from the status before you applied the patch? Not really. Just had to draw a line somewhere... If you do it for the last inline in a block, then you would also have to do it for the last inline of the last inline of a block etc. Besides, you get a second pass anyway, when the line is built. All the trailing space- glyph-areas could be removed there (but they currently aren't anyway, depending on text-alignment). I explicitly excluded fo:leaders from white-space handling, because for example: fo:leader leader-pattern=use-content xxx /fo:leader Collapsing the three spaces to one may produce unintended results. OTOH, if you have a nested inline in a leader, then the white-space for the inline will be treated... Is there an indication in the spec that whitespace around use-content leader patterns should be treated any different? If not, I would include it into the normal white space handling. This was more based on expectation than on anything I encountered in the specs, I guess. The white-space around the leader --physically outside of the fo:leader element-- is treated according to the type of parent it belongs to. The spaces inside the content of the fo:leader are left alone. Somehow, even with white-space- collapse=true, I'd much more expect the end result to mimic: fo:leader leader-pattern=use-content...xxx.../fo:leader than fo:leader leader-pattern=use-content xxx /fo:leader snip / Didn't your patch fix the marker_bug.xml testcase? If so it can come out of the disabled-testcases. Yep, it did. Completely forgot about that. Thanks for pointing out. Cheers and Best Wishes for 2006. Andreas
Test case linearea_nonempty_1.xml
After applying the latest round of patches the test case linearea_nonempty_1.xml fails for me. Does that happen to other as well? Manuel
Re: Test case linearea_nonempty_1.xml
On Dec 30, 2005, at 16:26, Manuel Mall wrote: After applying the latest round of patches the test case linearea_nonempty_1.xml fails for me. Does that happen to other as well? It never worked for me, but couldn't remember whether it was the intention, or did someone forget to disable it? I'm not sure, but it seemed to be unrelated to anything I was doing... Cheers, Andreas
Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/
On Dec 30, 2005, at 16:50, Manuel Mall wrote: On Fri, 30 Dec 2005 11:25 pm, Andreas L Delmelle wrote: Not really. Just had to draw a line somewhere... If you do it for the last inline in a block, then you would also have to do it for the last inline of the last inline of a block etc. Besides, you get a second pass anyway, when the line is built. All the trailing space- glyph-areas could be removed there (but they currently aren't anyway, depending on text-alignment). I am still not sure if this is not a step backwards. Before the model was: All whitespace handling apart from dealing with whitespace around FOP generated linebreaks is done during the initial refinement. Now this is not really the case any more and the line breaking stuff would have to deal with treating whitespace in other places than around its own generated linebreaks as well. I was hoping we could get rid of the trailing paragraph space removal code in the line breaking algorithm as it is one of those areas causing trouble again and again. Trailing spaces in a paragraph: yes, absolutely, which is why the trailing whitespace in any block is removed there (albeit only whitespace characters that are direct descendants of the block). Trailing spaces in a line: now *this* is where currently most of the tests fail. Trailing spaces are discarded only when you force text- align to justify (for example). Point is: if trailing spaces in a line are correctly suppressed during line-building, the trailing spaces in the last inline of a given block would be removed in that step (no matter at what depth the inline is nested). Cheers, Andreas
Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/
On Fri, Dec 30, 2005 at 11:50:21PM +0800, Manuel Mall wrote: On Fri, 30 Dec 2005 11:25 pm, Andreas L Delmelle wrote: On Dec 30, 2005, at 14:54, Manuel Mall wrote: On Fri, 30 Dec 2005 09:38 pm, Andreas L Delmelle wrote: I explicitly excluded fo:leaders from white-space handling, because for example: fo:leader leader-pattern=use-content xxx /fo:leader Collapsing the three spaces to one may produce unintended results. OTOH, if you have a nested inline in a leader, then the white-space for the inline will be treated... Is there an indication in the spec that whitespace around use-content leader patterns should be treated any different? If not, I would include it into the normal white space handling. This was more based on expectation than on anything I encountered in the specs, I guess. The white-space around the leader --physically outside of the fo:leader element-- is treated according to the type of parent it belongs to. The spaces inside the content of the fo:leader are left alone. Somehow, even with white-space- collapse=true, I'd much more expect the end result to mimic: fo:leader leader-pattern=use-content...xxx.../fo:leader than fo:leader leader-pattern=use-content xxx /fo:leader Actually I wouldn't (assuming default white space handling property values). What do others think? I agree with Manuel. The white-space-collapse value holds everywhere. The user must provide a value of false if he wants a leader pattern with multiple adjacent spaces. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: force-page-count
On Fri, Dec 30, 2005 at 01:32:30PM +0100, gerhard oettl wrote: hello [...] Because i am not very familiar with java and the getSucceedingPageSequence function is not used elsewhere i want to ask if it is working as expected or if i called it in a wrong manner. i found the reason myself (the page-sequences are not added to the root.pageSequences-list) so i can go on. sorry for wasting your time - i will call again if i succeed. gerhard -- .''`. gerhard oettl on Debian/Gnu Linux : :' : `. `'` gpg key: 1024D/D59131AA 2002-06-18 `-
Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/
On Sat, 31 Dec 2005 02:41 am, Andreas L Delmelle wrote: On Dec 30, 2005, at 16:50, Manuel Mall wrote: On Fri, 30 Dec 2005 11:25 pm, Andreas L Delmelle wrote: Not really. Just had to draw a line somewhere... If you do it for the last inline in a block, then you would also have to do it for the last inline of the last inline of a block etc. Besides, you get a second pass anyway, when the line is built. All the trailing space- glyph-areas could be removed there (but they currently aren't anyway, depending on text-alignment). I am still not sure if this is not a step backwards. Before the model was: All whitespace handling apart from dealing with whitespace around FOP generated linebreaks is done during the initial refinement. Now this is not really the case any more and the line breaking stuff would have to deal with treating whitespace in other places than around its own generated linebreaks as well. I was hoping we could get rid of the trailing paragraph space removal code in the line breaking algorithm as it is one of those areas causing trouble again and again. Trailing spaces in a paragraph: yes, absolutely, which is why the trailing whitespace in any block is removed there (albeit only whitespace characters that are direct descendants of the block). Trailing spaces in a line: now *this* is where currently most of the tests fail. Trailing spaces are discarded only when you force text- align to justify (for example). Point is: if trailing spaces in a line are correctly suppressed during line-building, the trailing spaces in the last inline of a given block would be removed in that step (no matter at what depth the inline is nested). Andreas, the problem is that the Knuth algorithm doesn't deal with spaces (glue) at the end or beginning of a paragraph. It only discards space (glue) when the algorithm creates a line break. It is (messy?) FOP custom code outside the core Knuth algorithm which deals with removing glue at the beginning and end of a paragraph. This should IMO therefore dealt with during refinement. I assume (haven't checked) that your whitespace handling does remove all leading whitespace in a paragraph and therefore it would make sense if it also removes all trailing whitespace (nice symmetry :-)). Note that the point is that we don't need any special code to discard whitespace around Knuth generated linebreaks as the algorithm does that for us (actually we need special code to prevent discards for certain linefeed-treatment values but that is more of a matter of generating Knuth sequences which allow breaks but don't discard and does not require a change to the algorithms). Therefore the only special case is the beginning and end of a paragraph. As the beginning is handled by whitespace handling at the FO level the end bit should be as well. Cheers, Andreas Regards Manuel
