b***@wiggum.w3.org
2008-12-04 16:44:26 UTC
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6279
Summary: Border-resolution and breaks
Product: XSLFO
Version: 1.1
Platform: All
URL: http://lists.w3.org/Archives/Public/xsl-
editors/2007AprJun/0000
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: XSL-FO
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.
Summary: Border-resolution and breaks
Product: XSLFO
Version: 1.1
Platform: All
URL: http://lists.w3.org/Archives/Public/xsl-
editors/2007AprJun/0000
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: XSL-FO
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.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.