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=39777>. 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=39777 ------- Additional Comments From [EMAIL PROTECTED] 2006-07-25 08:28 ------- (In reply to comment #7) Thanks for your comments, Simon. A few answers: > 2. Wiki page: The argument for an inner class in bullet 3 only refers > to an object inner class. Therefore contradicts bullet 4, a static > inner class, and is invalid. Well, the private fields of any ProgressInfo instance are directly accessible within OutOfLineRecord. This avoids using getter and setter methods everywhere in OutOfLineRecord, for the progressInfo field as well as the prevProgress parameters of the get[Footnote|Float]Split methods. That's what I meant. > 3. fo:float seems to be the only FO that can be placed in inline and > block content. This causes a problem because FOP distinguishes > between inline and block LMs rather much. I do not think that this > problem needs to be solved in this project. It should be fine to > make an implementation which works for inline fo:float FOs. Ok, noted. On the tests I've done this seems to work, but I don't know if it will in all cases. I think the solving of this problem may be done together with the implementation of the keep-with-previous property for the anchor element. I put it on my TODO-list. > 4. Infos is not correct english; better call it > ProgressInfo. cumulatedLengths is better changed to > cumulativeLengths. Thanks, always glad to improve my english ;-) > 5. The implementation does not use the max and min property of the BPD > of a float. In a text with little stretch and shrink, e.g. an > adapted version of the test file footnote_basic.xml, there is no > possibility to place the floats with less than infinite badness, > and they are moved towards the end of the page sequence. Yes. If I'm correct the shrink/stretch capabilities of footnotes aren't considered either. More generally there is a problem with too short nodes (considered as such because no stretching is possible), which are handled separately from the other nodes. The algorithm may prefer a normal node with a deferred float instead of a "too short" node with the float on the same page. I'm thinking about an improved algorithm which would handle such cases. I think I will give some ideas on the Wiki page soon, after I've submitted testcases. But before implementing it I'll perhaps work on side-floats, don't know yet. > 6. The OutOfLineRecord.getFootnoteSplit and > OutOfLineRecord.getFloatSplit methods suggest that there is room > for two subclasses. It would be nice if the two conditional blocks > in PageBreakingAlgorithm.computeDifference, if (floats.existing()) > and if (footnotes.existing()) could be merged, and the difference > in the logic be moved to the footnotes and floats objects. But that > is finishing touch. I agree (that some further refactoring is possible). As this part of the code may change if an improved algorithm is to be implemented, I didn't put too much effort in it. This will belong to a second refactoring step. Thanks, Vincent -- 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.
