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.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 Jeremias Maerki
