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

2007-04-04 Thread Vincent Hennebert
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

2007-04-04 Thread Arun Kumar
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: fop-dev@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



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

2007-04-04 Thread Chris Bowditch

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