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.
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 31, 2005, at 17:02, Andreas L Delmelle wrote: (been pondering a bit more over this, and...) Et voilà, that seems to be where the real *flaw* is located, if you ask me. It should care about glues at the beginning of a line -- which it seems to handle perfectly ATM-- In fact, this may currently be handled 'too perfectly'. One of the testcases --block_white-space_2.xml-- fails because a leading non- breaking space is removed, contrary to the expectation. Don't get me wrong. I still think that it is unnecessary to remove the mentioned trailing white-space for trailing nested inlines in a paragraph in the FOTree. Only, I think I'm beginning to see what is meant by this paradox: Besides that, I get the impression you're somewhat contradicting yourself here: - in the comment on the failing testcase you noted that 'These tests fail because the Knuth element sequences for consecutive whitespace are not correct.' - and now you're saying that it's not a matter of generating the correct element sequences The flaw here is that, IIC, the element sequences generated for nbsp are basically the same as for a common space, leading to the exact same type of area being (or not being) added to the Area Tree (= space .../) Somewhere the decision has to be made: do we or do we not add an area for this box/element? It's precisely there that the algorithm should make the evaluation, taking into consideration the white-space related properties and the underlying character's suppress-at-line- break property. Would this be a correct assessment? 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 Sun, 1 Jan 2006 12:02 am, Andreas L Delmelle wrote: On Dec 31, 2005, at 16:05, Manuel Mall wrote: The possible problem I saw with the block-level white-space handling was that all white-space characters would continue to take up memory until the first nested block or in the worst case, until the end-of- block. In case of large blocks with lots of indents due to pretty- printing, the current approach makes these spaces disappear much sooner (= more memory-efficient). Andreas, you can't be serious here. Keeping a few whitespace characters until the end of a block is reached is completely irrelevant with respect to FOPs memory consumption and should not play even the slightest consideration when comes to choice of algorithm. If this is the only reason which stops you from doing end of paragraph line-feed-treatment during refinement then please revise the algorithm to do so. snip/ Cheers, Andreas 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 Sun, 1 Jan 2006 10:22 pm, Andreas L Delmelle wrote: On Dec 31, 2005, at 17:02, Andreas L Delmelle wrote: (been pondering a bit more over this, and...) Et voilà, that seems to be where the real *flaw* is located, if you ask me. It should care about glues at the beginning of a line -- which it seems to handle perfectly ATM-- In fact, this may currently be handled 'too perfectly'. One of the testcases --block_white-space_2.xml-- fails because a leading non- breaking space is removed, contrary to the expectation. Don't get me wrong. I still think that it is unnecessary to remove the mentioned trailing white-space for trailing nested inlines in a paragraph in the FOTree. Only, I think I'm beginning to see what is meant by this paradox: Besides that, I get the impression you're somewhat contradicting yourself here: - in the comment on the failing testcase you noted that 'These tests fail because the Knuth element sequences for consecutive whitespace are not correct.' - and now you're saying that it's not a matter of generating the correct element sequences You still don't seem to quite get my point. The Knuth algorithm (read the paper) deals only with box/pen/glue for the purpose of breaking lines and if it breaks a line it takes certain actions with respect to discarding pen/glue elements directly following the break it created. If it doesn't create a line break it leaves everything as it is. This means everything at the beginning and end of a paragraph is left untouched. line-feed-treatment at the beginning and end of a paragraph is not influenced by the Knuth algorithm and therefore cannot be controlled by whatever sequences we generate. We can control line-feed-treatment at Knuth generated breaks by constructing the proper sequences which we will do eventually. But start/end paragraph is outside of that which is why I am keen to push it into the FO refinement stage (as it used to be). Would this be a correct assessment? Cheers, Andreas 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 Jan 1, 2006, at 17:15, Manuel Mall wrote: The Knuth algorithm (read the paper) deals only with box/pen/glue for the purpose of breaking lines and if it breaks a line it takes certain actions with respect to discarding pen/glue elements directly following the break it created. If it doesn't create a line break it leaves everything as it is. This means everything at the beginning and end of a paragraph is left untouched. line-feed-treatment at the beginning and end of a paragraph is not influenced by the Knuth algorithm and therefore cannot be controlled by whatever sequences we generate. Ahem... I do get your point, but the fact of the matter remains that the trailing spaces should be removed for the reason that they would end up at the end of a *line-area*, not because they end up at the end of the *paragraph*. I have no trouble grasping the idea that the Knuth algorithm only creates effective breaks in intermediate positions, and takes certain actions for those breaks. Ok, so that means the start- or end-of- paragraph line-break is not created by this algorithm in itself, and remains out-of-scope here. Would it not be a much easier and much more straightforward solution to have every paragraph end with an infinitely low penalty, so that the algorithm eventually treats trailing spaces in the last line-area just the same as it would for 'normal' line-breaks? We can control line-feed-treatment at Knuth generated breaks by constructing the proper sequences which we will do eventually. But start/end paragraph is outside of that which is why I am keen to push it into the FO refinement stage (as it used to be). As I said, it's all the same to me. If you (and a few others, of course) think we were better off before I committed my changes, then by all means, go ahead and revert... I did my homework, and posted it as a patch for review first. As I recall, only Finn had anything to add, and his comment was taken into account. The rest of you remained silent, which I consider to be at least a '+0' (= go ahead if you want to, but don't expect any assistance from us, because we already have our hands full). Cheers, Andreas
Bug report for Fop [2006/01/01]
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) |
| | +-+
| | | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| | | MIN=Minor NOR=Normal ENH=Enhancement |
| | | +-+
| | | | Date Posted |
| | | | +--+
| | | | | Description |
| | | | | |
| 635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence |
| 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t|
| 1063|New|Nor|2001-03-21|fop does not handle large fo files|
| 1180|New|Maj|2001-04-02|Problem with monospaced font |
| 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r|
| 1998|New|Nor|2001-06-05|linefeed-treatment not understood |
| 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl|
| 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row|
| 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly |
| 2909|New|Maj|2001-07-30|Gradient render error |
| 2964|Ass|Nor|2001-08-02|problems with height of cells in tables |
| 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work |
| 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body |
| 3497|New|Cri|2001-09-07|id already exists error when using span=all attr|
| 3824|New|Blk|2001-09-25|MIF option with tables|
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts |
| 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work |
| 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D|
| 4415|New|Nor|2001-10-25|scaling=uniform does not work on images... |
| 4510|New|Nor|2001-10-30|fo:inline common properties ignored? |
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG |
| 4767|New|Nor|2001-11-09|SVG text is distored in PDF output|
| 5001|New|Nor|2001-11-21|content-width and content-height ignored? |
| 5010|New|Enh|2001-11-21|Better error reporting needed |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from |
| 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values |
| 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop|
| 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? |
| 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output|
| 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem|
| 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render |
| 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving|
| 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label|
| 6918|New|Enh|2002-03-06|reference-orientation has no effect |
| 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi|
| 7140|New|Enh|2002-03-15|page-position attribute set to last on condition|
| 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on|
| 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in |
| 7337|New|Nor|2002-03-21|border around external image leaves empty space |
| 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page |
| 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b|
| 7525|New|Cri|2002-03-27|table with spans inside a list-block |
| 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li|
| 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images |
| 8050|New|Nor|2002-04-13|Soft hyphen (shy;) is not handled properly |
| 8321|New|Nor|2002-04-19|from-parent('width') returns 0 for nested tables |
| 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende|
|
