DO NOT REPLY [Bug 38087] [patch] force-page-count property implementation
https://issues.apache.org/bugzilla/show_bug.cgi?id=38087 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #12 from Glenn Adams gl...@skynav.com 2012-04-01 06:39:38 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.
DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation
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=38087. 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=38087 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-01-10 21:21 --- Committed the test cases. Thanks. Simon -- 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.
DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation
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=38087. 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=38087 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2006-01-09 22:20 --- Thanks for the fine test cases. Re noauto: Do you really expect 18 pages? I get 17, and I think that is correct. -- 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.
DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation
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=38087. 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=38087 --- Additional Comments From [EMAIL PROTECTED] 2006-01-10 00:38 --- Yes i expect 17. I want to show the missing pageno 217 - a typical case of self-delusion. -- 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.
DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation
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=38087. 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=38087 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-01-06 22:33 --- Applied. I rearranged the calls somewhat. This is the resulting call hierarchy: PageSequence.startOfNode AreaTreeHandler.startPageSequence PSLM.doForcePageCount (previous PS if not null) PSLM.finishPage PSLM.finishPageSequence (previous PS if not null) Root.notifyPageSequenceFinished AreaTreeHandler.notifyPageSequenceFinished PageSequence.initPageNumber PageSequence.endOfNode AreaTreeHandler.endPageSequence PSLM.activateLayout PSLM.finishPage Thanks for the patch. Simon -- 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: [patch] force-page-count property implementation
On Thu, Jan 05, 2006 at 12:19:26PM +0100, gerhard oettl wrote: It would be good if you could turn it into a test file for the layoutengine tests, which highlights all relevant combinations of force-page-count and initial-page-number. Otherwise I will do it. If have idea how which xslt paths to use for testing, but if you could lead me by sending me one (or two) examples with the first page-sequences of my current (not automated) testfile (may be via PM or so that i check it out with the next svn up and point me to the file) i'll do the rest. I will send you some tests, tomorrow or over the weekend. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation
On Wed, Jan 04, 2006 at 02:08:56PM +0100, gerhard oettl wrote: --- Additional Comments From [EMAIL PROTECTED] 2006-01-03 22:23 --- I am not quite happy with the fact that checkForcePageCount is called by the next page sequence. This is an interaction between page sequences, and it is better dealt with by the controlling structure, in this case AreaTreeHandler. In other words, I go with your suggestion in the second *. I had better orderd the open questions - so think them numbered: - 1) - 2) * 2a) * 2b) * 2c) ad 1) If there is no precedence for one of the choices i will change previousPageSeqLM from public to private as proposed in the question. Agreed. ad 2) I think it is the second - what you call the second * ? Because i couldn't think it a good idea to preserve the PageSequenceLayoutManger at layoutmanger level and call it from area level, so i think i shall do the changes 2a, 2b and 2c alltogether. 2c is a must anyway. 2b is the second *. I agree with your proposal to do all three changes 2a-c. There is a little error in the last page sequence but one in your demo file. It says that next is auto-even, which is not true. yes If of any importance i can add a corrected fo to show the possibility of missing pagenumbers in case of force-page-count=no-force. Let me know. It would be good if you could turn it into a test file for the layoutengine tests, which highlights all relevant combinations of force-page-count and initial-page-number. Otherwise I will do it. .''`. gerhard oettl on Debian/Gnu Linux That's the best, as soon as I find out how to make my mike work. :-) Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation
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=38087. 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=38087 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #17303|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-01-04 23:59 --- Created an attachment (id=17329) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17329action=view) patch 2 (using area tree) ad the now 2c) At the time the checkForcePageCount is called from the AreaTreeHandler the initialPageNumber is already calced by the PageSequence without knowing about eventueally later added pages so it must be recalced. I did this by making the initPageNumber method public. If this should stay private i have to add a public recalcInitPageNumber method that does nothing than call the private initPageNumber method - at your decision. -- 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.
DO NOT REPLY [Bug 38087] New: - [patch] force-page-count property implementation
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=38087. 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=38087 Summary: [patch] force-page-count property implementation Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] This patch (re)implements the force-page-count property. I tried to implement it with as little changes to the code as possible. Therefore some design issues and questions remain - see later. Description: The force-page-count property is handled by adding a method to the PageSequenceLayoutManger, because there are is a method that has all informations (static content, pagenumber, ...) about creating a new page (makeNewPage). The main problem was that the force-page-count property needs the initial-page-number of the next page-sequence which does not exist at this time. I solved this by preserving the current PageSequenceLayoutManger after the end of the page-sequence. I used the Root object for this because the last pagenumber of the sequence and other informations are also handed over this object from one page-sequence to the other. At the beginning of the following page-sequence the (stored) previous PageSequenceLayoutManger is called with the now current PageSequence object to finish this work. Changes to Root.java: - insert the variable previousPageSeqLM to store a PageSequenceLayoutManger for later use (and import the necessary class definition). Changes to PageSequenceLayoutManger.java: - split off the last part of activateLayout into a separate method (finishLeayout) because i need the same functionality after the force-page-count handling. - preserve the current PageSequenceLayoutManger object to the Root object at the end of the finishLayout method. - implement the force-page-count propterty in the checkForcePageCount method. This method needs the next PageSequence object as parameter. To get the initial-page-number property of this next page-sequence i copied the code from PageSequence.initPageNumber. Changes to PageSequence.java: - call the checkForcePageCount method of the preserved previous PageSequenceLayoutManger inside the startOfNode method immediately before initPageNumber so that this method is waware of possibly inserted pages of the previous page-sequence. - insert a getFocePageCount method to get the private variable. - insert a getInitialPageNumber method to get the private variable. Open issues / questions: - i think it very likely that the previousPageSeqLM variable of the Root class should be privat and there should be a setPreviousPageSeqLM and a getPreviousPageSeqLM method to hand the variable into and out of the object. - there was a second possiblity to implement this all by using the AreaTreeHandler: * instead of saving the PageSequenceLayoutManger object at the end of the finishLayout method of the PageSequenceLayoutManger it could be preserved at the end of the endPageSequence method of the AreaTreeHandler. * instead of calling the checkForcePageCount from the startOfNode method of PageSequence it could be called from the startPageSequence method of the AreaTreeHandler after receiving the rootFObj. * all other could be left nearly as with this patch with the exception that the startingPageNumber of the PageSequence has to be recalced after calling the checkForcePageCount because it is already calced at this point and does not know about possibly inserted pages from the checkForcePageCount method before. someone who has a more overall sight of the code has to decide where it fits best. I know the force-page-count property is of low priority, but it would be nice to get feedback, if someone can spare time to have a look at this patch. I hope i was not too verbose ;-) and that my patch is more usefull than the review is time-consuming and that i dont violate too much design guidelines. happy new year gerhard -- 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.
