[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: Fri, 15 Oct 1999 17:12:23 GMT
steve schafer
On Fri, 15 Oct 1999 08:33:37 -0500, you wrote:

>Of course not; but what's the point of designing a standard nobody uses?

I would use it. :)

>Arggghhh!  No!  :)  That's is precisely what a formal specification should
>*not* need!  

Absolutely true. But formal specifications are written in English or
some other natural language, and natural languages are notoriously
imprecise. Even in formal specifications, the precise syntax and
semantics are expressed in some mathematical/logical way, be it BNF or
denotational semantics or whatever. And what is a reference
implementation if not a precise mathematical expression of an idea?
Again, the purpose of a reference implementation is not to say, "This
is the way you have to do it," but rather to say, "Given input X, you
must obtain output Y." All of the stuff in between is merely a means
of achieving that end, and can safely be ignored (at least to the
extent that one can assume that it is bug-free, of course).

>Generally if a doc needs specific pagebreaks that can be done in the doc
>markup, or in a stylesheet designed specifically for that document.  But you
>touch on the larger issue of device-(in)dependence.  This is one of the real
>keys to designing a composition and style language that will work for paper
>and for electronic displays, and I find it difficult to define requirements,
>let alone design solutions.  Device independence is good, of course; except
>when it's bad.  If you want a stylesheet to work across a spectrum of
>devices, then I think you want "bands" of device independence on that
>spectrum, since things like display size and resolution may affect
>composition.  For 8 inch wide paper a five-inch line measure is fine, you
>probably want the same line breaks at any resolution, but then again, maybe
>not; you might want to stretch the letters a bit at lower resolution.  For a
>2-inch wide hand-held screen,  I probably don't want a 5 inch measure; I
>want the composition to depend on the size of the display space.  In a
>browser, I might want to sense a change in width and recompose a single
>column into two columns.  Etc.  An interesting language design question is
>how to express such dependencies, and where to locate such expressions.  I'm
>inclined to think this should be in a separate sub-language, so the
>stylesheet itself knows nothing of actual devices.  Otherwise you'd end up
>with a stylesheet full of "case" statements to cover the various device
>possibilities, in which case you'd just as well write multiple stylesheets.

I'm certainly not suggesting that one should be able to create a
single stylesheet that automatically generates perfect output on any
device. Formatting is, at its very core, the art of converting a
conceptual model into something that is displayable on some output
medium. Consequently, it cannot be made independent of the nature of
that output medium. However, there are more similarities than there
are differences, so I don't think it makes sense to have one
formatting language just for video displays, another formatting
language just for laser printers, and so on.

As an example, the Windows GDI does a pretty good job of abstracting
device dependencies out of the way. By taking a few simple precautions
(like ensuring that I perform all of my positioning computations using
device-indpendent units), I can produce effectively identical output
of just about any printer (within the physical constraints of the
device).

Using exactly the same code, I can also produce an on-screen, zoomable
print preview that gives me an accurate picture of what the printed
output will look like, with all of the line breaks in the right
places, etc. On the other hand, if I were to prepare the same document
with online viewing as the goal, the result would _not_ be the same as
that print preview. Instead, I would take into account the advantages
and disadvantages of online display and format the document
accordingly.

I'm not asking for perfection. I'm really not even asking XSL to make
my job easier; my goal is to make my users' lives easier, and if that
means my job is made harder, so be it. All I'm asking for is to be
able to transfer my XSL fo tree from one "XSL-compatible" system to
another, and not be surprised when I view the result. I just don't
have much confidence that XSL, as currently defined, will allow me to
do that.

-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.