headers
Chris King | 4 Apr 2007 04:37
Picon
Picon

http://www.w3.org/1999/xhtml


Greetings,

I tripped over xmlns="http://www.w3.org/TR/xhtml1/strict"
in http://www.w3.org/TR/xslt
used in the examples in section 2.3 (not stated as non-normative)
and appendix D.1 (non-normative):

<html xsl:version="1.0"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlns="http://www.w3.org/TR/xhtml1/strict">

Reading the errata archive response
http://lists.w3.org/Archives/Public/xsl-editors/2004AprJun/0033
I understand that lack of future knowledge about draft xhtml
meant that at the time of publication there was no error,
but now it's misleading.

Because xslt1.0 is still a current(?) recommendation in use,
my vote is for a little in-place edit to change the namespace to
	http://www.w3.org/1999/xhtml
so that it may prevent further whoopsies like mine.

--

-- 
</Chris>
Permalink | Reply | 0 comments |
headers
Vincent Hennebert | 4 Apr 2007 11:50
Favicon

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arun Kumar | 4 Apr 2007 12:00
Favicon

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" <vincent.hennebert <at> anyware-tech.com>
To: <xsl-editors <at> w3.org>
Cc: <fop-dev <at> 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.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Hennebert | 4 Apr 2007 21:10
Favicon

Border- and padding-conditionality and fences

Dear XSL Editors,

I have another question regarding border- and padding-conditionality.
Please see the attached fo file, which gives a two-page document: the
question is whether the padding-before of the inner block should be
discarded or not on the second page.

The intuitive answer would be yes (at least I think this is what most
users would expect).

However, if we strictly follow the rules of the XSL-FO 1.1
Recommendation it seems that the padding should actually be retained.
Indeed it would be discarded if the before-edge of the area generated by
the inner block were a leading edge in the normal-flow-reference-area
(of the second page, let's call it R). This is explained in the last two
paragraphs of section 4.3.1, "Space-resolution Rules" of the XSL-FO 1.1
Recommendation.

This edge would be a leading edge if the inner blocks's area would begin
the normal-flow-reference-area (section 4.2.5), that is if it had
a stacking constraint with R and if none of its ancestor areas had
a non-null space-before.

However, the retained border on the outer block creates a fence before
the area generated by that block; which prevents the inner area from
having a stacking constraint with R. Thus the edge is not a leading edge
and the padding-before should be retained.

What is interesting is that if the outer block had a discarded
border-before then the padding would also be discarded, as this time
(Continue reading)

Permalink | Reply | 0 comments |

Gmane