[Fwd: Layout simplifications]
trying again... Original-Nachricht Betreff:Layout simplifications Datum: Mon, 16 May 2005 18:14:52 -0400 Von:Glen Mazza [EMAIL PROTECTED] An: fop-dev@xmlgraphics.apache.org Team, Currently the LM classes that use the Knuth breaking strategy employ the breaking via a nested (inner) class -- PageSequenceLayoutManager.PageBreaker, for example. This is causing some duplication in methods (getNextKnuthElements(), for example) and variables in each of the Breaker classes. Also, AbstractBreaker has to duplicate methods already available in AbstractLayoutManager because it does not extend it. What I would like to do is the following (step-by-step, not proceeding until each stage works): 1.) Have AbstractBreaker extend AbstractLayoutManager (ALM). 2.) Remove the PageBreaker inner class from PSLM, and have PSLM directly extend AbstractBreaker. Refactor and remove any duplicate methods and variables. 3.) Rename AbstractBreaker to AbstractBreakingLayoutManager (or similar). 4.) One by one, remove the nested inner classes from those other breaking LM classes: removing any duplicate methods or functionality already available in the base class, and having those classes extend ABLM instead of ALM. (Only those LM classes which do breaking will extend ABLM--the rest will continue with ALM.) 5.) Refactor/simplify AbstractBreakingLayoutManager, taking advantage of methods already available in AbstractLayoutManager. Refactor/simplify the ABLM-extended classes, again resulting from insights during this process. 6.) (possibly) Create a BreakingLayoutManager interface (extending LayoutManager interface?), just to keep note of the delta between ABLM and ALM. I think if we do this, it will allow for more simplifications and insights into the layout coding, and make it easier to understand. I don't think we can afford the duplication as-is--my experience so far with FOP is that simplifying engenders more simplifications, while lard ends up begetting more lard. Thoughts/comments? Thanks, Glen
Footnotes working!
Footnotes should be working now. At the moment the page breaking algorithm is quite strict: it tries to insert every footnote in the same page where their citation is (the last footnote body could be split, and partially deferred to the next page). The recommendation seems to suggest that it could defer one or more *whole* footnotes, if there is not enough space in the page where their citations are, even if this is not very usual to happen in books; anyway, this could be fixed later. Two annotations concerning the footnote separator: - is it correct to assume that the footnote separator is the same on each page containing footnotes, or it could have some page-dependant content? At the moment, its areas are obtained only once, and repeated in each page where a footnote is inserted. - I had to add a new StaticContentLM constructor with a Block area paremeter; maybe someone sees a better way to do this? The problem is that normal StaticContentLM add their areas to a Region, while the SCLM handling the footnote separator adds them to a block area (this is related to the previous point); another difference, non depending on the current implementation, is that the SCLM handling the footnote separator does not perform any breaking algorithm: it is quite similar to a BlockLM. Regards Luca
Layout simplifications
Team, Currently the LM classes that use the Knuth breaking strategy employ the breaking via a nested (inner) class -- PageSequenceLayoutManager.PageBreaker, for example. This is causing some duplication in methods (getNextKnuthElements(), for example) and variables in each of the Breaker classes. Also, AbstractBreaker has to duplicate methods already available in AbstractLayoutManager because it does not extend it. What I would like to do is the following (step-by-step, not proceeding until each stage works): 1.) Have AbstractBreaker extend AbstractLayoutManager (ALM). 2.) Remove the PageBreaker inner class from PSLM, and have PSLM directly extend AbstractBreaker. Refactor and remove any duplicate methods and variables. 3.) Rename AbstractBreaker to AbstractBreakingLayoutManager (or similar). 4.) One by one, remove the nested inner classes from those other breaking LM classes: removing any duplicate methods or functionality already available in the base class, and having those classes extend ABLM instead of ALM. (Only those LM classes which do breaking will extend ABLM--the rest will continue with ALM.) 5.) Refactor/simplify AbstractBreakingLayoutManager, taking advantage of methods already available in AbstractLayoutManager. Refactor/simplify the ABLM-extended classes, again resulting from insights during this process. 6.) (possibly) Create a BreakingLayoutManager interface (extending LayoutManager interface?), just to keep note of the delta between ABLM and ALM. I think if we do this, it will allow for more simplifications and insights into the layout coding, and make it easier to understand. I don't think we can afford the duplication as-is--my experience so far with FOP is that simplifying engenders more simplifications, while lard ends up begetting more lard. Thoughts/comments? Thanks, Glen
Re: Footnotes working!
On Tue, May 17, 2005 at 04:48:07PM +0200, Luca Furini wrote: Footnotes should be working now. Great. At the moment the page breaking algorithm is quite strict: it tries to insert every footnote in the same page where their citation is (the last footnote body could be split, and partially deferred to the next page). The recommendation seems to suggest that it could defer one or more *whole* footnotes, if there is not enough space in the page where their citations are, even if this is not very usual to happen in books; anyway, this could be fixed later. In linguistic or theological works you may see many and long footnotes. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Footnotes working!
Luca Furini wrote: The recommendation seems to suggest that it could defer one or more *whole* footnotes, if there is not enough space in the page where their citations are, even if this is not very usual to happen in books; Actually, this is *very* unusual, and can only happen if there is only a single line of content and all the footnote space is already eaten up, either by footnotes deferred from previous pages or because there are lots and/or very long footnotes in the same line. The common convention is that only a footnote cited in the last content line of the bage may be broken across pages, and no further footnote content will be deferred to the next page. In fact, breaking footnotes should be avoided if the content line citating the footnote can be put onto the next page withouth leaving an ugly white area below the content, either by distributing surplus bpd space to before/after block spaces or by fiddling with line heigths (or both). Duh, an example in the Wiki would be in order... J.Pietschmann
RE: Footnotes working!
-Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Hi Luca, First of all: compliments on yet another Nice Job! At the moment the page breaking algorithm is quite strict: it tries to insert every footnote in the same page where their citation is (the last footnote body could be split, and partially deferred to the next page). Well, that fits the largest part of the requirements... The recommendation seems to suggest that it could defer one or more *whole* footnotes, if there is not enough space in the page where their citations are, even if this is not very usual to happen in books; anyway, this could be fixed later. Optimistic interpretation: I think that is meant to refer to the cases where a footnote citation appears in the last block on a page, so it is not necessary to move the whole block to the next page just because a few of its footnotes don't fit. snip / - is it correct to assume that the footnote separator is the same on each page containing footnotes, or it could have some page-dependant content? At the moment, its areas are obtained only once, and repeated in each page where a footnote is inserted. AFAICT 'xsl-footnote-separator' is meant to be specified as the flow-name property on an fo:static-content, so in essence they are meant to be mostly the same for an entire fo:flow (~ fo:page-sequence), BUT... One thing I wonder about: Is it allowed to have sth like fo:static-content flow-name=xsl-footnote-separator fo:retrieve-marker .../ /fo:static-content In which case the content of the separator *would* be page-specific...? snip / Cheers, Andreas
More collapsing borders... (RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableContentLayoutManager.java)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Hi Jeremias and others interested in table-borders, (Sorry for the --again-- long post, but...) The following comment in the code (TCLM) got me wondering... //Create empty grid units to hold resolved borders of neighbouring cells //TODO maybe this needs to be done differently (and sooner) ... if we're on the same frequency here --and to avoid re-inventing the wheel ;-) Have you also considered --even if only partly-- normalizing table borders during the FOTree-building? (Or do you only mean 'sooner' in the layout process?) This is something I'm still pondering over, as, for instance the following fragment (supposing a collapsing model, easy case: no borders specified higher up): fo:table-row border=solid 4pt fo:table-cell border=solid 2pt !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row fo:table-row fo:table-cell border=solid 3pt !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row AFAICT could be expanded in one go into: (I'm not completely sure, but aren't the shorthands expanded internally? If so, can we use that to our advantage?) fo:table-row border-before=solid 4pt border-after=solid 4pt border-start=solid 4pt border-end=solid 4pt fo:table-cell border-before=solid 4pt border-after=solid 4pt border-start=solid 4pt border-end=... !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row fo:table-row border-before=solid 4pt border-start=solid 3pt fo:table-cell border-before=solid 4pt border-after=solid 3pt border-start=solid 3pt border-end=... !-- block content -- /fo:table-cell !-- more cells -- /fo:table-row Well, apart from a few liberties I may have taken here, I think the idea is clear enough that, *if* this could be pulled off, this may greatly simplify the related portions in the layout code... Evidently, at that point we would only be able to compare with cells that were previously read --events already occured--, so at first sight it only solves part of the problem, but anyway... In the simplest cases --i.e. no breaks and no spans-- the right border-widths need only be _read_ by the LM from the FObjs, and the LM only needs to decide whether to add (separated borders) or take into account the one with the highest precedence (collapsing borders). Further motivation: in principle, only the widths of the borders should be relevant to the layout code. The current fact that there's an explicit reference to the border-*styles* in an essentially layout-related class... Well, somehow it does not sit completely right with me --could be a matter of taste, but IMO, layout needs to concern itself only with sizes... The only real hard work in layout would be limited to the two difficult cases --breaks/spans--, but exactly because only these two would need to be handled during layout, they would become clearly outlined in the code --and because the lion's share of the decisions are already made before the LMs kick off, even this 'hard work' could turn out to be quite straightforward. What would it mean for layout if large parts of the 'determineWinner()' functionality would actually shift somewhere to the Property subsystem and the FOTree (? where they are ultimately still accessible to Layout if needed?) Anyway, the more I read the parts in the XSL-FO and CSS Rec about borders, the more I get the impression that the collapsing model works: - partly on the level of the bare properties/FOTree the question: which borders are dominant in the general cases? - and partly on the level of layout the question: what is the size of the space assigned to the applicable borders in this case? ATM it's only a thought. Just checking to see if, in anyone's opinion, it would be worth digging deeper into... if treating the above two questions separately helps to avoid (or even merely alleviate) certain headaches, all the better. Cheers, Andreas
Re: First performance comparison
Thanks for taking the time to do this analysis. I was wondering where we were standing on performance. I think it is clear from the 12sec-7.8 sec drop that keeping logging/stdout output reduced helps performance. Keeping quiet seems to be Xalan's approach as well. I looked at our commericial competitors' sites to see where they are with logging. It appears RenderX doesn't log by default but it has a server-side EnMasse product[1] which does configurable logging. AntennaHouse apparently just uses stdout/stderr[2], but I don't know how much output it produces while running. Since the logging level is nonconfigurable, I would suspect not much. Glen [1] http://www.renderx.com/enmasseguide.html [2] http://www.antennahouse.com/support/qa/QA-product.html#QA2003082202 Jeremias Maerki wrote: I've just run readme.fo (from the examples) through both 0.20.5 and CVS HEAD, 20 times in 1 thread, to satisfy my curiosity. I don't want to hide these numbers from you: 0.20.5 takes 6.3 seconds for that. CVS HEAD took over 12 seconds at the beginning but spitting out lots of debug messages. After converting the System.out calls to log.debug calls and setting the log level to SEVERE, the time went down to 7.8 seconds. A subjective impression I had was that CVS HEAD took longer to warm up (i.e. classloading plus initialitation). readme.fo is a document that except for references looks fine in both versions, although CVS HEAD produces one page more (11 instead of 10). It looks like the line heights differ quite a bit. For all those who'd say now that the new FOP is too slow, I'm going somewhere else (or something like that), bear in mind this is all preliminary and based on non-optimized code and work in progress. I was simply curious and I'm sure others are, too. At least, we can say, it's not that bad and nothing is lost. :-) More later, probably with measurements with tables and on memory consumption. Jeremias Maerki
