You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Stephan Albers <St...@af-software.de> on 1999/12/02 20:13:04 UTC

XSL:FO and DTP (QuarkXPress)

Kelly Campbell wrote:

> Eventually it would be nice to see something like QuarkXPress for XSL:fo
> though.

Yes, we would like to have that, too. And we have also implemented a
first prototype based upon FOP 0.11.

There are several problems:

1) The only way to talk to QuarkXPress is via it's C/C++ API. Since we
didn't want to go that way, we have used a product called Tags
(http://www.emsoftware.com, 50-200 USD per Quark user) which is a so
called XTension (= PlugIn).

This product reads an external file with XTags. These tags are an
abstraction layer a little bit above the QuarkXPress API. More
important: you just have to write a file instead of developing C
functions via JNI.

More or less you can create frames, insert text, create styles and set
the most important QuarkXPress attributes.

So: via this tool you can talk to Quark without to many problems.


2) The "abstraction layer" of the Quark API is between the FO tree and
the layout tree. So when you want to map FO to Quark, you have to use
both trees to get a reasonable result.

What we did is the following: we took the fo nodes and the layout nodes
and linked both together. So we have "one" tree with both informations.
We call this FLO (formatted layout objects). Then we walk this tree and
generate Quark XTags.

This is some kind of yo-yo process between fo and layout. Whenever the
abstraction layer of fo is to high for Quark, we have to go down to the
layout tree.


3) QuarkXPress doesn't have Tables, so you have to map Tables to frames,
tab stops... When you have a multi line text within one cell, you have
to divide this into multiple lines and takes the tab stops into account.
So even a simple table is relativly complex and stuff like nested tables
is nearly impossible. 


We want to sell this as part of a commercial solution for electronic
catalogs that we are currently developing. Since this is just one part
of our solution we are willing to share this with others, as long as
they also contribute to the development. We could also think of being
paid for dealing with boring proprietary stuff like this, so..

Framemaker is a nice alternative, because it can read/format SGML, has
an import file format called MIF, supports tables and so on. But it
seems everybody wants Quark. By the way, the new Adobe products InDesign
has the same problems.

Stephan