Hi Jean-François,
Thanks very much for your reply. Naively, I hadn't factored in the
"just make it work" methodology to solving the formatting problems, I
was expecting FO to provide mechanisms to handle the functionality I
mentioned in my post - they didn't seem that obscure.
Glad I could be of help ;-). Yeah, we always like to assume the tools
we are using will at least do the job, but the truth is most of the
time they only do part of the job and you have to patch up what's left.
It is unfortunate, but very frequent. Revision indicators aren't that
obscure either when you think about it (having a bar on the side of the
document to indicate that a portion of text has changed, but it is only
supported as of XSLT v1.1, and nearly nobody implements it just yet).
Companies usually offer company specific extensions to FO as an add on
to paliate the deficiencies of the standard. XSLT still has a long way
to go. All and all, it still is a very interresting and powerful tool.
I'm looking into XML / XSL as a replacement to an inhouse developed
reporting solution and one of the requirements was this pagination
control. Additionally, this potential reporting solution is to be used
by people who aren't primarily developers, but accountants - so the
solution mustn't be too challenging to use. Do you have any thoughts /
comments on XSL as a reporting solution. I've had a look at the
Altova, XSLFast and StylusStudio tools, however, if I put these
applications in front of the end users, capable as the applications
are, I'm fairly certain the users would not thank me for it.
I don't know exactly what your requirements are, but you might want to
look the XML way in that case. Instead of creating creating a custom
XSLT for an XML everytime a new report has to be emitted, you put
together a single more flexible XSLT stylesheet in which all XMLs will
go through to generate your report. The tools you mentioned, Altova,
XSLFast and Stylus Studio are graphics frontends sitting on XSLT
processors to aid in stylesheet development. I personally wouldn't have
end users use those to format their reports.
Using for example an XML editor such as open-source VEX (XML which
would have to contain enough information for you to properly format the
end product in either .pdf or .rtf. font size, bold, italic,
indentation, table column width, etc.) might be what you are looking
for. VEX is a strange hybrid though. Using a combination of XML and CSS
for display (CSS which is usually only used in combination with HTML).
It is a very interresting tool though and might be just what you are
looking for. Otherwise, any XML editor that takes in an XML + XSLT to
output on display will do the trick. The same XSLT that would be used
for display could be used for transformation into the final .rtf or
..pdf product.
I'm coming to the conclusion that XSL et al are powerful tools, but
there is a need for a seasoned XSL et al developer to create the
solutions - it's not the sort of thing you just dive into.
Somebody definately needs to sit there and put together the stylesheet,
depending on the complexity of the reports, it might very well turn out
to be very easy, or very complex.
Once the flexible stylesheet is done though, everything that goes
through it should be fine.
Google is indeed a powerful friend, it's a shame he / she's not psychic
- though I'm sure that's only a matter of time
I've spent so long
trying to phrase my searches in google to try and get the answer I'm
looking for that I'm thinking of doing a Phd in frustration management
techniques..
Heheh, its just a question of practice. It took me one try to hit the
answer you were looking for, but then again I'm ALWAYS searching stuff
on google so I kindda know how to make it squeeze the answers out.
Google in "using google efficiently". It pays off like you wouldn't
beleive to have google do what you want.
I've been using Apache FOP for the rendering and it does seem OK.
However, one of the other requirements for this reporting solution was
to be able to create RTF, which the latest beta does, however, it
renders the same FO document differently to RTF and PDF - which is a
little frustrating.. I know you can generate RTF straight out of the
XSL transform, however, do you not then forfeit the layout capabilities
built into FO? - specifically the pagination control.
RTF. There's an interresting requirement. If you want your FO and RTF
to by synchronized, some work will have to be done to make them
synchronized (2 different stylesheets might be required in this case.
One to output PDF through FO and one to output RTF). I never compared
the expressing capabilities of RTF vs FO, but if one is more expressive
than the other, if you want them to be in synch, you might have to
leave behind some functionalities from either one or the other. Or if
its not such a big issue, the RTF can be different from the PDF if
thats okay with the customers. If you were go to down the VEX path, you
are probably looking at a custom made DTD for your XML, a CSS to
display the XML properly under VEX and 2 different stylesheets. One to
output PDF through FO and one to output RTF.
Here's a link to the RTF spec 1.6:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnrtfspec/html/rtfspec.asp
and a little discussion about this issue you are facing with RTF:
http://www.stylusstudio.com/SSDN/default.asp?action=9&read=3147&fid=48&style=WebBoard
Thanks again for your assistance.
You are most welcome
Regards
Jean-Francois Michaud
Regards,
Howard
Jean-François Michaud said:
Hello Howard,
Hi,
I'm really new to this XSL stuff and there's a lot of information out
there on the web, I just can't seem to find a definitive answer to my
question, hence......
In FO, I know that you define a block and use the keep-together
attribute to specify whether or not the block should be split over
multiple pages - unless the block itself is longer than a page.
However, if you allow the block to be split over two pages, is there a
mechanism to put some text at the top of the split piece of the block.
As far as splitting text goes, you want to look at orphans/widows. When
the attribute is set to a certain value, it garanties that you will get
at least what you are asking for or else the whole content of the block
carries over to the next page. Not all XSLT processors support this
feature, you want to make sure that the processor you use supports all
the features you are looking for. Most of the time, they support one
feature, but not the other and vice versa. Its difficult to get a very
good one that supports all the important features.
If you are not in for hardcore technical publications, FOP (open
source) is actually not so bad (it doesn't support orphans/widows
though).
Specifically, say I have a table and the table gets split over two
pages half way down its body. So the top half of the table is at the
bottom of page 1 and the bottom half of the table is at the top of page
2. Is there a mechanism in FO to reprint the table column headers at
the top of the chunk of table on page 2.
I read somewhere that this might be possible by writing another XSLT to
do some post processing, additionally, I've read that XSL is a fire and
forget kind of technology and you can't do this. If you don't know
that this table splitting is going to happen until it's run through the
FO processor and once it's gone through the processor you've got (in
this case) a PDF file - how would you then insert the column headers in
again, by the time the table has been split, it's too late to easily
insert the column headers.
Google is a very powerful friend ;-). This seems to be what you are
looking for:
http://www.idealliance.org/papers/dx_xmle04/papers/04-02-01/04-02-01.html#s6
I'd like to ask the same question with regards to a table caption, in
order to achieve a table title at the top of the split chunk of table
on page 2. e.g.
Something to keep in mind also, often you will have to use tricks to
pull off certain effects (nested indentation using lists for example
even though the content of your XML isn't contained in lists; to get
sequencial labeling across multiple sections for example. An invisible
table column for which you set the width to align a table exactly like
you want on a page). Don't be afraid to use constructs that don't seem
to be "appropriate" or that look very different (under FO) than what
you have in your XML. Whatever works, works. If there is not direct way
to do something by using the functionalities of the language directly,
you might be able to achieve the desired result through indirect means
(oddly enough, when you are working on solid projects, this happens
very often). Currently, the language is simply not descriptive enough
(functional only). A functional/procedural language hybrid would be
much more appropriate.
In the case of your table caption, you could use an borderless row in a
fo:table-header.
[snip]
Regards
Jean-Francois Michaud
