[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Nostradamus (was Re: FO. lists as tables)

Subject: Re: Nostradamus (was Re: FO. lists as tables)
From: pandeng@xxxxxxxxxxxx (Steve Schafer)
Date: Wed, 20 Oct 1999 03:30:55 GMT
nostradamus lost text
On Mon, 18 Oct 1999 10:42:58 +0100 (BST), you wrote:

>To be called TeX the system just needs to conform to a certain
>specification that means that it gives effectively identical output
>for a given input.

Let me emphasize a point that I think has gotten lost: I'm not saying
that an XSL user should be _required_ to specify everything down to
the last millipoint. It's like the difference between ordinary blocks
and absolutely-positioned blocks; with ordinary blocks, you rely on
the formatter to do a "decent" job of positioning. So it should be
with line-breaking and hyphenation. If you don't care, let the
formatter use its default algorithm; if you _do_ care, you should be
able to specify a particular behavior. A general-purpose formatting
specification should allow both approaches.

>These are the sort of things that let the various commercial TeX systems
>compete with each other. But for the purposes of this discussion they
>may all be lumped together as one system `tex'. Surely the aim of the
>game is to widen the interoperability so that files may be shared
>between these systems and frame and word and fop and renderx and
>friends.

But to what end? While there are numerous variations on a theme, the
business of formatting text and graphics is fairly well understood.
It's not like an XSL processor can be really "innovative" in the way
it formats text. If the XSL specification is sufficiently
comprehensive, then I believe that we'll have even better
interoperability between diverse systems, because they will be able to
more precisely specify their formatting intentions.

>Yes but a lot of that is people using undocumented non standard
>extensions for one browser then trying to hack in code so that it
>doesn't break the other browsers, or using `valid' css constructions
>that when implemened by the browser make the text just vanish.
>This is rather different to the situation of two fully coforming xsl
>renderers which both style each text block as specified, but produce
>different line and page breaks (which are not part of the
>specification).

Experience simply doesn't bear this out. Look at the HTML behind all
those commercial web pages out there. Web designers want _absolute_
control over the appearance of their pages, and will go to incredible
lengths to achieve it. As for print media, a book designer may not
care so much, but a designer of advertising brochures certainly will.

If XSL doesn't give them this level of control, the browser and
formatter vendors will continue to introduce mutually-incompatible
extensions, and we'll be in no better shape than we are today.

-Steve Schafer


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.