Re: [xsl] XSL-FO versus PostScript

[Zack Brown <zbrown@xxxxxxxxxxxxxxx>]

On Thu, Feb 27, 2003 at 08:43:57PM -0700, Jim Melton wrote:
> This will undoubtedly sound like a tautology, but a meaningful answer (one 
> that is highly persuasive for me, at least) is that "XSL FO is XML". If 
> you've ever coded in TeX, or even in LaTeX, you'll have an idea of just how 
> painful it can be.

I've done a lot of TeX work, and I agree it's painful. I also find it
persuasive that XSL-FO is XML. That's why it was my first choice (and
may still be). But as I explain below, I think we're talking past each
other here.

>  I have done very significant amounts of raw TeX coding 
> and have quite a few gray hairs to show for it.  By contrast, writing 
> documents in XML is merely tedious and there are already tools that allow 
> the process to be a bit less painful still.  Once I have a document coded 
> in XML, I can "repurpose" the document from hardcopy (e.g., PostScript) to 
> screen (e.g., PDF) to web browser (e.g., HTML) simply by writing additional 
> stylesheets and then (for XSL FO) rendering the result into the final 
> form.  The ability to have all of my documents in XML is worth quite a 
> lot.  They become searchable (think XQuery), transformable (think XSLT), 
> and (as I just described) repurposable.  None of those things are nearly as 
> true for documents written using TeX.

Yes, but remember, we're talking about using TeX only at the outer rim.
All the documents themselves would still be in XML, it's just that the
XSLT would produce TeX/PS instead of XSL-FO.

Are you saying you like XSL-FO because you write XSLT to process those
XSL-FO files themselves into yet another format? I would guess not. I think
most people, once they've produced XSL-FO files, will not process them with
anything other than standard tools to produce a printable file. To that
extent, XSL-FO might as well not even be XML, since we really won't be taking
advantage of it's XML properties. No? Who uses XPath on an XSL-FO file?

> 
> Now, if you have highly specialized publishing needs, then you need to find 
> the tool/system that does the job you need.  Not very many business 
> documents have a burning need to print text in a spiral on the page, but 
> clearly some do (e.g., advertisements).  XML and XSLT and XSL FO are 
> probably not good candidates for that sort of document.

I wouldn't go that far. I think XML and XSLT are perfectly up to the
task. XSL-FO is the part that seems less good than available alternatives.

>  However, that 
> combination is absolutely dynamite for producing the thousands of pages of 
> documentation that go along with complex software systems, airplane 
> construction, nuclear power plant design, and scores of other applications.
> 
> Message?  Choose the appropriate tool for the job.  Raw PostScript is good 
> at some things and bad at others.  The same is true of Tex, of LaTeX, of 
> XML, of SQL, of Fortran, of Java, etc. etc. etc.  "..very cool..." is 
> certainly one criterion to use, but my boss would much rather pay for 
> useful functionality than the cool factor ;^)

But I don't think we've been talking about the same things. To sum up: you seem
to think I'm advocating using something other than XML for documents. That's
not the case. XML is the way to go. But when processing XML for
printable output, I question whether XSL-FO is the best format to
produce from your XSLT recipes.

Remember: no one writes XSL-FO by hand. In virtually all cases, XSL-FO is
produced by XSLT recipes that process other XML files. Whether you write
XSLT to produce XSL-FO, PostScript, or TeX, I doubt anyone is going to
do anything with the resulting file except print it. Correct? And if
that's the case, then the question I'm raising is, what is the best
format to use for the file being automatically produced?

So far the winner seems to be TeX with PostScript extensions, because it
gives the most power, and still provides higher level features like
kerning, page numbers, footnotes, etc.

Again, this has nothing to do with whether people should use XML to write
their documents. This is strictly about what language to process XML files
*into* via XSLT, to produce printed output.

Be well,
Zack

> 
> Hope this helps,
>    Jim
> 
> At 19:06 2003-02-27 -0800 Thursday, Zack Brown wrote:
> >On Thu, Feb 27, 2003 at 07:52:46PM +0000, David Carlisle wrote:
> >>
> >>
> >> > Wouldn't that be very cool?
> >>
> >> well it would be very familiar at least.
> >> Anyone using a postscript back end to (la)tex typesetting has been able
> >> to do all those kind of things for a couple of decades or so.
> >> I don't think it really fits with the FO model though.
> >> the point of FO is that it intentionally cuts out lots of device
> >> specific processing so that it can be a cross platform language
> >> for specifying the style and layout.
> >
> >But (and I'm not trying to be antagonistic, just trying to make a 
> >decision),
> >why doesn't this restrict XSL-FO to being just a cute example of an XML
> >application? If by using TeX, people can get the power of PostScript 
> >without
> >sacrificing XSL-FO's high level formatting features, then why wouldn't TeX
> >be the proper solution for their problem? Even if XSL-FO is fully device
> >independent, a TeX/PS solution isn't exactly device specific.
> >
> >So to sum up the argument so far:
> >
> >I asked why we should prefer XSL-FO over PostScript, since PostScript is
> >more powerful. The reply was that PostScript didn't have the high level
> >document features provided by XSL-FO. So now my reply is, TeX provides
> >those high-level features, *and* it allows PostScript constructs that
> >give the full power of PostScript to the user. Is there another reason
> >to prefer XSL-FO?
> >
> >Peace,
> >Zack
> >
> >>
> >> In particular in FO there is no feedback from the typeset constructs to
> >> the layout engine so you can't ask as you can in PS or TeX, "does this
> >> fit here" changing that would be a big change to FO.
> >>
> >> David
> >>
> >>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> >>
> >
> >--
> >Zack Brown
> >
> > XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 
> ========================================================================
> Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
> Oracle Corporation            Oracle Email: mailto:jim.melton@xxxxxxxxxx
> 1930 Viscounti Drive          Standards email: mailto:jim.melton@xxxxxxx
> Sandy, UT 84093-1063              Personal email: mailto:jim@xxxxxxxxxxx
> USA                                                Fax : +1.801.942.3345
> ========================================================================
> =  Facts are facts.  However, any opinions expressed are the opinions  =
> =  only of myself and may or may not reflect the opinions of anybody   =
> =  else with whom I may or may not have discussed the issues at hand.  =
> ========================================================================
> 
> 
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 

-- 
Zack Brown

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list