Related link: http://www.cranesoftwrights.com/schedule.htm#pfux
XSL-FO combines an enormous (and verbose!) vocabulary and lots of possible combinations. In our second day of XSL-FO training, the potential number of interactions is seems ever larger, as does the number of cases where repurposing features (especially empty blocks, and footnotes) to produce results which aren’t immediately obvious.
There’s a strange kind of genius at work in the page-layout systems of XSL-FO, demanding that stylesheet writers specify the logic by which their documents operate. The XSLT/XSL-FO combination lets developers create enormous logic puzzles which lay out pages rather than the more familiar (to me) process of human interaction in applications like PageMaker, Quark, InDesign, and FrameMaker.
While it’s sometimes possible to leap into the XSL-FO instance markup, there’s still (deliberately) a large layer of indirection between that markup and the final rendered product. Working with XSLT stylesheets which generate XSL-FO, which is for the most part the preferred approach, adds another layer of indirection. While it’s certainly possible to tweak stylesheets to render a particular document, I have to admit that I really miss the cascade of CSS and its much easier element-by-element tweaking capabilities. There are best practices for creating tweakable (well, modularized) XSLT stylesheets, but you’re much more at the mercy of the creator of the stylesheet with which you’re interacting.
I have a hard sitting through five days of anything, especially huge volumes of technical information, but Ken Holman has done a remarkable job of keeping this interesting. He combines enthusiasm for the training with a long list of projects outside of training, and his work beyond the training made the examples a lot more compelling. I can’t imagine teaching this for five days solid, but he seemed just as ready to explore the details of keeps and breaks this afternoon as he was to explain the overall architecture on Monday.
I came to the training as a skeptic of XSLT and especially XSL-FO, and I haven’t experienced a massive conversion. At the same time, though, I have a far better perspective on what these tools are good for (and not good for), not to mention a much deeper understanding of how they fit together. I’ll be taking what I’ve learned back to O’Reilly, where I’m hoping to use my improved XSLT skills for a variety of editorial tasks, and see if I can fit XSL-FO into my process so that authors can get a better snapshot of what their work will look like.
After five days of this, I’m pretty tired, but very happy. It’s a different feeling than I tend to get after a conference or reading a book, and it’s one I’d encourage more people to enjoy.
Does training make a big difference for you?
XSL-FO Good for Report Generation?
It's interesting that you are learning about xsl-fo. I'm in the process of creating a product for a startup an when it comes to printing I was thinking of using xsl-fo with the apache xsl-fop project.
It's seems quite powerfull but difficult. I was wondering if it can be used to generate simple printing and full blown report generation. We need to print simple transactions and generate reports. I was hoping to use one system to do both.
I like the fact that the output can be configured, this way customers can get their own custom output, logo's, disclaimer's, etc. FO seems like it can handle this easily, but what about report generations, charts, graphs, etc.
Thanks for any feedback,
Joe
XSL-FO Good for Report Generation?
Absolutely XSL-FO is good for report generation, because report generation is very often easily rule based. XSL-FO 1.0 is not well suited for magazine layouts or other arbitrary positioning or multiple flows.
I acknowledge many people think XSL-FO is difficult, but I've come to the conclusion that is usually because the are reading the Recommendation. The Recommendation is written for XSL-FO engine implementers and has all the gory detail necessary to ensure consistency across products and applications. I don't think the Recommendation makes a great learning tool for a beginning stylesheet writer.
Thankfully, it is easy to meet straightforward requirements quickly and easy to build on the basics to make very professional-looking results for rule-based publications.
Without knowing your requirements for "simple transactions and generate reports", I am confident in predicting these to be rule-based and you will be able to make good-looking publications.
Regarding charts and graphs, XSL-FO easily accommodates foreign namespaces for graphic images and a number of tools support the inline presentation of SVG. XSLT stylesheets can produce the mixture of SVG and XSL-FO from XML in a seamless fashion to flexibly produce an integrated result.
I hope you find this is helpful.
............... Ken
XSL-FO for Reports
XSL-FO works well for reports, but where it shines is with reports (and documents) where the data is irregular or there is a lot of variation (i.e. the data doesn't fit into nice rows and columns).
Specifically, I find XSL-FO (using FOP) to be the perfect tool for security marketing and sales. There's a lot similarity between products, but the columns change from product to product. There's also a lot of disclosure, footnotes and explanation paragraphs, that XSL-FO handles quite easily. Other reporting tools that we've used have required us to break up text into separate controls to handle bold text. We've even had to use unicode footnote symbols to handle superscripts. XSL-T usually is enough to generate the formatting and the logic we need to create reports.
XSLENT!
Back when XML eXcetera were first announced, I had the corny idea for a domain name for a design/layout service for enterprises, XSLENT.COM. I registered the name, but never pursued the idea. Given Simons' eXposure to this technology, would such a scheme make sense?
BIG THANKS
Marc Laventurier