Hi,
David Faure wrote:
> -----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.
That's correct.
>
> 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?
That's correct as well.
>
>
>>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).
That's, from my point of view, a very valid argument. Having list
elements does not simplify transformations to HTML only, but to many
other formats as well, especially to those, that use these standardized
formats (HTML, XSL-FO, etc.) as a base. Moreover, the list elements from
my point of view represent a structure that in many cases really is
present in a document: If one numbers a paragraph in a document using
whatever word processor and inserts a new one, the new paragraph gets a
number as well, so the intended use of numbered paragarphs is to create
list. Taking this into account, I think we should at least not remove
the list elements.
However, the problem remains that in word processors, one might create
documents that contain numbered paragraphs that are distributed over the
whole document and that therfor are no "traditional" lists. The question
from my point of view is whether we need a new element for these kind of
paragarphs, or whether we consider them a non-stanadard application of
lists that does look a little bit strange in the file format, because
the structure of the document is strange in fact.
>
> 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?
In fact, there is no loss of information when using lists.
Best regards
Michael
>
> - --
> 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-----
>
>