[
Lists Home |
Date Index |
Thread Index
]
>> First off, the fo:block tag is a presentation element in it's own
right,
>> just as the p tag is, so the example should be a little more like
this
>> fo:block{
>> text-align:right;
> One should never write an fo
>document, it is only the result of styling some other document.
I was probably unclear, in that the examples of css styling I gave where
for applying css against an fo document at fo processing time, i.e at
the point your fo document gets output to pdf or other paginated format.
This is the same viewpoint that David Rosenborg was starting from it
seems to me.
> <fo:block class="exampleblock">
>why do that and force a different styling language with a different set
>of selectors have to walk over the result tree and find this class
>attribute and style it.
I think the examples I gave demonstrated some reasons, easier control of
inheritance. Other reasons might be, run transform on document, save FO
instance. Change CSS styling. This is not that dumb a scenario, I've
implemented a CSS like system for my XSL-FO work, one of the things I
often have to do is to allow editing of XSL-FO result documents, i.e
something in a set of documents is not good, therefore we will run an
edit on the XSL-FO and output a new XSL-FO, often this just involves
switching styling styling information for various classes of things.
Note that of course one reason for this also involves that I work with
FOP, I do not have the luxuries that someone with access to AntennaHouse
does.
>The only point in an xsl-fo generating
>stylesheet is to style the input document.
XSL-FO is a result document from an XSLT transform. It is perhaps more
styling oriented than other types of result documents, but it does not
style the input document - there is in fact no connection between the
two such as there is between a markup document that somehow refers to an
external styling document, whether that be css or an xslt via the
xml-stylesheet processing instruction (another solution that I think is
weak in structure)
>there is no point in
>pretending that the resulting fo tree is some generic content-rich
>document that can be css styled in arbitrary ways.
Nope it can't be styled in arbitrary ways, neither can SVG, SMIL or
HTML. It can(actually I should say could since we are discussing if
XSL-FO had css styling capabilities here) be styled in the ways relevant
to its inline markup.
>> i.e someone can work on the css without knowledge of xslt,
>I don't think that (should) be possible in general. Someone might css
>style the original document but unless they have intimate knowledge of
>the xsl stylesheet they should not expect to be able to css style the
>resulting FO.
Someone doesn't have to necessarily know the structure of the XSL-FO
being output. In my solutions I have some virtual areas, for example in
my XSL-FO I have my xsl-region-before-right with a fo:block with a
fo:table inside of it; the table allows me to split the region into two
subsidiary regions(cells), each cell has one block, styling can then be
done on these areas by their classnames. The person who maintains these
areas doesn't really have to know anything about it, just what
properties they can put on anything, which often is just the common
border padding and background properties, common font properties and
sometimes common margin properties.
>No one wants to look at a generated FO document except
>bad days when you are debugging. It should just be internal guff that
>you pass as quickly as possible to your FO engine.
Right! I find that having a css-like syntax for my styling decreases the
need to look at both XSL-FO and the XSLT, once the solution is up and
running of course.
>I believe
>there is a css stylesheet around somewhere that implements at least
some
>of XSL FO directly in a css capable browser, such an implementation
>would naturally allow further stylesheets to be cascaded over the
>document if that's what you want to do.
Again here I think we've been miscommunicating since I was discussing
not styling XSL-FO as an xml document for display on a screen via CSS;
but about having the separation of tasks that other markup formats enjoy
- XML + XSLT = Result Format(XSL-FO); XSL-FO + CSS + FO Processor =
generally PDF or other paginated form.
However if you ever find that css for XSL-FO again please send me a
copy, it sounds rather cool :)
|
