Re: Clarification for tables: grid units, border-resolution and breaks
Arun Kumar wrote: I am trying to do the following By hijacking Vincent's Thread, you have posted your question about FOP to the XSL Editors Please don't hijack threads and be careful who you post to! < fo:table-cell border-left-color="green" border-left-style="dotted" border-top-color="red" border-top-style="dotted" border-right-color="blue" border-right-style="dotted" border-bottom-color="yellow" border-bottom-style="dotted" in fop-0.20.5 , also tried the dashed but it is taking only solid as border of cell not dotted or dashed, FOP 0.20.5 does not implement dashed or dotted borders. How we can make the cell border dashed or dotted, is it a known bug or i am missing some thing ? It is a known limitation of rather ancient FOP version 0.20.5. This has been implemented in later versions of FOP. I recommend that you download the binary distribution of 0.93 and try it for yourself. http://xmlgraphics.apache.org/fop/download.html#binary Note to other FOP Devs: Isn't it about time we removed the download links to 0.20.5 from the download page? This should help discourage new users of a 5 year old release. Thanks, Chris
Re: Clarification for tables: grid units, border-resolution and breaks
I am trying to do the following < fo:table-cell border-left-color="green" border-left-style="dotted" border-top-color="red" border-top-style="dotted" border-right-color="blue" border-right-style="dotted" border-bottom-color="yellow" border-bottom-style="dotted" > in fop-0.20.5 , also tried the dashed but it is taking only solid as border of cell not dotted or dashed, How we can make the cell border dashed or dotted, is it a known bug or i am missing some thing ? is there any work around for it? regards Arun - Original Message - From: "Vincent Hennebert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: Sent: Wednesday, April 04, 2007 3:20 PM Subject: Clarification for tables: grid units, border-resolution and breaks > Dear XSL Editors, > > Questions were recently raised on the fop-dev mailing lists about > tables, borders and breaks. We finally all came to the same conclusions > but I think it might be useful to add some statements to the XSL-FO > Recommendation, in order to ease the understanding for newcomers. > > > Grid units and area tree > > It seems that the notion of grid unit is to be understood in terms of > area tree instead of fo tree. This is not obvious in the Recommendation > and it might help to explicitely write that. For example, when > a table-cell is broken over two pages, does it make one broken grid unit > or two separate ones? Thinking in term of FO tree, that would be one; in > term of area tree, that would be two. This is important for border > resolution, as we can see below. > > > Border-resolution in the collapsing-border model > > For the (cells of the) first row of a table, border-before on the > fo:table and applicable fo:table-column objects play into border > resolution. When the table is broken accross several pages, do they also > play for the first row of each page? Or only the very first row of the > table? We agreed upon yes. This means that if > border-conditionality="retain" on fo:table, then it will appear on each > page (if it wins in the border resolution), which would be the same > behavior as in the separate-border model. > > But if the fo:table-header is not omitted at page breaks, how should > border resolution be performed? Technically, the areas generated by the > table-cell children of fo:table-header are /replicated/ on each new > page, so they would have the is-first trait set to true. So assuming > that the conditionality of the fo:table's border-before is "discard", > should it play or not in the border resolution of table-headers on the > second and following pages? > > > Border-resolution and breaks > > For simplicity let's assume we are inside a single table-body. The > question is the same if we are at the boundary between two table-bodies, > only the border-after/-before of the table-bodies will also play in the > resolution. > The border-after of a cell is to be determined from: > - the table-cell's border-after; > - the containing table-row's border-after; > - the following table-row's border-before; > - the border-before of the cell below. > > If a break occurs /within/ a cell, should the following row and cell > still play in the border-resolution? We agreed upon not. > > If a break occurs between two cells: > - should a full border appear at the bottom of the page (or column) and > a full border at the top of the following page (column)? Or only half > a border on each? We agreed upon the former. > - like above, should the two cells and table-rows play in the > border-resolution of each border? Or only the previous cell and row > for the border-after on the first page and the following cell and row > for the border-before on the following page? We agreed upon the > latter. > > Those questions are easily answered if we consider that the table is > divided into independant grids on each page. Thus there would be a grid > line at the top and bottom of each page. Such a scheme would be logical > if grid units are entities which belong in the area tree. > > If on the contrary the table must be thought as a single grid which then > is broken down on several pages (more on the FO tree side), then the > answers to these questions tend to be different. > > That's why it may be useful to state that grid units pertain to the area > tree, and that border-resolution is performed on them at the area-tree > level. > > > Explicit breaks on table-header and -footer > > I don't think it makes much sense to set the break-before and > break-after properties on fo:table-row and children of fo:table-cell > which are themselves children of fo:table-header and fo:table-footer > elements. It might be helpful to explicitely state that in the > descriptions of break-before and break-after. > > I hope I was myself clear! > > Thanks, > Vincent Hennebert
Clarification for tables: grid units, border-resolution and breaks
Dear XSL Editors, Questions were recently raised on the fop-dev mailing lists about tables, borders and breaks. We finally all came to the same conclusions but I think it might be useful to add some statements to the XSL-FO Recommendation, in order to ease the understanding for newcomers. Grid units and area tree It seems that the notion of grid unit is to be understood in terms of area tree instead of fo tree. This is not obvious in the Recommendation and it might help to explicitely write that. For example, when a table-cell is broken over two pages, does it make one broken grid unit or two separate ones? Thinking in term of FO tree, that would be one; in term of area tree, that would be two. This is important for border resolution, as we can see below. Border-resolution in the collapsing-border model For the (cells of the) first row of a table, border-before on the fo:table and applicable fo:table-column objects play into border resolution. When the table is broken accross several pages, do they also play for the first row of each page? Or only the very first row of the table? We agreed upon yes. This means that if border-conditionality="retain" on fo:table, then it will appear on each page (if it wins in the border resolution), which would be the same behavior as in the separate-border model. But if the fo:table-header is not omitted at page breaks, how should border resolution be performed? Technically, the areas generated by the table-cell children of fo:table-header are /replicated/ on each new page, so they would have the is-first trait set to true. So assuming that the conditionality of the fo:table's border-before is "discard", should it play or not in the border resolution of table-headers on the second and following pages? Border-resolution and breaks For simplicity let's assume we are inside a single table-body. The question is the same if we are at the boundary between two table-bodies, only the border-after/-before of the table-bodies will also play in the resolution. The border-after of a cell is to be determined from: - the table-cell's border-after; - the containing table-row's border-after; - the following table-row's border-before; - the border-before of the cell below. If a break occurs /within/ a cell, should the following row and cell still play in the border-resolution? We agreed upon not. If a break occurs between two cells: - should a full border appear at the bottom of the page (or column) and a full border at the top of the following page (column)? Or only half a border on each? We agreed upon the former. - like above, should the two cells and table-rows play in the border-resolution of each border? Or only the previous cell and row for the border-after on the first page and the following cell and row for the border-before on the following page? We agreed upon the latter. Those questions are easily answered if we consider that the table is divided into independant grids on each page. Thus there would be a grid line at the top and bottom of each page. Such a scheme would be logical if grid units are entities which belong in the area tree. If on the contrary the table must be thought as a single grid which then is broken down on several pages (more on the FO tree side), then the answers to these questions tend to be different. That's why it may be useful to state that grid units pertain to the area tree, and that border-resolution is performed on them at the area-tree level. Explicit breaks on table-header and -footer I don't think it makes much sense to set the break-before and break-after properties on fo:table-row and children of fo:table-cell which are themselves children of fo:table-header and fo:table-footer elements. It might be helpful to explicitely state that in the descriptions of break-before and break-after. I hope I was myself clear! Thanks, Vincent Hennebert