Re: [xsl] About xsl-fo features when printing same layout to different page sizes

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
Hi Curro,

At 02:50 AM 5/14/2008, you wrote:
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).

It depends on what you mean by "dropping the rest".

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.      
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

Current Thread