Re: About xsl-fo features when printing same layout to

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.

Cheers,
Wendell

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