I've attached the picture and an FO file I wrote today to mimic that picture.
BTW, the pictures worked fine for me the whole day. They are all here: http://people.apache.org/~jeremias/fop/ Alternatively, if you log into cvs.apache.org you can cd into /x1/home/jeremias/public_html/fop to get them. On 03.05.2005 19:40:39 Andreas L. Delmelle wrote: > > -----Original Message----- > > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > > > > Hi, > > <snip /> > > BTW: Am I the only one who has trouble viewing the pictures on the wiki > page? (It seems to be the only one with which I have problems. The other > table-related pages show up nicely...) > > > That also means that it's making the whole border resolution a lot more > > complicated. If you started with the upper left cell and tried to > > determine the after border you can end up taking the after border > > specification from the cell on the right side of the cell. > > Are you talking about what our current implementation *would* end up taking > as after border, or what *should* be taken as after border according to the > spec? *should* :-( > In the latter case, if you mean 'start/end', I'm game, but I don't see how > the 'after' border of the first cell to the right of a given cell could > influence the 'after' border of that cell... If the "border is determined, > for each segment, at the cell level" that seems to mean a decision at the > cell level between: > > - table > - body (header / footer) > - column > - row > - neighbouring cells > * start ~ border-end of first cell to the left > * end ~ border-start of first cell to the right > * before ~ border-after of first cell above > * after ~ border-before of first cell below > - the cell itself > > for each of the border segments: start - before - end - after > > One optimistic note: all of the above options can't be an option at the same > time for one and the same cell... and the decision between row borders and > table borders, for instance, could already be resolved at row level, such > that, when the borders are determined at cell level, the cell only needs to > query the row, column and neighbouring cells (not reach back up to the body > and table). Got to think that through first. It might speed things up a little. > > But before I turn everything upside-down again, can please someone > > confirm that I was really wrong before and got it right now? Thanks a > > lot. > > If I could only see the images... > > > Cheers, > > Andreas Jeremias Maerki
Description: Binary data