Re: belle page

Subject: Re: belle page
From: MARK.WROTH@xxxxxxxxxxx (Wroth, Mark)
Date: Tue, 25 Apr 2000 07:55:48 -0700
Brandon Ibach <bibach@xxxxxxxxxxxxxx> and Sebastian Rahtz <sebastian.rahtz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> discussing the implications of extending the functionality of (Open)Jade to incorporate more features of page-sequence or column-set said:

SR> I remember some years ago asking James Clark about this, and he
SR> demonstrated to me that it would be a nightmare for the TeX backend,
SR> because of things like footnotes, floats and sidebars which would all
SR> come out of sequence. Still, maybe it could work.
SR> 
BI>   Perhaps he was referring to implementation of both the page and
BI>column-set objects.  As I mentioned, I believe most of the real
BI>complex stuff comes with the column-set object.
BI>   I'd be interested in your opinion, Sebastian, on the idea of a
BI>direct Postscript/PDF backend.  I know I've brought this up before,
BI>some time back, but it continues to make sense the more I think about
BI>it.  There would have to be a good balance of what is done in the C++
BI>backend and what is done in Postscript itself, but I tend to think
BI>that it wouldn't be too difficult to reimplement TeX's most basic
BI>algorithms for line and page breaking, etc.  It just seems that TeX is
BI>not ideal for DSSSL, given its orientation toward interactive
BI>typesetting.  In fact, I daresay that the process is hindered by the
BI>more advanced features of TeX that DSSSL FOs simply don't need.
[...]
SR>I used to think it was a silly idea. I now think it is more plausible, 
SR>after seeing what FOP has done in the XSL FO world. I am sure of one
SR>thing, which is that JadeTeX as-is is not a viable long-term
SR>solution. David Megginson and I were both naive to think that this
SR>method was really workable. We have three choices, IMO:
SR>
SR> 1. rewrite the jade TeX backend completely, to do a lot more
SR>    preparatory work, and emit much simpler low-level TeX. that still
SR>    buys us a lot
SR> 2. write a new PDF backend, linking in something like Merz' pdflib to
SR>    do the dirty work
SR> 3. write a backend which generates XSL FO, and hope that good engines
SR>    emerge in that area


I have never been convinced that implementing page-sequence in TeX is as difficult as the (informed) opinion on this list would have it.  This may be because I don't _understand_ what is implied by page-sequence, or because I was just looking at page-sequence and not at column-set.
(FWIW, while I won't claim to be a guru of either TeX or DSSSL, I've been working with TeX a *lot* longer than with DSSSL; much of my unwillingness to be too assertive on this topic is not being sure I understand the implications of the DSSSL side).

But this discussion causes me to wonder how much of the confusion is generated by the design decision to base JadeTeX on LaTeX rather than more primitive TeX definition.  While using a LaTeX base certainly simplifies a lot of functionality within the page, it renders TeX's basic page layout mechanisms (which are not exactly transparent to begin with) even more opaque.

I guess what I'm saying is that I think the (PDF)TeX engine is capable of handling everything I understand of the page-sequence and column-set needs.  I'm not trying to imply that the TeX  programming challenge is simple, or even necessarily doable within the time/knowledge constraints we all have.  But I think extending JadeTeX or reimplementing the TeX backend are potential solutions.


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread