Lists Home |
Date Index |
- From: "Paul Tchistopolskii" <firstname.lastname@example.org>
- To: "Michael Leventhal" <email@example.com>, "XML Developers' List" <firstname.lastname@example.org>
- Date: Wed, 9 Jun 1999 18:17:21 -0700
>> Claim 3 Print has no place on the web.
> I said the Web is "not about paper documents" and the web was not the
> place to do page composition. Everyone likes to be able to print
> documents, that isn't the issue, it is whether you should expect to get
> FrameMaker+SGML documents out of a web browser or not using
> a page composition engine.
One practical comment. Even Web is "not about paper documents"
( actualy I don't understand what does it mean ) there is some constant
need to place documents with complex layouts to the Web. (It's why we
have a buch of RTF2HTML, MIF2HTML e t.c. converters, Net-It startup
e t.c.). I spent a couple of months implementing '1-to-1' converters for
RTF and MIF, trying to keep tables, N-columns layouts e t.c. Of course
supporting all the goods is impossible with HTML, but it is not my point.
With MIF you can ( more or less ) do XML / CSS without reimplementing
FrameMaker rendering engine, because MIF keeps columns content
separated ( thanks to Frame ). With RTF if you want to render layout
with 2 columns and if you want to go XML / CSS you *should*
reimplement some *significant* part of Word rendering engine
( simply to understand where the contents of first column ends ;-)
It's why MS Word from Office 2000 still has some ...problems ... with
complex RTF layouts...
Being implemented, FO can handle both RTF and MIF resanobly easy
( resanoble and easy ).
I'm just saying that FO model can handle some things with
complex layouts *much* better than CSS / DOM e t.c and people
*do* need complex layouts on the Web.
> XSL-FO does not provide any clear advantages over CSS formatting and
> CSS is, in fact, a powerful formatting language for XML.
That is not true. Mapping complex RTF document to FO is doable. Mapping
it to CSS seems to be *impossible* without rewriting significant part of
rendering engine ( or FO engine ;-). The funny thing is that after
XSL FO you *can* render such things to CSS, because ... well ... XSL FO
rendering is hard to implement, but being implemented it is powerful.
Of course, you can replace 'RTF' with 'FORMAT X' ( even FORMAT X would
be XML. Nobody can predict what particular XML would be created by
some vendor in the future ).
> If the goal of all this were just to write a formatter. So are you
> willing to say that as a general transformation engine XSL is not really
> useful and that it really is designed only to provide one part of a
> page composition engine
Maybe you are right. Maybe some day it would be possible to redesign
FO and CSS so that :
XSLT would be for transformations
FO objects would handle page composition
CSS objects would handle single page
( Definately, CSS objects have many common with FO objects, where
FO is a superset of CSS. Actualy some kind of mapping FO's to
some kind of CSS already inside FO implementations on the level
of internal structures. ;-)
Or something like that. Until such redesign:
XSL already has XSL
XSL already has FO
XSL already has superset of CSS
As a result - it is very powrful engine and when first FO implementation
would appear, it'l be not easy for you to beat it with DOM / CSS
( especialy if you'l be asked to do something that deals with N-columns
RTF document ;-)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)