Clarification for tables: grid units, border-resolution and breaks

[Vincent Hennebert <vi...@anyware-tech.com>]

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

Re: Clarification for tables: grid units, border-resolution and breaks

[Chris Bowditch <bo...@hotmail.com>]

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

<snip/>

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

[Arun Kumar <ar...@ebusinessware.com>]

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" <vi...@anyware-tech.com>
To: <xs...@w3.org>
Cc: <fo...@xmlgraphics.apache.org>
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