[
Lists Home |
Date Index |
Thread Index
]
>If you were restyling the source document I'd agree, but how on earth
do
>you restyle the generated FO? Pretty much everything in sight is an
>fo:block so the only way to get a handle on it for css would be to
>generate class attributes somewhere and restyling probably means
>generating a different set of class attributes, so you'd still need to
>go back and change your xslt stylesheet.
Well things can also be fo:inline, fo:table; fo:list-block etc. etc.
but let's just accept for the moment that nearly everything is gonna be
fo:block.
--example use case fo + css styling--
I'm not gonna get outside of classes, tags, and ids here; there may be
some upsetting of fo rules but it is done with the understanding of
showing simple css benefits for fo. Please note that I'm pretty sure
this would make some ugly FO, if even displayable(once pre-processed.)
<fo:stylesheet>
fo:block{space-before.optimum:5pt; space-after.optimum:3pt;}
.Section2{space-before.optimum:7pt;border-start-color:red;
border-start-width:2px;}
.bodyblock block{border-start-width:1px;}
.Title{width:44pt;height:75pt;background-color:blue;color:white;}
#section1body22{margin-top:11mm;}
</fo:stylesheet>
.....
<fo:page-sequence master-reference="ContentVAV" format="1">
.....
<fo:flow flow-name="xsl-region-body" id="body22">
<fo:block-container class="bodyblock" id="body22block">
<fo:block class="Section1" id="section1body22">
<fo:block class="Title" width="33pt">What he said</fo:block>
<fo:block>
He Said <fo:inline class="quote">"I'm really trying here"</fo:inline>
</fo:block>
</fo:block>
<fo:block class="Section2" id="Section2body22">
......
</fo:block>
</fo:block-container>
</fo:flow>
-------------------
okay that's enough I don't want to sit here and try to figure out a
great example I just want something that demonstrates some points.
1. If you do have to open up FO and debug that will be easier
2. easier to control inheritance, via css methods for controlling
inheritance, than through the normal FO methods for controlling
inheritance(aside from the usual 'inherit from the parent element' which
we are used to from most presentation markup)
3. If The fo:stylesheet was referencing an external stylesheet than it
would be even easier to control inheritance. Or should I say easier to
develop powerful systems for specifying inheritance.
4. Finally the main point and I think the point that everyone has been
trying to make who is arguing on the side of using css styling in FO is
that it allows for a similar separation of tasks that markup development
teams are enjoying in other solution building areas. Where I work we may
wear many different hats, but we don't wear every hat. One of the
strongest business benefits / development benefits I see for xml is
that you can have a universal format accessible from a number of high
level apis and even if the format is not necessarily the best
representation of the problem area one is working in, you more than make
up for this downside by being able to use the same tools and
methodologies to work with it; one of the most prevalent working models
seems to be xml + programmatic solution(xslt,sax,scripting language) ->
result format(svg,html,e-book, etc.); result format + css = presentation
level-> interpreter/processor.
Sorry if I'm repeating myself here.
XSL-FO should be fitting into that result format box, but it's a little
fat, bits are hanging out over the edge.
Also in a later post David said that people who know css better than
xslt might appreciate having the styling in css. But I know xslt better
than I know css(can't say I'm not always finding new things out about
xsl-fo though, and the marvels of FOP's faulty implementation), and I
think it would be preferable.
Ian - sometimes you will want to keep XSL-FO documents hanging around,
if for example you implement a rule-based publishing system(I know
something about this since it's part of what I'm working on right now)
You have a collection of documents, various document types together:
Coverpage.xml
Booklet1.xml
Split.xml
Booklet2.xml
Split.xml
Vcards.xml
These come out as project22.fo
Project22.fo goes to project22.pdf
User realizes that certain elements in the result should be changed
presentation wise, in such a case it often makes more sense to edit the
xsl-fo(via your favorite programmatic process) and regenerate from the
FO document than it does to start the process from the beginning.
Also G. Ken Holman had some examples for managing Landscaped Tables on
his site that also implies XSL-FO sticking around.
|
