GNOME.org
 

Re: word processor document format: what parts?

On Sun, 20 Sep 1998, J. Patrick Narkinsky wrote:

> > I think that this is not the Right Way(tm).  Consider instead:
> > 
> > <bogusdoc>
> > <style bold>
> >  <font face=arial points=12 weight=bold>
> > </style>
> > <style italic>
> >  <font face=arial points=12 weight=oblique>
> > </style>

Okay, how about replacing:

> > <style bold-italic>
> >  <font face=arial points=12 weight=bold,oblique>
> > </style>

With:

<style name="default.bold.italic">
 <style inherit="default.bold">
 <style inheric="default.italic">
 // Styles in addition to those above go here
</style>

> I have to disagree.  While such an approach could work for a simple case
> such as bold-italic, how would it deal with (for example): 
> 	Nesting Tables Within Tables

I don't see how this is a problem.  Tables are addressed on a cell-by-cell
basis, with a default style for the entire table.

> 	Having a table as part of a list
> 	Having a graphic inside a table

Okay, yes, I see your point.  However, the change I made above addresses
these:

<style name="default.table">
</style>
<style name="default.table.cell.2-2"
 <style inherit="default.table">
 <font weight=bold>
</style>

Perhaps not.  I'm not thinking of putting everything in a markup language,
just styles, ala Document, Paragraph, and Character styles.  Tables and
lists I don't consider styles as much as I do layout.  That is, I wouldn't
expect a table to suddenly become not a table by applying a new style to
it.  Maybe that's wrong.  I don't know.

> If we took the '<bold-italic></bold-italic>' approach for all the possible
> combinations of say, 50 tags, we would be looking at like 50^50

It's n^x where n is the number of states and x is the number of items.

> three, four, and five layer deep nesting.  To cover a maximum of 5 layers
> of recursion avoiding a recursive approach using a mechanism as outlined
> above, we'd be looking at something like ((((50!)!)!)!)!).  My scientific
> calculator chokes on this after the 2nd factorial.

I think this is hardly fair or accurate.

> Furthermore, my impression is that a nested, tree based approach is the
> 'XML way'.  An edit component which cannot deal with it effectively is not
> going to be able to support much of the syntax that XML (and similar
> gidgits such as SGML) has to offer. 

Be that so or not, I think is irrelevant, as long as whatever you're doing
can read and write the format.  Using these styles it's pretty easy to
recreate one from the other.

All I was trying to do was isolate things such as font, point size, etc,
out of the document in replacement of styles such as the rarely used HTML
tags <code>, <author>, etc.

> Secondly, the above approach might still conceivably work if we were
> desiging a single application of XML.  For a lot of reasons (which I have
> discussed earlier), I don't think this is what we want to do.  All the
> style sheet languages have a requirement to support this kind of tag
> within a tag concept. 

You're probably right.  All I was thinking was that when I read in what
you typed as an example, it would internally get coverted to the multiple
<style> sets, which eliminates the recursion in your example.  Tags
typically don't recurse terribly deep, and I don't know enough about CSS
to really argue for or against any particular methodology.

But for lack of better example:

<style sheet="MyStyle.sht">
<html>
<body style="main"> <!-- defined in MyStyle.sht -->
 <table rows=5 cols=2 style="tablestyle">
 <tr><th>Column1
     <th>Column2   <!-- "th" is defined in tablestyle -->
 <tr><td>Data2.1
     <td>Data2.2   <!-- "td" is defined in tablestyle -->
 <tr><td>Data3.1
     <td>Data3.2
 <tr colspan=2><hr>
 <tr style="tableresult"><td>Result1
     <td style="badtableresult">Result2
</table>

It just seems easier to me to have this non-style, formatting/layout tags
be independent "style" type tags.  Is there any provision in XML for text
flows?  I would doubt it, but am no expert.  They seem distincly different
beasts in my mind, but as I said, I could be very wrong.

Christopher
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]