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.org&by=thread&from=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
