Re: Implementing Change bars
Hi Stephan, Stephan Thesing wrote: Hello, snip/ My idea is now along the following lines: - Remember for each element during parsing the change bars it is influenced by. - After layout, go over all areas produced by those influenced elements and add the areas for the change bars (thus, only an area with proper border attributes). It all depends on how this is implemented, therefore I’m awaiting your patch. But that seems to imply a two-pass process that I’m not sure we want. Imagine a change-bar that starts on page 2 and ends on page 50. We don’t want to wait that the areas for page 50 have been created to add the change-bar areas on page 2. I don't pretend to really understand the layout in FOP yet, but my basic understanding was: - As soon as a page-sequence has been parsed, it is layouted, the layout managers are created. - When a page has been filled (approx), little adaptations are done, the area tree for that page is complete and can be rendered. This doesn’t exactly happen like this, although that doesn’t change much of what you would have to do. FOP implements a total-fit algorithm. Basically, instead of creating one page at a time, it optimises the layout over the whole page sequence. It does so by playing with elastic spaces between blocks in order to homogenise pages. Suppose that a big unbreakable block doesn’t fit on page 10 and must be deferred to page 11. By slightly increasing vertical spaces between earlier blocks, content can progressively be shifted to the following page until page 10 is reached, and fill up that latter instead of leaving it half empty. So the actual layout of page 1 may actually not be known until the very end of the page sequence has been reached. I must actually refine my concern above: at the moment, a two-pass process would degrade performance only if a change-bar encompasses several page sequences, which I guess would rarely happen. Still, if later on we want to implement a lower quality, lower resource demanding layout process, we wouldn’t want such a two-pass process. snip/ BTW, as far as I understand FOP, the area tree is never used for RTF output, but rather the event mechanism is used, that notifies the RTF backend for start/end of fo elements, which are then directly transfered into RTF. Thus, the change bar stuff tied to the areas will not work for RTF and extra code has to be added to the RTF backend to handle the change bars. If you don’t need change bars for RTF output, then don’t worry about it. If that were depending only on me the RTF backend would have been deprecated long time ago :-) It doesn’t fit well in the rest of FOP and anyway is no longer so much useful now that ODF, among others, is around. Vincent
Re: Implementing Change bars
On 03 Sep 2009, at 22:07, Stephan Thesing wrote: Hi Stephan, snip / Seems reasonable, although... validateChildNode() is more meant to take care of very specific cases, mentioned in the definition of the content model. Now I'm thinking: a change-bar-* is a neutral item that is basically allowed anywhere, except as a child/descendant of a very limited set of FOs that cannot appear as descendants of an fo:flow or fo:static-content. The requirement of a flow/static-content ancestor is specific to the change-bar-* nodes, not to their parent/ancestor, so I'm not entirely sure whether FObj is the right place to enforce that rule... Yes, that rule is enforced in the ChangeBar class' startNode(), which is the base class for the ChangeBarBegin and ChangeBarEnd classes. But the validateChildNode() has to accept change-bar-begin and change-bar-end children for all nodes in order to allow them to occur at the allowed places. For the answer to this, see the pointer I gave about 'isNeutralItem()'. That's basically ALL that really needs to be modified in FObj AFAICT. Regards, Andreas Delmelle mailto:andreas.delmelle.AT.telenet.be jabber: mandr...@jabber.org skype: adlm0608 ---
Re: Implementing Change bars
Hi Stephan, Stephan Thesing wrote: Hello, just a short status / question update. snip/ What remains is layout and producing the change bar areas. If I read the spec right, the intended semantics of the change-bar-elements is the following: - for all elements generating areas that are under the influence of a change bar, add fixed areas as tall as the generated areas and placed beside the column of that area as given by the change bar properties. - being under the influence of a change bar is defined by the file order of elements in the input. I.e., any element between a change-bar-start and corresponding change-bar-end (same class) is influenced by that change bar. For me, that means that an element can be under the influence of multiple change bars, naturally. The area tree described in the Recommendation is non-normative, therefore we are free to deviate from it as long as the final visual result is the same. And I’m actually not keen on the idea of generating a change-bar area for /each/ area under the influence of a change bar. This will give many overlapping areas (for example an fo:block produces a normal area, plus possibly a line-area, which will itself contain many inline areas. If a change-bar area must be generated for each of them...). The visual result is likely to look non-continuous, as the borders of a table for which we have already had complaints. Ideally a single area would be generated on each column. My idea is now along the following lines: - Remember for each element during parsing the change bars it is influenced by. - After layout, go over all areas produced by those influenced elements and add the areas for the change bars (thus, only an area with proper border attributes). It all depends on how this is implemented, therefore I’m awaiting your patch. But that seems to imply a two-pass process that I’m not sure we want. Imagine a change-bar that starts on page 2 and ends on page 50. We don’t want to wait that the areas for page 50 have been created to add the change-bar areas on page 2. Can this be realizes in such a way in FOP? To be honest I don’t have a precise idea of how to implement that in FOP. But maybe that could be done using some kind of listener. An event would be generated when a change-bar-begin is encountered. It would be handled by ‘the proper LayoutManager’ that would record the current offset from the top of the applicable reference-area. Once the ‘change-bar-end’, ‘bottom-of-column’ or ‘end-of-document’ event occurs, it creates the change-bar area. Where should that code be put? Good question... PageBreaker maybe, although StaticContentLM must also do something. Moreover, change-bar areas must also be produced for out-of-line areas like footnotes, returned by objects that are under the influence of the change-bar. I appreciate any comments and suggestions! Hoping the above gives you some hints, Vincent
Re: Implementing Change bars
Hello, Yep, that's what I was referring to, and AFAICT, it is not mandated that the change-bar-begin and the corresponding change-bar-end appear in the same flow/page-sequence. yes, it can occur across page-sequences, etc. Seems reasonable, although... validateChildNode() is more meant to take care of very specific cases, mentioned in the definition of the content model. Now I'm thinking: a change-bar-* is a neutral item that is basically allowed anywhere, except as a child/descendant of a very limited set of FOs that cannot appear as descendants of an fo:flow or fo:static-content. The requirement of a flow/static-content ancestor is specific to the change-bar-* nodes, not to their parent/ancestor, so I'm not entirely sure whether FObj is the right place to enforce that rule... Yes, that rule is enforced in the ChangeBar class' startNode(), which is the base class for the ChangeBarBegin and ChangeBarEnd classes. But the validateChildNode() has to accept change-bar-begin and change-bar-end children for all nodes in order to allow them to occur at the allowed places. Thus, as I see it, either this has to be added to all validateChildNode() methods, or validation of children for an arbitrary element has to be split in checking for elements that may always be children (the change bars currently) and element specific checks mandated by the content model of each node. I used the later approach. If all elements that may be in a flow call a common validateChildNode() (via super()), then the code could be moved there (I didn't check). Best regards... Stephan -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: Implementing Change bars
Hello, The area tree described in the Recommendation is non-normative, therefore we are free to deviate from it as long as the final visual result is the same. And I’m actually not keen on the idea of generating a change-bar area for /each/ area under the influence of a change bar. This will give many overlapping areas (for example an fo:block produces a normal area, plus possibly a line-area, which will itself contain many inline areas. If a change-bar area must be generated for each of them...). The visual result is likely to look non-continuous, as the borders of a table for which we have already had complaints. Ideally a single area would be generated on each column. yes, this would be merging of the generated areas, which should be easy enough. My idea is now along the following lines: - Remember for each element during parsing the change bars it is influenced by. - After layout, go over all areas produced by those influenced elements and add the areas for the change bars (thus, only an area with proper border attributes). It all depends on how this is implemented, therefore I’m awaiting your patch. But that seems to imply a two-pass process that I’m not sure we want. Imagine a change-bar that starts on page 2 and ends on page 50. We don’t want to wait that the areas for page 50 have been created to add the change-bar areas on page 2. I don't pretend to really understand the layout in FOP yet, but my basic understanding was: - As soon as a page-sequence has been parsed, it is layouted, the layout managers are created. - When a page has been filled (approx), little adaptations are done, the area tree for that page is complete and can be rendered. Here, as soon as the page has been really created, one can add the change bar areas to it and render it. The general problem with the change bars is that they don't create any areas in themselves but rather add a property to each fo element between the begin and end marker. That property being that a change bar should accompany the element. Thus, they are initially an element related property. If such an influenced element creates several areas when being layouted, all areas have to be accompanied by change bars. Thus, we have to wait, until the areas of the influenced elements have been created, which (my understanding) is when a page layout has been finished (the page created with the areas on it). Only then can we know the vertical positions of the areas, which are needed for the change bar areas. I may be missing something here:-) Can this be realizes in such a way in FOP? To be honest I don’t have a precise idea of how to implement that in FOP. But maybe that could be done using some kind of listener. An event would be generated when a change-bar-begin is encountered. It would be handled by ‘the proper LayoutManager’ that would record the current offset from the top of the applicable reference-area. Once the ‘change-bar-end’, ‘bottom-of-column’ or ‘end-of-document’ event occurs, it creates the change-bar area. I have to look into that:-) Where should that code be put? Good question... PageBreaker maybe, although StaticContentLM must also do something. Moreover, change-bar areas must also be produced for out-of-line areas like footnotes, returned by objects that are under the influence of the change-bar. Thanks for your comments! BTW, as far as I understand FOP, the area tree is never used for RTF output, but rather the event mechanism is used, that notifies the RTF backend for start/end of fo elements, which are then directly transfered into RTF. Thus, the change bar stuff tied to the areas will not work for RTF and extra code has to be added to the RTF backend to handle the change bars. Best regards... Stephan -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
Re: Implementing Change bars
Hello, just a short status / question update. I have added the fo:change-bar-begin/end elements with their properties. Validation is also implemented, but: - In contrast to the other fo: elements, the change-bar-* elements are allowed to occur everywhere, as long as they have an fo:flow or fo:static-content ancestor. All the elements do their content validation via validateChildNode() (e.g. Block.java in o.a.fop.fo.flow). As I didn't want to add acceptance of change-bar-* children to all fo: elements under o.a.fop.fo.flow, I added to FNode.java a validateChildNodeGlobal() function that performs the global check for change-bar-* children and then calls validateChildNode() to perform the local check for each element. in FOTreeBuilder.java this is then called instead of validateChildNode(). The version of validateChildNodeGlobal() applicable for change bars is added in FObj.java Validation of the stacking constraints of change-bar-begin and -end are also done. Error messages and codes for validation errors are also already added. What remains is layout and producing the change bar areas. If I read the spec right, the intended semantics of the change-bar-elements is the following: - for all elements generating areas that are under the influence of a change bar, add fixed areas as tall as the generated areas and placed beside the column of that area as given by the change bar properties. - being under the influence of a change bar is defined by the file order of elements in the input. I.e., any element between a change-bar-start and corresponding change-bar-end (same class) is influenced by that change bar. For me, that means that an element can be under the influence of multiple change bars, naturally. My idea is now along the following lines: - Remember for each element during parsing the change bars it is influenced by. - After layout, go over all areas produced by those influenced elements and add the areas for the change bars (thus, only an area with proper border attributes). Can this be realizes in such a way in FOP? I appreciate any comments and suggestions! I will be able to produce a first diff of my code this weekend. Best regards... Stephan - retrieving the start- and end locations of the bars during layout (org.apache.fop.layoutmgr) - creating the appropriate areas (will probably have to be done in o.a.f.layoutmgr.PageSequenceLayoutManager) That should be enough to get you started. If you have any question, see you on fop-dev! Vincent -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
Re: Implementing Change bars
On 02 Sep 2009, at 20:22, Stephan Thesing wrote: Hi Stephan just a short status / question update. I have added the fo:change-bar-begin/end elements with their properties. Validation is also implemented, but: - In contrast to the other fo: elements, the change-bar-* elements are allowed to occur everywhere, as long as they have an fo:flow or fo:static-content ancestor. Yep, that's what I was referring to, and AFAICT, it is not mandated that the change-bar-begin and the corresponding change-bar-end appear in the same flow/page-sequence. All the elements do their content validation via validateChildNode() (e.g. Block.java in o.a.fop.fo.flow). As I didn't want to add acceptance of change-bar-* children to all fo: elements under o.a.fop.fo.flow, I added to FNode.java a validateChildNodeGlobal() function that performs the global check for change-bar-* children and then calls validateChildNode() to perform the local check for each element. in FOTreeBuilder.java this is then called instead of validateChildNode(). The version of validateChildNodeGlobal() applicable for change bars is added in FObj.java Seems reasonable, although... validateChildNode() is more meant to take care of very specific cases, mentioned in the definition of the content model. Now I'm thinking: a change-bar-* is a neutral item that is basically allowed anywhere, except as a child/descendant of a very limited set of FOs that cannot appear as descendants of an fo:flow or fo:static-content. The requirement of a flow/static-content ancestor is specific to the change-bar-* nodes, not to their parent/ancestor, so I'm not entirely sure whether FObj is the right place to enforce that rule... A common superclass ChangeBarNode for ChangeBarBegin and ChangeBarEnd could take care of that 'validation' in its processNode() implementation. The stacking-validation could probably be performed in the same go. No changes necessary so high up in the class hierarchy. To trigger correct validation when the eventual (parent) FObj calls its validateChildNode() method, all that needs to be altered there, is the addition of change-bar-begin and change-bar-end to the isNeutralItem() method. Validation of the stacking constraints of change-bar-begin and -end are also done. Error messages and codes for validation errors are also already added. What remains is layout and producing the change bar areas. If I read the spec right, the intended semantics of the change-bar- elements is the following: snip / For me, that means that an element can be under the influence of multiple change bars, naturally. Indeed, and if no offset is specified the bars will be drawn over each other. snip / I'll get back on your further ideas ASAP. Regards, Andreas Delmelle mailto:andreas.delmelle.AT.telenet.be jabber: mandr...@jabber.org skype: adlm0608 ---
