Subject: Re: [xsl] About xsl-fo features when printing same layout to different page sizes|
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 14 May 2008 11:27:53 -0400
To check if I understood well,
1. There is no way (at least not easy or inmediate way) to flow text into a box of x/y dimensions, and fit some text in that box, dropping the rest (I don4t need to fit all the text).
You can set up a box of x/y dimensions, and you can flow text into it, and you can even specify overflow behavior to "hidden", but what your formatter will do with that will depend. Most will simply clip the contents at the point where it starts overflowing. If you need no more control than that, there you are.
2. If I have different sizes (size1, size2), I'll always need different xsl. The relationship beetween the different xsl will be more complicated than just resizing the block areas, page size and margins. (How much more?)
Again, not precisely. XSL stylesheets can accept parameters at runtime, and they can be written with conditional logic based on those parameters. Likewise, the parameters themselves can be accepted as specifications in the XSL (for page size, font size or whatever). Alternatively, XSL can be set up in modular fashion, in which several different stylesheets all call the same lower-level modules of shared code, allowing efficiencies in coding and giving a family resemblance to the results. Whether either of these cases of code reuse make for "different XSL" depends on what you mean by "different".
But while I am not a professional layout designer, my guess is that to get reasonably good results, you won't be able to get away with using canned procedures for everything but block and page sizes and margins. On the other hand, this is again subject to your definition of "good results", and for some processes, the considerable benefits of XSL "lights-out" processing (in terms of scalability and manageability) can outweigh the decline (or perceived decline) in production values.
An aside: I recently took a one-day class in letterpress printing, and finally got a glimpse into what traditional layout designers are perceiving and judging when they evaluate layouts. It's fascinating how looking at the "same thing" (letter forms on a page) can be altered by a different perspective on how it comes to be, what the designer can control (and not) in the production technology, where the tradeoffs are between the level of effort and the fineness of the result, what sorts of information about that result are available to the designer before the production run, and what are the marginal costs of test runs.
Since I have no way of determining what you and/or your managers or clients care about with respect to layout design (and believe me, this varies tremendously), it's also impossible for me to judge whether XSL-FO is up to the job.
I really want to take advantage of the multicolumn, intelligent paragraph layout, etc... that xsl-fo provides and this is not available in other interactive layout applications (xhtml browsers).
It sounds to me like you are at the point where you might set up a small pilot project to test it out. Most commercial XSL formatters come in a trial or "mini" version sufficient for this purpose. Make a list of precisely of what you need to accomplish, put together a data set (not large but sufficiently large to test), and work through the list, learning FO as you go. If you are systematic about it, you can fairly rapidly assess where your requirements are easily addressed, and where they are not. Keep track as you do this of which requirements are "must-haves" and which ones can be adjusted or done without entirely.
One warning, however: if you're also new to XSLT, you'll have to learn two different things at once. Such a project will be much easier for someone whose XSLT skills are already strong. (Or you can actually mock up an XSL-FO XML document by hand. This wouldn't be my idea of a good time, but it would serve to isolate the testing of XSL-FO features while postponing the problem of how you'd create your FO.)
There is, of course, also a market for XSLT and XSL-FO programming and for training.
====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================