[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Proposal for lists/numbered paragraphs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 24 March 2003 16:48, Philip Boutros wrote: > <office:automatic-styles> > <style:style style:name="P1" style:family="paragraph" > style:parent-style-name="First line indent" style:list-style-name="List > 4"/> > </office:automatic-styles> > > <text:unordered-list text:style-name="List 4"> > <text:list-item> > <text:p text:style-name="P1">One</text:p> > </text:list-item> > <text:list-item> > <text:p text:style-name="P1">Two</text:p> > </text:list-item> > <text:list-item> > <text:p text:style-name="P1">Three</text:p> > </text:list-item> > </text:unordered-list> > > > Notice that "List 4" is referenced both by the text:unordered-list and > by the "P1" paragraph style. What if "P1" referenced a different list > style? How would I be required to interpret this? As far as I understand the OO file format, the closest style is that one that overrides the furthest, so the style named in <text:p> is the one that would be used. If the style for every paragraph specifies P1, then the style associated with the overall list won't be used at all - is this correct, Daniel/Michael? > Since the paragraph style already contains the list style information, > from a rendering standpoint in this example the text:unordered-list is > completely redundant and the text:list-item is simply defining a list > level. List level could be easily done with an attribute (which could > default to 1) producing the following alternative XML. > > <text:p text:style-name="P1">One</text:p> > <text:p text:style-name="P1">Two</text:p> > <text:p text:style-name="P1">Three</text:p> > > This all seems like a lot of extra syntax just so HTML generation can > eaisly produce <OL> and <LI> tags. Not only HTML. Any kind of format that needs structure: XSL, Docbook, ... Formats that don't need structure can easily get rid of it, that's easier than figuring out the structure from a non-structured file - although, well, that's what word processors have to do when saving, though (figuring out the beginning and end of each list). Anyway a conclusion of "it's extra syntax, but it's doable and equivalent" (which I agree with), doesn't have the same consequences as a conclusion of "this loses information". That would indeed be a very big problem, but I think we established now that there is no information loss, right? - -- David FAURE, faure@kde.org, sponsored by TrollTech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). How to write a Makefile.am for KDE/Qt code: http://developer.kde.org/documentation/other/makefile_am_howto.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+f0BC72KcVAmwbhARAiDuAKCQ/NiaLOxNB3vJGkNHT/NpF8pJJwCfdEfg LtAnb429Xq8VWmZcpdN8XTI= =QWZb -----END PGP SIGNATURE-----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]