Re: word processor document format: what parts?
- From: Daniel Veillard <Daniel Veillard w3 org>
- To: Mark Galassi <rosalia cygnus com>, "J. Patrick Narkinsky" <patrick narkinsky ml org>
- Cc: Todd Graham Lewis <tlewis mindspring net>, gnome-list gnome org
- Subject: Re: word processor document format: what parts?
- Date: Sat, 19 Sep 1998 18:41:19 -0400
> [Patrick's discussion of using xml as a basis for *all* word processor
> work, with xsl to do the rendering.]
>
> I think Patrick is completely right, and a really cool processor must
> work that way.
I won't disagree :-)
> If you do that, you end up with a good part of a replacement for
> FrameMaker+SGML which is a cool SGML authoring tool. The missing part
> is the "structure view": a tree view of the structure of your document
> which makes it really great to work with highly structured SGML DTDs
> like DocBook.
Like Amaya [1] or Thot [2] structure view, except that they are not
defined in an XSL syntax but using the concept of "presentation schemas"
(basically the document has a structure and the P schema explain how to
render this structure as one view of it in a separate window).
> The ideal word processor for me would be one that:
>
> * Stores docs internally as SGML or XML (with a particular DTD).
I/O format shouldn't be part of the design of an word processor core
but rather an API for I/O plugins.
> * Applies stylesheets to the marked up text on the fly, and displays
> it WYSIWYG.
I would tend to say the same here, an API for setting up presentation
is important. You may want to use CSS or XSL or whatever kind of presentation
rules the document format you're going to import carries.
> * Has an easy-to-use DSL or DSSSL editor which can be used "on the
> fly" to set how given elements are rendered.
Again avoid binding language specific support into the design.
> * Has a FrameMaker+SGML-style "structure view".
Yep 200%
> * Allows "overrides" so that certain paragraphs can be rendered a
> little differently from how the stylesheet would render them.
Agreed the possibility to have Element based presentation rules
overriding document's one is important.
> * Has full emacs-like extensibility :-)
If through APIs, why not !
If people think really seriously at building this Word Processor
code I *strongly* suggest to have a look at the output of the Opera
project and the Thot editing toolkit [3]. I won't say that you should reuse
the code (while it's possible since it's covered by W3C Copyright now)
but have a good read of the concept and existing APIs. The code is
old-fashionned, and the UI use Motif, but the very inner code handling
the document structure is somewhat stable. The graphic display engine
is a bit too limited for very fancy rendering too.
BTW, XML DOM APIs (my capslock is functionning :-) have a lot of
similarities with the Thot document APIs.
Good reading, I will be happy to provide feedback and suggestions,
Daniel
[1] http://www.w3.org/Amaya/
[2] http://opera.inrialpes.fr/thot/
[3] http://opera.inrialpes.fr/thot/doc/APIman.toc.html
--
Daniel.Veillard@w3.org | W3C MIT/LCS NE43-344 | Today's Bookmarks :
Tel: +1 617 253 5884 | 545 Technology Square | Linux, WWW, rpm2html,
Fax: +1 617 258 5999 | Cambridge, MA 02139 USA | badminton, Kaffe,
http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]