[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Requirements regarding ODF lists from
As requested by the TC. Terminology; * User intent; the numbering information that is still visible in a paper copy. So not the name of the style etc. * A list is a set of list-items, spanning several levels. The list is delimited by the intent of the user. Requirements; * Be able to segment all list-items into specific lists. This is used to unambiguously convey the users intent of numbering scope. For example; when a user has a document with 100 list-items total, it should be possible to state clearly that the first 12 items form one list and another 7 items another list. Etc. * Provide rules that allow implementations to read the structured (numbering) data out of an ODF doc and show the same list item labels as all other implementations. The emphasis has to lie with the correct counter over the formatting of the list item (so if the implementation does not support roman numbering, it can show a 4 instead of IV). * Modularity Every list stands alone. Changing one list should not have any effect on other lists. Removing one list should not have any effect on other list. Same with adding a list into a document. * A list style has to be able to be connected (by the implementation) to a paragraph style. So I can have a H1 paragraph style which then auto-applies the corresponding list style. This implies that a) different list styles can be used to make 1 list. b) a list style only specifies the list-formatting for the level it represents. c) start values of each list-level are specified by the list-style applied to the first list-item on that level * To allow any supporting implementation to write out the (user) intended lists using either text:list or numbered-paragraph formatting. This implies a) an implementation would be able to read either structure and then write it out into the other structure without a numbering change. b) an implementation internal data structure should have a representation in either format, preserving user intent. This does NOT imply; 1) both list structures have to have the same featureset. 2) each and every list imaginable has to be convertable to the other format without loss. 3) an implementation internal data structure has to have a representation in either format, with all the implementation-internal structures being preserved without loss. In other words only a representation in -one- of the formats is sufficient. -- Thomas Zander
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]