Re: [XSL-FO] Automation about line number
- G. Ken Holman wrote:
> I looked where you cited and I see no examples of the use of a stringargument.
Value: start | center | end | justify | inside | outside | left | right
| <string> | inherit
The <string> in the angle brackets is really meant to be an XSLFO
property expression string, I think, while all the other values are
Well, they *could* have been a bit more clear.
> I checked the CSS citation and saw in the syntax of the CSSstylesheet the use of quotes, but I thought that was an artifact of the
CSS stylesheet syntax.
>that if the alignment string were the word "left" you would need to say
> Looking at XSL-FO section 5.11 I note the description of <string> to be:
> "A sequence of characters"
> ... which does not imply the need for quotes ... though I will admit
"'left'" in order to distinguish from "left".
Section 5.9.8 Strings (lexical structure of property expressions):
"Strings are represented either as literals or as an enumeration token."
The string literal is cross referenced to the production:
 Literal ::= '"' [^"]* '"' | "'" [^']* "'"
(see slice5.html#NT-Literal). These quotes are supposed to be inside
the XML attribute, like for XSLT strings.
But then, there is the following in 5.9.8:
"All properties contexts allow conversion from enumeration tokens to
which means the XML attribute
would represent a valid FO property expression, yielding the
enumeration token bar which may be implicitly converted to the string
OTOH, an enumeration token is supposed to be a NCName, and a single
dot is not a NCName (but a single underline character is). Hence
the need for the quotes. Or so I believe.
I remember the discussion regarding page number formats:
<fo:page-sequence format="01" ...
The expression will be parsed as number, but because the format is
expected to be a string and in contrast to XPath XSLFO numbers
can't be implicitely converted into a string, the property is in
error (and even if implicit conversion was allowed, it would drop
the leading zero). The errata allow the FO processor specifically
for this use case to fall back to use the original string value
of the XML atribute, after trimming leading and trailing whitespace,
otherwise everybody would be forced to write
<fo:page-sequence format="'01'" ...
And I really like the specification of the hyphenation character:
Value: <character> | inherit
Yeah, chapter 5 doesn't include a specification for a lexical character,
nor do the errata. This begs the question whether
is really meant to be written this way, because the only plausible
interpretation of <character> would be "a string consisting of
a single character". And what about
Yes, four ASCII dots. Why shouldn't this be allowed?
I'm reminded of the most renowned example of "specification by
implementation", the C preprocessor - simple, intuitive syntax,
straightforward implementation, but leading to an utterly convoluted
formal description for the sake of getting rid of the "dark corners"
(which makes the quite innocently looking expression 0xE-0xA an invalid
Specs with holes suck. But then, I've dealt with texts which were much,
I hope they fix the property expression grammar and the individual
property specs in XSLFO 2.0
- Yes, for Docbook:
--- "J.Pietschmann" <j3322ptm@...> wrote:
> G. Ken Holman wrote:http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/9rHolB/TM
> > Unless a vendor gives you a vendor extension to do
> line numbering of
> > formatted lines, I think you are out of luck.
> The DocBook XSLT style sheets provide such an
> for Saxon and Xalan, I think.
> ------------------------ Yahoo! Groups Sponsor
> Yahoo! Domains - Claim yours for only $14.70
> Yahoo! Groups Links
- Clarification: The DocBook line numbering applies only to programlisting and
literallayout elements, not to general text. There is no facility in
DocBook stylesheets to number all lines of a document, which is what the
original question was after.
----- Original Message -----
From: "Glen Mazza" <grm7793@...>
Sent: Friday, June 11, 2004 11:30 AM
Subject: Re: [XSL-FO] Automation about line number
> Yes, for Docbook:
> --- "J.Pietschmann" <j3322ptm@...> wrote:
> > G. Ken Holman wrote:
> > > Unless a vendor gives you a vendor extension to do
> > line numbering of
> > > formatted lines, I think you are out of luck.
> > The DocBook XSLT style sheets provide such an
> > extension
> > for Saxon and Xalan, I think.
> > J.Pietschmann