W. Eliot Kimber
> I am a template developer using 3B2 pagination software. I want to
> know does any xslfo formatter provides such features as avialable in
> other pagination softwares(i.e quark-express, indesign, 3B2 etc.)
>
> a). making round corner boxes, drawing rules.
Drawing horizontal or vertical rules can be done in several ways with
FO. All the useful FO implementations also support the use of SVG to
draw anything SVG can draw.
Antenna House XSL Formatter includes extensions for doing rounded box
corners. These are not quite as complete as 3B2's but close.
> b). adjusting left, right, top and bottom margins. Not sure what you mean by this. Page margins can be varied on a per-page
basis by using different page masters, although they cannot be
arbitrarily changed outside of the definition of a page sequence (that
is, there's nothing you can put in a flow that would directly affect the
page margins on a given page).
> c). auto generating footnotes.
XSL-FO has a footnote feature (automatic placement) and both XSL
Formatter and XEP provide extensions for doing column footnotes
(standard FO only provides full-page footnotes).
However, neither FO nor the commercial tools provide the full range of
footnote placement features that 3B2 provides (especially through things
like footnote control streams and rendition-time macros).
> d). placing figures and table near to their callouts in the running
> text.
FO has some features for this, including top and side floats (but not
bottom floats unless you use footnotes (and don't have any real
footnotes on that page)).
Neither FO nor any implementations provide the equivalent of 3B2's
anchor control streams, which let you do very sophisticated automated
placement of floats.
> e). frames with unequal column widths.
Not directly. In FO columns must be of equal width.
However, in FO 1.1 you can simulate this with multiple flows. Also, both
XEP and XSL Formatter provide extensions that make it possible to
achieve major/minor type layouts where the minor column only holds
single-page marginalia items.
> f). colour-gradient styles.
You can use any background graphic, including gradients. You can also
use inline or external SVG to do gradients (assuming your FO
implementation supports SVG gradients).
> g). recto-verso style variation etc.
Yes, you can have different page masters for even and odd pages, and so
on. FO 1.0 fails to provide inside/outside options for some items, but
this has been corrected in FO 1.1. Both XEP and XSL Formatter provide
extensions for inside/outside placement.
> Does XSL:FO fullfil such requirements in electronic typesetting.
This is always a difficult question to answer because it is highly
dependent on the details of the requirements for a particular
publication or class of publication.
Because XSL-FO systems tend to be so much less expensive than systems
built using proprietary composition systems, the better question is
often "can I reduce my requirements to the set supported by XSL-FO and
its implementations in order to recognize the savings and benefits of
using XSL-FO?" If the answer is "yes" then FO is the answer. If the
answer is "NO" then it's not. Of course that still leaves open the
question of what XSL-FO can or can't do. This is an easy question to
answer in the context of specific layout sample, hard to answer generically.
That all said, FO was always targeted at the requirements of technical
documentation and not high-end documents like textbooks, magazines, and
the like.
In Innodata Isogen's practice as a development of publishing systems and
provider of composition services, we have found that the FO standard and
current FO implementations, while quite powerful and clearly appropriate
for most technical documentation applications, are simply not up to the
task of rendering more demanding publications such as textbooks and
magazines, what I tend to refer to as "highly-designed documents".
Also, all XSL-FO implementations are geared for lights-out, batch
operation. This means that there is really no opportunity for
interactive modification of the rendered result the way there is in 3B2,
Quark, InDesign, or XPP. While you could, in theory, generate XSL-FO
instances and then tweak them, there are no user interfaces for doing this.
Also, the abstract XSL-FO processing model explicitly lacks feedback
from the pagination stage back to the FO generation stage, which means
that there are no features in XSL-FO for doing what FO calls
"layout-driven" formatting, that is formatting that depends on knowledge
of where a given object falls on a page relative to other objects. This
kind of feedback can be implemented using a two-pass process, but I
don't know of anyone whose done this in any general way (Ken Holman has
published some work he's done to do a sort of 1/2 send pass to do index
generation).
So if you have requirements that are defined in terms of where something
falls in the pagination stream or in terms of how much space it takes
relative to other things, then XSL-FO is probably not going to work, at
least not without significant additional implementation effort.
Also, XSL-FO provides few features for automatic copyfitting, which is
something that tools like 3B2 can do reasonably well. XSL Formatter
provides some "make it fit" features but they are limited compared to
3B2's copyfitting features.
In the interest of full disclosure, I should mention that Innodata
Isogen is currently developing and marketing a new composition offering
built around what we are calling the "tool-agnostic layout system"
(TALS), which uses a generic style sheet mechanism to then generate
renderers that can then generate the input into different composition
systems, including 3B2 and similar systems.
The style sheet mechanism is proprietary to Innodata Isogen but strongly
informed by XSL-FO and intended to be a completely neutral repository of
all the formatting information for a given schema-to-layout-design
binding. While the style sheet design is proprietary we are treating it
as though it were a standard--that is, our business intent is not to
achieve propietary lock-in of our customers but to provide them with a
system that has the characteristics of a standard, namely providing a
neutral data format that protects them from the downstream tools as much
as possible and lowers the overall cost of developing XML-based
publishing systems (by reducing engineering costs, enabling practical
re-use of style specifications, and automating composition with high-end
composition tools as much as possible (reducing the amount of hand work
needed to paginate documents).
Clients of this system own their style definitions and therefore have
the right to use a different implementation (we see our secret sauce
being the implementation of the renderer generators, not the style sheet
language itself). As in the XSL-FO market, we should be competing on
value, not trying to develop a proprietary monopoly.
We originally developed this approach in order to serve the needs of our
own professional services practice--we wanted to eliminate duplication
and redundancy in the development of format analysis reports and the
XSLT transforms that come out of them, but quickly realized that there
was a large opportunity to serve additional needs of publishers. Our
orignal plan to was to generate FO renderers (that is, renderers that
generate XSL-FO output, which is the bulk of what we develop in our
professional services practice). However, we got early interest from
publishers that were trying to get control over their use of 3B2-based
composition vendors to compose publications from XML source. We realized
that if we could better automate the generation of the input into tools
like 3B2, we could help publishers get more control over their
composition process, get more consistency in their results, and,
hopefully, lower the overall cost of publishing a given title, and,
possibly, reduce the time it takes to produce a publication (by
significantly reducing the time required to go from manuscript to final
pages).
Note that the intent of this system is absolutely *not* to compete with
existing composition tools, whether XSL-FO-based or proprietary. Rather,
we are trying to make it easier for clients to use different composition
tools and lower the cost of getting from XML to published pages, which,
we hope, will increase the market for composition tools (and, as a side
effect, encourage vendors of proprietary composition systems to compete
more on value (which they already do of course, but there is significant
proprietary lock-in for a tool like 3B2 or InDesign or XPP once you've
made the investment in skills and tools and data for using it).
In the context of XSL-FO systems, the only potential downside from our
system is that we might lower the cost (both in dollars and in risk of
proprietary lock in) of using high-end compositions systems to the point
where they become competitive with XSL-FO-based systems where the XSL-FO
system would otherwise satisfy the composition requirements. It's
certainly not our intent to develop a technology disruptive to the
XSL-FO market but it may be an unavoidable consequence. Of course, this
might also drive the FO development community to work harder at
extending the FO specification so that it is more applicable to high-end
composition needs....
Our initial implementation efforts have been on generating 3B2 input,
which is why I happen to know pretty much precisely how XSL-FO and its
implementations relate to the specific features of 3B2. | 
| XSL Frequently Asked Questions