[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Word -> XSL


Subject: Re: [xsl] Word -> XSL
From: Eliot Kimber <ekimber@xxxxxxxxxxxx>
Date: Tue, 05 Jan 2010 08:39:25 -0600

On 1/5/10 8:11 AM, "Schultz, Len" <len@xxxxxxxxxxxxx> wrote:

> This brings up another question I have.  I don't know FO well, and don't know
> what it can and can't do relative to WordML.  E.g. in WordML, I can specify a
> book fold: where the flow is presented on a 2 column landscape layout that can
> be folded in the middle to create a book.  I can set this up with one
> parameter in WordML.  What are FO's limitations relative to a powerful word
> processor or page layout program?
> 
> Also, does anyone have experience with commercial servers, such as Quark
> Server, In Design Server, PageFlex, etc?  If so, what do these bring to the
> table that FO and WordML can't do?

With FO 1.1 you can construct fairly sophisticated page layouts (multiple
flows, etc.) *if* you know the geometry of the regions on all the pages
going in. This is probably the case for something like menus where you have
a pre-defined layout template and a fairly small amount of content of
consistent size.

What FO cannot do, by itself, is anything that requires feedback from the
layout/pagination process to the FO generation process. That is, FO cannot,
for the most part, do dynamic copy fitting. It is possible to implement
multi-pass processes that use the (proprietary) intermediate output of FO
engines as input to a second or third pass to adjust things.

InDesign and InDesign Server give you pretty much complete programmatic
control over the layout details. With InDesign you can script dynamic layout
based on whatever rules you can program. For something like menus that would
be pretty straightforward (because the rules will be relatively simple). For
something like a heavily-designed publication you'd need something like the
Typefi product, which provides a level of heuristic sophistication you'd
never be able to achieve with brute force scripting.

While InDesign advertises support for XML it is really not a useful feature
except in very narrow use cases, such as database publishing where the XML
structures are repetitive and invariant.

To get from arbitrary XML to InDesign it is much easier to just generate the
InDesign interchange format (INX or, with CS4, IDML).

The DITA2InDesign project on sourceforge (dita2indesign.sourceforge.net)
includes both Java and XSLT 2 code for doing just that. The Java code is
currently limited in that I haven't yet figured out how to calculate the
geometry of objects on pages after the first, but it otherwise enables
programmatic generation of complete InDesign documents. The XSLT code is
designed to generate the text content, that is, the "Story" part of InDesign
documents. At Really Strategies we use it to generate InCopy articles from
XML source, since the InCopy doesn't need to carry any geometry.

I did a proof of concept project a year or so ago using the code that's in
the DITA2InDesign project to generate catalogs from XML-based content
coupled with designer-created template documents. It worked pretty well (at
least for the first page of the result :-)). I'm sure the technique could be
applied to menus as well. It's mostly a matter of working out a way to map
each item in the XML (e.g., the dishes or drinks in the menu) to the
appropriate container on the page. Depending on how sophisticated the layout
is, this can be as simple as generating paragraphs where the paragraph
styles manage the layout details to generating a separate frame or set of
frames for each item.

The main limitation with this approach is that, as with XSL-FO generation,
you have no way of knowing, when you generate the InDesign data, what the
rendered extent of any text is, since that is done by InDesign.

However, having generated a starting point, the scripting to then adjust the
final result as necessary is relatively easy and work-a-day scripting for
InDesign specialists. For example, detecting that a given frame is overset
and adjusting either its geometry or the details of its content is pretty
easy to do with InDesign scripting.

Note also that InDesign Server is just InDesign without a UI and with a huge
license fee--anything you can do with InDesign Server you can do with
standalone InDesign, except deploy it in a server context.

Cheers,

Eliot

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com


Current Thread
Keywords