xml-dev - Formatting Objects

[Amy Lewis <amyzing@talsever.com>]

I unfortunately deleted the message to which I want to reply.  The
basic tenet, though, was this (as I read it--I hope the poster will
correct me if I'm wrong): FOs will never be widely accepted, because
one must take into account the rendering characteristics of the target
device in any case.  Therefore the custom dialects of each device are
as useful as FO.

I really don't agree, and to counterpoise the list of failed efforts
similar to FOs, I'd offer Fortran, Postscript, and even original HTML.

Similar arguments were offered when the first compilers were being
developed: all machines are different, and since you can't achieve
independence, its better to write the most efficient machine code for
each platform.  As a result, Fortran was highly optimizing ... for each
machine on which you recompiled.  You might have to tweak, but you
didn't have to rewrite, in a completely different instruction set.

Likewise, Postscript drove all the custom typesetting equipment off the
market.  This is different from FOs, of course (it's a different level
of abstraction), but the technology has gone from one in which each
device had its own custom language that the end user had to use, to one
in which a driver is supplied to transform Postscript into whatever the
machinery understands.  The end user produces well-formed and valid
postscript ....

And HTML succeeded so wildly, in part, because using it, one could be
agnostic about operating systems, about whether the display was
bitmapped or a character grid; it was possible to specify that
something was "a heading" and to be able to trust that it would display
as "a heading" (whatever that means, in device context).

So it's natural that FOs would be associated with the web, and
especially that they'd be increasingly interesting when the web extends
from the CRTs on which it grew up into character-grid and bit-mapped
tiny LCDs, high-resolution paged devices, "display" devices that have
no visuals (sound or touch), and so on.

Even without the impetus to support new breeds of device, anyone who's
had to cope with the vagaries of producing a site that might look
reasonably good in both IE and NS at roughly 800x600, with their
competing and incompatible formatting extensions, is likely to breathe
a sigh of relief if and when the major browsers all respond to the same
instruction set.  Even if they don't respond the same *way*, it's a lot
less painful if they use the same language.  And ideall, browsers will
someday be built around stylesheets to the extent that the "built-in"
way of doing things is just a file shipped with the browser, one that
the end user can customize (or two files--one to be the baseline that
custom sheets could override, one to set styles that can't be changed,
so that invisible fonts and such can be prevented).  Clearly, browser
users aren't going to be writing style sheets any time soon (whether
they're XSLFO or CSS or anything else), but if the internal defaults
were set using some shared, standard language, then the designers could
expect certain kinds of interactions (the end users could set things,
presumably, through dumbed-down dialogs full of pick lists).

Finally ... with XML (not XHTML, but XML "pure," with locally-generated
or vertical market generation of schemas/DTDs), there are no longer
defaults for tags.  Yes, you can run it through XSLT into (some dialect
of) HTML (plus custom formatting information based on the particular
browser detected, using its proprietary language of choice) ... but
why?  What if "Section 2.4" doesn't map to <h2>, but specifically to
"indent twelve ems, set leading to 1.5 times point size, use bold font
of currently selected family ..."?  Sure, it needs adjustment for the
differing requirements of a Palm Pilot, Postscript A4, and a computer
screen ... maybe it even needs adjustment for a computer screen with
75dpi fonts versus one with 120, or adjustment based on the displayable
width ... but at least it's only *one* language for hundreds of devices
... not hundreds of languages (sometimes for the same device, 'cause
the applications are trying to differentiate themselves ...).

FOs may not have come of age ... but I really think that they are going
to be an essential element, down the line.  Treated as a complete, end
to end solution, they'll fall short, but as part of a package designed
for the problem (which would include some ability to get feedback from
the device, to dynamically adjust, and user interaction where
required), I think they're both necessary and useful.

Sorry to be so long winded about it.

Amy!
-- 
Amelia A. Lewis          alicorn@mindspring.com          amyzing@talsever.com
Razors pain you; Rivers are damp; Acids stain you; And drugs cause cramp.
Guns aren't lawful; Nooses give; Gas smells awful; You might as well live.
		-- Dorothy Parker, "Resume"

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************