ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Simon Pepping <spepping@scaprea.hobby.nl>
Subject: Re: XSL-FO
Date: Sun, 30 Dec 2001 13:03:36 +0100	[thread overview]
Message-ID: <20011230130335.B604@scaprea> (raw)
In-Reply-To: <5.1.0.14.1.20011228104722.03ee6ae8@server-1>; from pragma@wxs.nl on Fri, Dec 28, 2001 at 10:55:41AM +0100

On Fri, Dec 28, 2001 at 10:55:41AM +0100, Hans Hagen wrote:
> At 05:12 PM 12/27/2001 +0000, Marco Kuhlmann wrote:
> >     Hi all.
> >
> >Has anyone any experience with XSL-FO? Is it a standard that is
> >far enough to be used in preparing print layouts? For example,
> >does it have the same expressivity as ConTeXt? Would it be
> >possible and meaningful to implement a ConTeXt backend for
> >formatting objects? There are programs like passivetex; how
> >easy would it be to implement something similar in ConTeXt?
> >
> >Any hints would be appreciated.
> 
> (also see berends reply)
> 
> afaik formatting object is like putting boxes together;
> 
> xml -> (with xslt) xml-fo -> tex -> pdf
> 
> in many cases (esp when dealing with documents) the xml-fo stage is not 
> needed at all;
> 
> so far i never ran into an fo, but i may some day as part of a doc (i can 
> imagine that for instance sub apps spit out fo's); in that case an extended 
> version of \framed is probably enough to implement it; when the moment is 
> there, i will probably cook up such an extended framed, but it's low on my 
> list of priorities [but you may expect much more xml support next year in 
> context]
> 
> taco may have more to say about this since he's working with fo's

The standard is certainly usable. But I do not think it has the same
expressivity as Context.

In fact it is a bit hard to judge, because it depends on the available
implementations. It is an abstract layout description, consisting of
block areas and inline areas, which are fine tuned with a large array
of properties. Implementations should use this description to produce
an actually formatted document. It is possible that, when one reads
the spec carefully and has a complete implementation, i.e. one that
implements all FOs and properties that the spec provides, a powerful
expressivity results; I just do not know.

Sebastian Rahtz has produced passivetex, which, together with xmltex
as its XML parser, is an implementation. It is not complete. Earlier,
Sebastian has done similar work for SGML and DSSSL, producing
jadetex. Despite the large amount of work, that is also not a complete
implementation. A complete implementation is just huge.

Making an implementation in Context would duplicate
passivetex. Because Context's XML parsing support is under active
development, it might make sense. One should be able to parse a FOT
file, which is an XML file containing only FO elements. Parsing and
using all the properties, together with the default properties, is not
easy. I believe xmltex is not actively maintained, but it is
sufficient to parse a FOT file.

A lot of Sebastian's work concerns the mapping of Unicode to TeX
symbols. Although this is done in terms of LaTeX symbol names, much of
it might be reusable in Context, giving a head start.

I believe passivetex was plagued by the fact that the logical model of
an FO tree is different from TeX's logical model. An FO tree is
strictly hierarchical, which should be translated into a flat
horizontal and vertical list. Perhaps it is better to start from
scratch and write a typesetting engine with the FO view of a document
in mind. That is what is being done by the FOP project,
http://xml.apache.org/fop/index.html, and by some commercial
implementations, e.g. RenderX, http://www.renderx.com, and Antenna
House, http://www.antennahouse.com/. In my article in the EuroTeX2001
proceedings I have described an idea to implement FOs directly in NTS,
not via macros; but I have not done anything in that direction.

For DSSSL, jadetex is by far the most widely used backend, as it is
called there. One might even say that without jadetex DSSSL would not
be a practical option for most of its users. The use of SGML Docbook
in the Open Source community would not have grown as it did without
it. In XML this is not so; the active community is much larger, and
much more work is spent on FO implementations.

See Sebastian and Michel Goossens' article in the TUG2000 Proceedings
for some fine examples of what they have achieved with passivetex.

See also my tutorial at EuroTeX2001,
http://www.ntg.nl/eurotex/presentations/.

-- 
Simon Pepping
email: spepping@scaprea.hobby.nl


      reply	other threads:[~2001-12-30 12:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-27 17:12 XSL-FO Marco Kuhlmann
2001-12-27 18:01 ` XSL-FO Berend de Boer
2001-12-28  9:55 ` XSL-FO Hans Hagen
2001-12-30 12:03   ` Simon Pepping [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011230130335.B604@scaprea \
    --to=spepping@scaprea.hobby.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).