Re: word processor document format: what parts?

["J. Patrick Narkinsky" <patrick narkinsky ml org>]

On Sun, 20 Sep 1998, Todd Graham Lewis wrote:

> Don't forget the case of:
> 
>  	<bogusdoc>
>  	<bold>
>  		This is bolded text
>  	<italic>
>  		This is </bold> italic text
>  		<bold>
>  			This is bold/</italic>italic text
>  		</bold>
> 

That's not well-formed XML.  (XML requires that tags be nested -- such a  
document should be impossible to create).

> Also, one interesting thought which I had was to have a default page
> style, such that one could do:
> 
> 	This is <size=18>some sized text, and<size=normal> this is normal
> 
> Just a little nugget to throw out.

Once again, XML requires that all tags be closed.  So, the above should
really be written as:

<font-size scale default>
	This is <font-size scale=18pt> some sized text, and</font-size>
	this is normal
</font-size>

Syntactic grumbling aside, I would see no problem with defining font
scaling commands which allow for a default size attribute.  You can easily
allow for this in the style sheet associated with the document.

> 
> I, too, have been struggling with the centrality of the editing component.
> I am trying to figure out how not to make it one big opaque mushball,
> and it is proving hard to do.  Again, I was thinking of having a very
> simple document widget which only does the minimum; if you want to insert
> a footnote, then an external footnote-insertion widget walks the document
> widget through doing it.  

I'll go along with that a certain distance.  I think the widget needs to
support multiple views, just as MS Word does.  So, one view should be very
much WYSIWYG, and the footnote would actually display on that view.  On
the other hand, I think their should be a view where the footnote might be
in a seperate frame within the edit widget.  Also, I think that there
should be a view where the tags themselves are displayed (i.e. WP's
'reveal codes', which I miss sorely in Word).

> (By widget, I mean it in the classical sense
> of something undefined, not in the narrow X sense.)  The parts which I see
> as _having_ to be in the editing widget are:
> 
> 	- ownership of the document as private data only accessible
> 		through high-level accessor functions
> 	- display
> 	- actual editing; text insertion as opposed to adding document
> 		elements
> 
> Parts which I think can be external are:
> 
> 	- document import/export/saving; just push/pull to/from the doc
> 		widget.
> 	- markup interfaces.  Changing the font to bold can and should be
> 		done by an external part that calls a 
> 
> 	change_style( (style)bold, (selection)current_selection);
> 
> 		on the document.  No need to hard-code the interface for
> 		those parts into the editing widget; that should be done
> 		on the front end.

I tend to think that the change_style bit should be fairly tightly
integrated with the widget.  It's really a question of where you draw your
line in the sand.   In this case, I think that all core rendering and
element fiddling should be within the edit component (I'm using component
as opposed to widget: it's more clear I think).

On the other hand, I think this should be accessable via an external API
(DOM).  Hence, you could keep your menus and spell checker and stuff
outside this module.

My $0.02

Patrick
 
----------------------------------------------------------------------
If we're to have any luck stanching the vain drain, we just have to 
let nerds be nerds...  Owen Edwards, Forbes Magazine
----------------------------------------------------------------------