Re: [office] review ODF 1.2 specification draft - chapter 18,attributes in fo namespace

[Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems<Oliver-Rainer.Wittmann@Sun.COM>]

Dear TC members,

below you find Patrick's reply to my ODF 1.2 draft 7 review comments 
from mid of November 2008.
Unfortunately, we, the TC, did not answer/reply to any of Patrick's 
comments/questions including myself.
I think it is a good time now to come back to reviewing our ODF 1.2 
specification draft in order to finish it.
Thus, comments/questions/clarifications are welcome.

You will post mine as soon as possible (hopefully before today's ODF TC 
call).

Best regards, Oliver.

Patrick Durusau wrote:
> Oliver,
> 
> Thanks for the comments!
> 
> Note that only some of these answers will be reflected in the draft I am 
> posting tomorrow. I passed it to Michael before I finished reviewing 
> these comments. I expect to be dropping new versions every two weeks 
> until we have all the Sun comments incorporated and proofed.
> 
> I invite everyone to review these responses but I want to call your 
> attention to some specific items:
> 
> 1. 18:402 fo:background-color - in particular the question about 
> disabling images for cell, row, table
> 
> 2. 18:408 and 18.409 - objection to deprecating these attributes?
> 
> 3. 18.411 the separator line question
> 
> 4. 18.415 - suggestions for the third editorial note?
> 
> 5. 18.421 - changing default value or value space? Which one?
> 
> 6 18.429 fo:margin-bottom - note question about whether we are 
> announcing a limitation to common styles
> 
> And see the question about header/footer. I don't have any particular 
> position on this but we do need to be clear about what we intend to 
> restrict.
> 
> 7. 18.430.1 fo:margin-right - see the question about removing the 
> description of margins in tables.
> 
> There are a number of attributes that follow with the comment that XSL 
> 1.0 references were missing from ODF 1.1. I don't know if these were 
> intentional or not. Can someone comment on that?
> 
> 8. 18.434 fo:min-height - rule on svg:height and fo:min-height?
> 
> Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:
>> Dear TC members,
>>
>> I have reviewed the attributes in the fo namespace in chapter 18 of our
>> current ODF 1.2 specification draft.
>>
>> Here are my comments:
>> - General
>> -- I am not sure, if it is good to have only the reference to XSL for
>> attributes in fo namespace. Below, you will find some comments to
>> include some sentence about the attribute's purpose. After given such
>> comments to the first reviewed attributes I omit them for the rest and
>> write down this general comment. I think we should decide, if a
>> reference to XSL is enough for such attributes or if some text about the
>> purpose of such attributes for ODF should be added.
>>
> Sure, we could make 18:401 a section that treats fo attributes 
> generally, whether we made all the fo attributes as children of such a 
> section or not. I suspect having a section would be clearer but that 
> should be easy enough to do if we decide to go in that direction.
> 
> If we create such a section, that gives us an easy place to treat issues 
> such as the non-use of inheritance as defined by XSL.
>> - "18.402 fo:background-color"
>> -- Replace the two "ref-element-..." text snippets by the corresponding
>> reference.
> Done.
> 
> Actually, I need to split this out as the semantics of the attribute 
> vary depending upon the element where it occurs.
> 
> For example, one paragraph, it switches off <style:background-image> but 
> that isn't the case for its use with style:text-properties.
> 
> Sigh. Modulo that change my responses to the comments follow:
>> -- Reference to XSL is missing. The former reference to XSL can be found
>> in the ODF 1.2 specification draft 6 in sub chapters 16.4.37 and 16.5.23
> Done.
>> -- 3rd paragraph: Integrate that this statement for paragraph also holds
>> for page, header, footer and section.
> Suggest:
> 
> "This attribute sets the background color for a footer, header, page, 
> paragraph and section. If the value is set to transparent, it switches 
> off any background image that is specified by a 
> |<style:background-image>| . 16.6"
>>
>> -- 4th paragraph: Integrate that this statement for table and cell also
>> holds for row.
> Suggest:
> 
> "Together with the |<style:background-image>| element, this attribute 
> specifies the background properties of a cell, row or table. "
> 
> Question: Is there a difference between paragraphs 3 and 4 other than 
> the elements being described? In other words, if for cell, row and 
> table, the value is transparent, doesn't that disable the image 
> specified by <style:background-image> for cell, row, and table?
>> -- 5th paragraph: Indicate that this statement holds for table, cell and
>> row.
> I am not sure the indirection of fill attributes via <style:style> is 
> really usefully reported by:
> 
> "Fill formatting properties can be used instead of this attribute for 
> enhanced table row and table cell background fill styles. If a value for 
> a |draw:fill| attribute is provided, then a background image that is 
> specified by a |<style:background-image>| element and a background color 
> that is specified with the |fo:background-color| attribute are switched 
> off."
> 
> Even if I add table to this paragraph.
> 
> Can you suggest a better location for this statement? Or perhaps saying 
> something more explicit around the use of <style:style>, etc.?
>> -- Include paragraph which contains statement for frame regarding
>> background according to ODF 1.2 specification draft 6, sub chapter 
>> 16.27.18
> Ok, but could we say, I suppose in some future version, say that the 
> <style:style> element reference for *any* element has all of its style 
> properties? Of any sort?
>> -- Generated section from schema contains twice the statement about the
>> elements the attribute is used with.
> I will ask Michael about that.
>>
>> - "18.403.1 General"
>> -- content of first bullet item has to be <style:graphic-properties>
> True, but that also makes the relationship to the borders for frames 
> indirect (see your next point). Still, the correction should be entered.
>> -- Probably, we can remove the bullet list and replace it by some text
>> like "... specify border properties for page, header/footer, paragraph,
>> cell and frame." Information about the elements the attributes may be
>> used with is already given in the generate section.
> True. But if we change that here, we need to systematically make that 
> change across the standard.
> 
>>
>> - "18:404 fo:break-after" and "18.405 fo-break-before"
>> ad Ed. Note: I do not think that we support value "inherit". The value
>> was not in the schema fragments in the ODF 1.2 specification draft 6.
>> Thus, I think we should add this to the paragraph, which already state
>> that we do not support value "odd-page" and "even-page".
>>
> We don't support the FO inheritance model anywhere so that could be 
> stated for all FO attributes. And then make specific statements values 
> not supported for particular attributes.
> 
> That would substantially change the numbering so we need to do that 
> prior to a public draft if at all possible.
>> - "18.406 fo:clip"
>> -- I have no answers for the two editor notes.
>> -- It seems that we also does not support value "inherit".
>> --> a lot of questions/remarks. Thus, this attribute sub chapter is
>> somehow in status "red" from my point of view.
> OK, does anyone disagree with my reading of the excluded attribute values?
>>
>> - "18.407 fo:color"
>> -- Please include a sentence like "The fo:color attribute specifies the
>> foreground color of text."
>> -- ad Ed. Note 1: I do not know, if we want switch to XSL 1.1. But, if
>> we switch, all XSL references need to be adjusted.
>> -- ad Ed. Note 2: Yes, it seems that we do not support value "inherit".
>> Thus, we have to state it explicitly.
> The XSL reference cites CSS2 to say that this attribute sets the 
> foreground color of text content. Other than convenience, is there 
> another reason for making this statement here?
> 
> Reasoning that all the standard need do is state the rule as briefly as 
> possible, such as by citation of another standard. If I were creating a 
> version of the standard for implementers (which would be far longer than 
> the normative standard) I would include all manner of material from 
> other standards, rather than simply using references.
>>
>> - "18.408 fo:column-count" and "18.409 fo:column-gap"
>> I have got no solution for the remarks in the editor's notes.
> OK, for backwards compatibility (this release only), does anyone object 
> to deprecating both of these attributes? We really should not abuse the 
> FO namespace this way.
> 
> The other part of the solution will be to declare other attributes that 
> should be used in 1.2 for these purposes.
>>
>> - "18.410 fo:country"
>> -- Relation to fo:language: fo-country may be ignored if it is not
>> specified together with fo:language attribute.
>> -- ad editor's note: Yes, it seems we do not support value "none" and
>> "inherit". Thus, we have to state it explicitly.
>> -- Include a paragraph, which states that this attribute specifies the
>> country of a text for its usage in element <style:text-properties>.
> Don't we already have a cross-reference to this attribute under 
> <style:text-properties>?
> 
> Isn't the question what attribute(s) establish locale? And the answer to 
> that is fo:country and fo:language?
> 
> Not disagreeing with the suggestion but thinking that we need to cover 
> locale for all the cases where it is relevant and not on an attribute by 
> attribute or element by element basis.
>> -- Include a paragraph, which describes that fo:country and fo:language
>> are also used to further define sorting algorithms - see ODF 1.2
>> specification draft 6, sub chapters 7.8.1, 7.8.1.8 and 15.10.3.3 - for
>> its usage in elements <text:alphabetical-index-source> and
>> <text:bibliography-configuration>.
>>
> This is my point about the local information again.
> 
>> - "18.411 fo:end-indent"
>> -- Include statements (taken from ODF 1.2 specification draft, sub
>> chapter 16.7.4.2). Probably, we should include this information at
>> element <style:column>:
>> --- that this attribute specifies the right space of a column,
>> --- that this attribute together with the left space (fo:start-indent)
>> of the following column corresponds to the gap between these columns and
>> --- that the width of an existing separator line between these columns
>> is included in these spaces.
>> -- Question: is the reference to XSL ok? We did not have it in ODF 1.2
>> specification draft 6.
>>
> Ah, because we are not describing all "block-level formatting objects." 
> (as does XSL) OK, that makes sense.
> 
> On the separator line I assume you mean:
> 
> "If a columned area contains a separator line between columns, the space 
> that is occupied by the line is contained within the left and right 
> spaces and therefore is not added to them."
> 
> OK, so: "A separator line may appear in the space between columns that 
> is specified by the fo:end-indent and fo:start-indent attributes. The 
> width of the line is not added to the value of either attribute."
> 
> So, does that space operate as a constraint on the separator line? That 
> is it cannot be bigger than that space? Must it be centered on that 
> space or is other placement possible?
>> - "18.412 fo:font-family"
>> -- Include statements (taken from ODF 1.2 specification draft 6, sub
>> chapter 16.4.14)
>> --- that the attribute specifies the font family of a text and
>> --- that this attribute can be used instead of the style:font-name
>> attribute, but usage of style:font-name is recommended.
>> -- Generated text contains twice the statement about the element with
>> which the attributes may be used.
>>
> Shouldn't we simply deprecate this attribute? And if we do, do we really 
> want to make it any easier to use?
> 
> My sympathies are for taking your advice on the font family, etc., that 
> is to fully describe even deprecated material but that may simply 
> encourage it use.
> 
> I have no axe to grind one way or the other.
> 
>> - "18.413 fo-font-size"
>> -- 3rd paragraph does not belong to this attribute - it more belongs to
>> fo:font-family.
> Yes.
>> -- Information about values given in ODF 1.2 specification draft 6, sub
>> chapter 16.4.19 is completely missing.
>> -- We should explicitly state which attribute values from XSL we do not
>> support.
>> -- I do not think that this attribute should be deprecated.
>>
> You mean such as:
> 
> "The value of these attribute is either an absolute length or a 
> percentage as described in §7.8.4 of [XSL]. In contrast to XSL, 
> percentage values can be used within common styles only and are based on 
> the font height of the parent style rather than to the font height of 
> the attributes neighborhood. Absolute font heights such as |medium|, 
> |large|, |x-large|, and so on, and relative font heights such as 
> |smaller|, and |larger| are not supported."
> 
> I think it needs cleaning up but yes you are correct, that needs to be 
> added back in.
> 
> The other paragraphs, which are references to other font size attributes 
> are more problematic.
> 
> The organization of the document to split out the attributes into 
> individual sections has a cost. That is that every attribute, even if 
> intimately related to another, has its own separate existence and 
> description.
> 
> My suggestion would be for cases like this one, where the reader is 
> likely to want information about other fonts (we have a similar 
> situation) is to create Notes (this means non-normative text) that 
> directs their attention to the other material.
> 
> My take is that solves the need for related information and at the same 
> time preserves the ability to single out any particular element or 
> attribute for additional information or annotation.
>> - "18.414 fo:font-style"
>> -- We should explicitly state which attribute values from XSL we do not
>> support.
>>
>> - "18.415 fo:font-variant"
>> -- ad 1st editor's note: see my comment above - 18.407
>> -- ad 2nd editor's note: not supported values from XSL should be
>> explicitly named.
>> -- ad 3rd editor's note: I have no solution. --> status "red"
>>
> Does anyone else have an opinion on the 3rd editor's note?
>> - "18.417 fo:height"
>> -- Include statement that this attribute specifies the height of the
>> bullet image in a certain list level definition.
>> -- ad editor's note:
>> --- explicitly name not supported XSL attribute values.
>> --- I do not know, if this attribute is only used for specifying the
>> size of a bullet image. Action item for me: check it in OpenOffice.org.
>>
> Well, in draft 6, 16.12.6 says that the size of the image is specified 
> by this and fo:width. Maybe used more broadly but I am just going by the 
> language in the text.
>> - "18.418 fo:hyphenate"
>> -- ad editor's note:
>> --- Yes, we have to explicitly state that we do not support value 
>> "inherit".
>> --- No answer from my side to the other questions in the editor's note.
>> I think these question are also for the other fo:hyphenation-...
>> attributes. Right?
>>
> Yes, other fo:hyphenation attributes.
>> - "18.419 fo:hyphenation-keep"
>> -- Explicitly state that we do not support values "column" and "inherit".
>>
>> - "18.420 fo:hyphenation-ladder-count"
>> -- Explicitly state that we do not support value "inherit".
>>
>> - "18.421 fo:hyphenation-push-char-count"
>> -- Default value can not be 0, because the value type of this attribute
>> is "positiveInteger", which does not include 0. XSL states that its
>> value is of type "integer" and that negative and non-integer values are
>> mapped the nearest integer greater than 0.
>> Possible solutions:
>> - change type of attribute to "nonNegativeInteger" or
>> - change default value.
>> -- Explicitly state that we do not support value "inherit".
>>
> OK, more questions:
> 
> 1) Changing the default value has the greatest chance of causing 
> backwards compatibility issues. Yes?
> 
> 2) If #1 is yes, I asssume we can use nonNegativeInteger and leave the 
> default alone?
> 
> I prefer the solution with the least impact on existing applications but 
> don't have a feel for that issue.
>> - "18.422 fo:hypenation-remain-char-count"
>> -- [the same as for fo:hypenation-push-char-count - see above]
>>
>> - "18.423 fo:keep-together"
>> -- Please state that this attribute is used for paragraphs and table 
>> rows.
>> -- Yes, state that we do not support value "inherit" and integer values.
>>
> Because narrower than XSL?
> 
> Isn't that already stated by it only appearing on row and paragraph 
> element elements?
> 
> Still, I think your point that our divergence from XSL should be called 
> out.
>> - "18.424 fo:keep-with-next"
>> -- Reference to XSL is wrong. It has to be "§7.19.4", not "§7.9.14".
>>
> Yes. Thanks!
>> - "18.425 fo:language"
>> -- Yes, we do not support values "none" and "inherit".
>> -- The "corresponding" comes in due to copy-and-paste from original
>> section, in which also style:language-asien and style:language-complex
>> are specified. IMHO it can be removed. Thus, fo:country and fo:language
>> "go together". The same is hold for style:country-asien and
>> style:language-asien. And for style:country-complex and
>> style:language-complex, too.
> So, delete: "This attribute may be ignored if it is not specified 
> together with a corresponding |fo:country| attribute."
> 
> Yes?
> 
> I was am planning on a joint treatment of fo:language and fo:country as 
> locale. Just need to find the right place for it.
>> -- Include a paragraph, which describes that fo:country and fo:language
>> are also used to further define sorting algorithms - see ODF 1.2
>> specification draft 6, sub chapters 7.8.1, 7.8.1.8 and 15.10.3.3 - for
>> its usage in elements <text:alphabetical-index-source> and
>> <text:bibliography-configuration>.
>>
> Locale issue.
>> - "18.426 fo:letter-space"
>> -- Yes, we do not support values "space" and "inherit".
>>
>> - "18.427 fo:line-height"
>> -- 2nd setences of 1st paragraph should be removed. It is the same as
>> the 2nd paragraph.
>> -- Yes, we do not support values "number", "space" and "inherit".
>>
> Delete: "A value of |normal| disables the effects of 
> |style:line-height-at-least| and |style:line-spacing| ."
>> - "18.428 fo:margin"
>> -- Yes, we should state that we do support only one value, which can be
>> a length or a percentage. A percentage is relative to the parent style's
>> margin - like it is for the other fo:margin-... attributes.
>>
>> - "18.429 fo:margin-bottom"
>> -- Yes, we do not support value "auto" and "inherit".
>> -- Yes, in general we do not support value "inherit" from XSL
>> attributes, but for value "auto" I do not think this is true - see
>> fo:keep-together and fo:hyphenation-keep.
> Yes.
>>
>> -- For a percentage value we should state that the bottom margin value
>> is the given percent value of the parent style's bottom margin value.
> With the caveat that is true within a common style, or at least so says 
> the prior draft. Is that a limitation/constraint?
>> -- Information is missing that a percentage value is not supported for
>> <style:graphic-properties> - see sub chapter "16.27.5 Top and Bottom
>> Margins" of ODF 1.2 specification draft 6.
> Sorry, 16.27.5 in draft 6 says:
> 
> "The |fo:margin-top| and |fo:margin-bottom| attributes determine the top 
> and bottom margins to set around a frame. See section 16.5.20. 
> Percentage values are not supported."
> 
> I searched on style:graphic-properties and did not find the limitation 
> you mention.
>> -- Information is missing that for page footers attribute
>> fo:margin-bottom is ignored - see sub chapter "16.3.2 Margins" in ODF
>> 1.2 specification draft 6.
>>
> Yes, but that text says: "Bottom margins are only evaluated for headers, 
> top margins only for footers."
> 
> Since this can appear in <style:paragraph-properties> (since paragraph 
> elements appear in headers and footers) do we mean a processing 
> constraint, i.e., if you see fo:margin-bottom being applied in a 
> paragraph in a footer element ignore it or is this a validity 
> constraint? That is to say the XML itself is invalid?
>> - "18:430 fo:margin-left"
>> -- Information is missing that a percentage value is not supported for
>> <style:graphic-properties> - see sub chapter "16.27.5 Left and Right
>> Margins" of ODF 1.2 specification draft 6.
> I don't see that restriction.
> 
> In 16.27.5, simply says that percentage values are not supported around 
> frames.
> 
> Ah, ok, I ran it to ground. What you mean is that when the prior draft 
> said "not supported for frames" it was actually stating a restriction on 
> <style:graphic-properties>. Rather indirect.  ;-)
> 
> I will restore it but stated more directly.
>> -- Percentage value for section also does not make sense - see sub
>> chapter "15.7.2 Margins" in ODF 1.1 specification. Or do we changed this
>> for ODF 1.2 - I did not find a corresponding proposal.
> I don't have any notes suggested that this was changed.
> 
>>
>> -- The second and third paragraph should be removed. They should be
>> integrated into element <style:list-level-label-alignment>. For
>> <style:list-level-lable-alignment> percentage values does not makes
>> sense and need to be excluded. -> I have given me an action item to
>> provide the corresponding text.
> Agreed.
>> -- 5th paragraph about fo:text-indent can be removed in my opinion - it
>> is already present at attribute fo:text-indent.
>> -- In last paragraph the information about right margin in tables should
>> be removed.
>> -- For a percentage value we should state that the left margin value is
>> the given percent value of the parent style's left margin value.
> Yes.
>>
>> -- Question to the schema experts: Can the schema assure certain value
>> types in certain elements? Than we do not have to state in prose that in
>> certain elements percentage values are not supported.
>>
> Well, sure, you simply define an attribute or attribute group with the 
> value restrictions that are desired. The problem here is that we use a 
> reference to another definition of the attribute and restricting that 
> value set. There are schemas where that can be done but I haven't looked 
> closely at XSL with that in mind.
> 
> 
>> - "18.430.1 fo:margin-right"
>> -- This sub chapter should be a sub chapter of chapter "18 Attributes".
> Yes.
>> -- Information is missing that a percentage value is not supported for
>> <style:graphic-properties> - see sub chapter "16.27.4 Left and Right
>> Margins" of ODF 1.2 specification draft 6.
> Yes, but see my suggestion about restating this restriction more 
> directly under fo:margin-left
>> -- Percentage value for section also does not make sense - see sub
>> chapter "15.7.2 Margins" in ODF 1.1 specification. Or do we changed this
>> for ODF 1.2 - I did not find a corresponding proposal.
> Nor did I.
>> -- 3th paragraph about fo:text-indent can be removed in my opinion - it
>> is already present at attribute fo:text-indent.
>> -- In last paragraph the information about left margin in tables should
>> be removed.
> Why?
> 
> Has the behavior we defined changed?
>> -- Yes, list item does not have a right margin via its list level
>> properties, which are applied via the list style.
>>
> OK.
>> - "18.431 fo:margin-top"
>> -- Yes, we do not support value "auto" and "inherit".
>> -- For a percentage value we should state that the top margin value is
>> the given percent value of the parent style's top margin value.
>> -- Information is missing that for page headers attribute fo:margin-top
>> is ignored - see sub chapter "16.3.2 Margins" in ODF 1.2 specification
>> draft 6.
>>
> See my comment on bottom margins above.
>> - "18.432 fo:max-height"
>> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was
>> the reason to include it? Was it intention not to have it or was it a
>> defect?
> I don't know if it why it was omitted. To correct for XSL 1.0, the 
> citation would be to 7.14.6.
>>
>> - "18.433 fo:max-width"
>> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was
>> the reason to include it? Was it intention not to have it or was it a
>> defect?
>>
> I don't know if it why it was omitted. To correct for XSL 1.0, the 
> citation would be to 7.14.7.
> 
>> - "18.434 fo:min-height"
>> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was
>> the reason to include it? Was it intention not to have it or was it a
>> defect?
> I don't know if it why it was omitted. To correct for XSL 1.0, the 
> citation would be to 7.14.8.
>> -- 1st paragraph should also state that it specifies the minimum height
>> of a text box.
>> -- It should also be stated that the attribute specifies the minimum
>> height of a header or a footer - see sub chapter "16.3.1 Fixed and
>> Minimum heights" in ODF 1.2 draft 6
>> -- Ad editor's note: It is meant that svg:height specifies the fixed
>> height for a header or footer, while fo:min-height specifies the minimum
>> height for a header or a footer, in my honest opinion.
>>
> Well, but for text box (9.3.1 in ODF 1.1) we say that fo:min-height 
> overrides the svg:height.
> 
> Isn't that inconsistent with saying that svg:height specifies a fixed 
> height and fo:min-height sets a minimum height?
> 
> At least with the override language, there really is only one height if 
> both are present. Yes?
> 
> Well, draft six unhelpfully says svg:height and fo:min-height set fixed 
> or minimum height for a header or footer. That implies there is a choice 
> but it doesn't say which one.
> 
> Suggestions?
> 
>> - "18.435 fo:min-width"
>> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was
>> the reason to include it? Was it intention not to have it or was it a
>> defect?
>> -- Ad editor's note: svg:height specifies the height of a text box,
>> while fo:min-width specifies the minimum width of a text box, in my
>> honest opinion.
>>
> I don't know if it why it was omitted. To correct for XSL 1.0, the 
> citation would be to 7.14.9.
>> - "18.436 fo:orphans"
>> -- We do not support value "inherit".
>> -- We strict the attribute for paragraph orphans.
>>
>> - "18.437 fo:page-height"
>> -- We only support value type "length"
>>
>> - "18.438 fo:page-width"
>> -- We only support value type "length"
>>
>> - "18.439 fo:padding"
>> -- We only support one value of type "NonNegativeLength"
>>
>> - "18.440 fo:padding-bottom" till "18.443 fo:padding-top"
>> -- We do not support value "inherit"
>>
>> - "18.444 fo:space-after" and "18.445 fo:space-before"
>> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was
>> the reason to include it? Was it intention not to have it or was it a
>> defect?
>> -- We restrict its usage to a column.
>> -- We do not support value "inherit".
>>
> I don't know if it why these were omitted. To correct for XSL 1.0, the 
> citation would be to 7.10.6 and 7.10.5, respectively.
>> - "18.446 fo:start-indent"
>> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was
>> the reason to include it? Was it intention not to have it or was it a
>> defect?
>> -- We restrict its usage to a column.
>>
> I don't know if it why it was omitted. To correct for XSL 1.0, the 
> citation would be to 7.10.7
> 
> Note since we do restrict to column and not all block-level formatting 
> objects.
>> - "18.447 fo:text-align"
>> -- Include statement that this attribute is used for alignment of
>> paragraphs and the alignment of list labels.
> It already treats list labels. I take it that you want a more general 
> statement about paragraphs and then the list label material. Works for me.
>> -- Move information of 2nd paragraph, the following enumeration and the
>> 3rd paragraph to element <style:list-level-properties> -> I have given
>> me an action item to provide the corresponding text.
> OK.
>> -- Add information to 4th paragraph that this is hold for the alignment
>> of paragraphs.
>>
> OK.
>> - "18.449 fo:text-indent"
>> -- ad editor's note: I will provide some text about it for element
>> <style:list-level-label-alignment>. Here we should only add at the end
>> of the 1st sentence the text "or a list item".
>>
> OK>
>> - "18:451 fo:text-transform"
>> -- Question: Is it really deprecated? I did not find the corresponding
>> proposal.
>>
> No, my mistake. It cannot be used with| fo:font-variant, if it is, the 
> result is undefined. |
>> - "18.452 fo:widows"
>> -- We do not support value "inherit".
>> -- We strict the attribute for paragraph widows.
>>
>> - "18.453 fo:width"
>> -- In ODF 1.2 draft 6 and ODF 1.1 we had no reference to XSL. What was
>> the reason to include it? Was it intention not to have it or was it a
>> defect?
>> -- We restrict its usage to the image of the list label, as far as I can
>> see.
>>
> I don't know if it why it was omitted. To correct for XSL 1.0, the 
> citation would be to 7.14.12
>> - "18.454 fo:wrap-option"
>> -- I am not familar with this attribute. Thus, the status of this
>> attribute is somehow "red".
>>
> Comments on this one would be most welcome.
> 
> Deeply appreciate the comments!
> 
> Hope you are at the start of a great day!
> 
> Patrick
> 


-- 
=======================================================================
Sun Microsystems GmbH    Oliver-Rainer Wittmann
Nagelsweg 55             Software Engineer - OpenOffice.org/StarOffice
20097 Hamburg
Germany                  Fax:   (+49 40) 23 646 955
http://www.sun.de        mailto:oliver-rainer.wittmann@sun.com
-----------------------------------------------------------------------
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

=======================================================================
Oliver-Rainer Wittmann (od) - OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS