Re: Start using *-position traits?
Well, this might have been a bit premature. The change necessary actually fixed a bug in AbstractRenderer, but still it might be worth discussing the point. On 04.02.2005 15:51:58 Jeremias Maerki wrote: Team, Chapter 4.2.2 Common Traits defines four traits (top-position, bottom-position, left-position, right-position) which describes the placement of areas within the nearest ancestor reference-area (or the page-viewport-area). We don't use these trait but recreate the placement of individual areas in the renderer (actually and effectively in each (!) renderer). I wondered a few times during the last month if we should have the layout manager handle the calculation of the coordinates. This has a few advantages: - All layout is really in the layout managers. - Each renderer really only paints the areas in the place it is told to. The obvious disadvantage is the effort needed to write the code that generates these traits in all layout managers. The reason I'm bringing this up now is my attempt to implement table row backgrounds where I don't manage to place the background areas in the right places due to placement logic in the renderer(s). Of course, there are work-arounds and I only have to fix AbstractRenderer in this case but it doesn't feel right. There's already enough placement logic in the PDFRenderer which needs to be duplicated in all other renderers. I can also remember the synchronization effort when I wrote the original PSRenderer. I think it would also simplify the renderers itself, making it easier to develop a new one, if we started using left-position and top-position traits. The other two may be necessary as soon as there's more effort towards implementing writing-modes. Keiron responded to a similar question in 2002: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=214823 I don't share his opinion on point 3 because whenever we have a change in reference-orientation we also have a new reference-area which establishes a new coordinate system. So I don't think it will be complicated to calculate the right coordinates. But I may be wrong. Opinions? Jeremias Maerki
RE: Start using *-position traits?
Jeremias Maerki wrote: Chapter 4.2.2 Common Traits defines four traits (top-position, bottom-position, left-position, right-position) which describes the placement of areas within the nearest ancestor reference-area (or the page-viewport-area). We don't use these trait but recreate the placement of individual areas in the renderer (actually and effectively in each (!) renderer). I wondered a few times during the last month if we should have the layout manager handle the calculation of the coordinates. This has a few advantages: - All layout is really in the layout managers. - Each renderer really only paints the areas in the place it is told to. The obvious disadvantage is the effort needed to write the code that generates these traits in all layout managers. The reason I'm bringing this up now is my attempt to implement table row backgrounds where I don't manage to place the background areas in the right places due to placement logic in the renderer(s). Of course, there are work-arounds and I only have to fix AbstractRenderer in this case but it doesn't feel right. There's already enough placement logic in the PDFRenderer which needs to be duplicated in all other renderers. I can also remember the synchronization effort when I wrote the original PSRenderer. I think it would also simplify the renderers itself, making it easier to develop a new one, if we started using left-position and top-position traits. The other two may be necessary as soon as there's more effort towards implementing writing-modes. Keiron responded to a similar question in 2002: http://nagoya.apache.org/eyebrowse/BrowseList?listName=fop-dev @xml.apache.orgby=threadfrom=214823 I don't share his opinion on point 3 because whenever we have a change in reference-orientation we also have a new reference-area which establishes a new coordinate system. So I don't think it will be complicated to calculate the right coordinates. But I may be wrong. Opinions? Hi Jeremias: It is fascinating to me how many times you and I happen to be working on exactly the same issue, as we are right now. FWIW, the FOray approach is as follows: Areas do not store any location information at all. The only size information stored is a progressionDimension value and a value for the resolved anteriorSpace. This is enough information, however, for each Area to compute and return to the Renderer where it should be rendered. Every Area either is or has an ancestor area that knows intrinsically what its location is just from its properties. Every Area knows its own IPD and BPD. So by considering the progressionDimension and anteriorSpace (the resolved value of space-before/after or space-start/end) of other Areas already stacked in the containing Area, any Area knows its location. Keiron is right that the computations are tricky for changes in reference-orientation and writing-mode, but I think dealing with them in the Area tree once is much easier than any other approach I can imagine. My code currently has the various writing-modes handled correctly (I think), but doesn't yet deal with changes in writing-mode or reference-orientation. The main reason I haven't tackled that yet is that I am still trying to decide how much of that work belongs in Area Tree and how much needs to be considered Renderer-specific. With this scheme, Layout never has to worry about location, orientation, or writing-mode, only sizes (IPD and BPD). Renderers don't have to compute any of them either, they just ask each Area where it wants to be rendered. In short, I think you are very much on the right track here. One caveat: I don't have all of my stuff working yet, so there may be a gotcha that I haven't thought of. If these comments are not helpful, please let me know. I don't mean to generate noise -- I just like to support good ideas when I see them. Victor Mote
Re: Start using *-position traits?
Thanks for sharing your thoughts, Victor. For the moment I've got my issue solved but as I already said, it may be beneficial to reconsider the approach here. I'll wait and see what the others have to say about it. You popping up again reminds me that I still have an issue on my task list: Making an integration of Foray into my JAFOP thingy. I'm quite interested in comparing FOP 1.0dev with other implementations as I go. Gotta find some time... On 04.02.2005 18:04:24 Victor Mote wrote: Jeremias Maerki wrote: Chapter 4.2.2 Common Traits defines four traits (top-position, bottom-position, left-position, right-position) which describes the placement of areas within the nearest ancestor reference-area (or the page-viewport-area). We don't use these trait but recreate the placement of individual areas in the renderer (actually and effectively in each (!) renderer). I wondered a few times during the last month if we should have the layout manager handle the calculation of the coordinates. This has a few advantages: - All layout is really in the layout managers. - Each renderer really only paints the areas in the place it is told to. The obvious disadvantage is the effort needed to write the code that generates these traits in all layout managers. The reason I'm bringing this up now is my attempt to implement table row backgrounds where I don't manage to place the background areas in the right places due to placement logic in the renderer(s). Of course, there are work-arounds and I only have to fix AbstractRenderer in this case but it doesn't feel right. There's already enough placement logic in the PDFRenderer which needs to be duplicated in all other renderers. I can also remember the synchronization effort when I wrote the original PSRenderer. I think it would also simplify the renderers itself, making it easier to develop a new one, if we started using left-position and top-position traits. The other two may be necessary as soon as there's more effort towards implementing writing-modes. Keiron responded to a similar question in 2002: http://nagoya.apache.org/eyebrowse/BrowseList?listName=fop-dev @xml.apache.orgby=threadfrom=214823 I don't share his opinion on point 3 because whenever we have a change in reference-orientation we also have a new reference-area which establishes a new coordinate system. So I don't think it will be complicated to calculate the right coordinates. But I may be wrong. Opinions? Hi Jeremias: It is fascinating to me how many times you and I happen to be working on exactly the same issue, as we are right now. FWIW, the FOray approach is as follows: Areas do not store any location information at all. The only size information stored is a progressionDimension value and a value for the resolved anteriorSpace. This is enough information, however, for each Area to compute and return to the Renderer where it should be rendered. Every Area either is or has an ancestor area that knows intrinsically what its location is just from its properties. Every Area knows its own IPD and BPD. So by considering the progressionDimension and anteriorSpace (the resolved value of space-before/after or space-start/end) of other Areas already stacked in the containing Area, any Area knows its location. Keiron is right that the computations are tricky for changes in reference-orientation and writing-mode, but I think dealing with them in the Area tree once is much easier than any other approach I can imagine. My code currently has the various writing-modes handled correctly (I think), but doesn't yet deal with changes in writing-mode or reference-orientation. The main reason I haven't tackled that yet is that I am still trying to decide how much of that work belongs in Area Tree and how much needs to be considered Renderer-specific. With this scheme, Layout never has to worry about location, orientation, or writing-mode, only sizes (IPD and BPD). Renderers don't have to compute any of them either, they just ask each Area where it wants to be rendered. In short, I think you are very much on the right track here. One caveat: I don't have all of my stuff working yet, so there may be a gotcha that I haven't thought of. If these comments are not helpful, please let me know. I don't mean to generate noise -- I just like to support good ideas when I see them. Victor Mote Jeremias Maerki
