Re: change bar status
I tried to apply your patch and its working great. Thanks for writing this. Currently for tables, it is rendering change-bar for each cell even if the change-bar is applied to entire row. Could you please provide some hints on what I need to change in the code, so that all the change-bar blocks in table are rendered in left-most part of table and not in the middle of page for a particular cell? As far as I could understand your code, it seems that I need to make that change in AbstractRenderer.java but I could not a method where I can place the change-bar to left-most part of table instead of appearing in the middle. Thanks in advance, Mandar -- View this message in context: http://apache-fop.1065347.n5.nabble.com/change-bar-status-tp31788p39064.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: change bar status
Stephan Thesing wrote: Dear all, sorry for the long delay in answering. Hi Stephan, thanks for looking into this! Change bars would be a useful feature addition to FOP. Having had some time in the last days to actually continue working on the change bar stuff: + parsing and validating the fo:change-bar-begin and fo:change-bar-end elements works (including properties) + attaching to all fo: elements that are between fo:change-bar-begin and fo:change-bar-end elements the vector of change bars that affect the element is implemented If I understand the FO standard right, then for each area generated by a FO object under the influence of a change bar, an area (with correct border-style/width/color... settings) has to be created as an xsl-absolute area and placed as determined by the change bar style relative to the column or page edge. For areas generated in the body-region, these additional areas are children of the flow area, for after/before/start/end they are children of the respective area region. If I understand the FOP code right, the areas are actually constructed by the various layout managers in addAreas(). That is my understanding too. Now, when creating the change-bar areas, one could for every area thus constructed, add a change bar area at the correct position in the area tree. But, it is desireable to merge change bar areas, because many areas will simply be the same or be adjacent to each other down the page side and should thus be represented as a single area representing the union of these areas (as far as possible). Another point is that the change-bar areas have a z-Buffer trait that decides visibility of overlapping change bars: I am not sure how to handle that yet. Desirable yes, but I'm not sure it is essential. I would try to get it working without merging first and then evaluate if the solution is acceptable without merging and if so tackle merging as a later project. We can certainly help with the evaluation if you post into a bugzilla entry. Would it be best to really add the change bar areas when the originating areas are constructed and merge on the fly or would it be better to search for all change bar generating areas when the page is finished and then to perform the merge? Currently missing altogether are unit tests for the code I have added or changed. In short, we are getting somewhere. Thanks for the update. It is encouraging. Chris
Re: change bar status
Dear all, sorry for the long delay in answering. Having had some time in the last days to actually continue working on the change bar stuff: + parsing and validating the fo:change-bar-begin and fo:change-bar-end elements works (including properties) + attaching to all fo: elements that are between fo:change-bar-begin and fo:change-bar-end elements the vector of change bars that affect the element is implemented If I understand the FO standard right, then for each area generated by a FO object under the influence of a change bar, an area (with correct border-style/width/color... settings) has to be created as an xsl-absolute area and placed as determined by the change bar style relative to the column or page edge. For areas generated in the body-region, these additional areas are children of the flow area, for after/before/start/end they are children of the respective area region. If I understand the FOP code right, the areas are actually constructed by the various layout managers in addAreas(). Now, when creating the change-bar areas, one could for every area thus constructed, add a change bar area at the correct position in the area tree. But, it is desireable to merge change bar areas, because many areas will simply be the same or be adjacent to each other down the page side and should thus be represented as a single area representing the union of these areas (as far as possible). Another point is that the change-bar areas have a z-Buffer trait that decides visibility of overlapping change bars: I am not sure how to handle that yet. Would it be best to really add the change bar areas when the originating areas are constructed and merge on the fly or would it be better to search for all change bar generating areas when the page is finished and then to perform the merge? Currently missing altogether are unit tests for the code I have added or changed. In short, we are getting somewhere. Best regards Stephan Original-Nachricht Datum: Mon, 09 Nov 2009 18:09:06 +0900 Von: Carlos Villegas c...@uniscope.jp An: fop-dev@xmlgraphics.apache.org Betreff: change bar status There was some discussion about implementing change bars some weeks ago. What's the current status? Thanks, Carlos -- 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
