Template for comments and secretariat observations | Date: 2007-08-26 | Document: DIS 29500, Office Open XML File Formats |
1 | 2 | (3) | 4 | 5 | (6) | (7) |
MB1 |
Clause No./ Subclause No./ Annex (e.g. 3.1) |
Paragraph/ Figure/Table/Note (e.g. Table 1) |
Type of com-ment2 | Comment (justification for change) by the MB | Proposed change by the MB | Secretariat observations on each comment submitted |
IL | Section 2.3.1.18 | "mirrorIndents (Use Left/Right
Indents as Inside/Outside Indents)"
, page 94 |
ed | It is not clear how this
interacts with the bidi paragraph property and its effect on the ind
property (see 2.3.1.12). |
While it can reasonably be
implied that mirrorindents functions identically for right-to-left and
left-to-right documents, the explanatory text should be clear.
Change the second sentence as follows:
|
|
IL | Section 2.3.1.45 | "wordWrap (Allow Line Breaking At Character
Level)"
, page 158 |
te | Text in this section says in its first sentence that this element applies only to Latin text. | This element should also apply to RTL scripts (Arabic or Hebrew). | |
IL | Section 2.3.2.18 | "lang (Languages for Run Content)"
, page 191. |
ed | The examples for East Asian Language and Latin language use wrong keywords. | The correct keywords should be respectively "w:eastAsia" and "w:val" (and not "w:bidi" as appearing in the examples). | |
IL | Section 2.3.2.28 | "rtl (Right To Left Text)" , page 213 . |
ed | The first sentence says: "This element
specifies that the alignment and reading order for this run shall be right
to left."
It is not clear how alignment can apply to a run, which may be just a part of a line. Alignment applies to a line or a group of lines (paragraph)? |
Clean up the text a bit to be more clear
specifying what is the main use of the RTL tag and how RTL and LTR text
are being treated.
Also, make clear definition what the term alignment means. Something like “This element specifies the linguistic rules which shall be applied when the contents of this run are displayed.” |
|
IL | Section 2.3.2.28 | "rtl (Right To Left Text)" , page 213 . |
te | The following text says: "This setting
determines the way in which the run contents are presented in the document
when punctuation characters are part of the run's contents. When this
property is specified, each part of the run between a punctuation mark
shall be laid out right to left on the line."
Then appears an example of English text "This is a list: one, two, three." which will be presented as follows when "rtl" is specified: ".three ,two ,one :This is a list" a) The example does not implement the description: it shows how the parts are ordered relative to one another, and not that "each part is laid out right to left". b) It is not clear what is considered punctuation. In particular, are signs like full stop, comma, hyphen-minus, solidus considered as punctuation when appearing within numbers? c) If to judge by the example, this definition of run direction has no practical value. It is hard to find a real-life use case where such an implementation of "rtl" would be useful. d) The run is not well defined as relative to direction: - can a run contain both LTR and RTL text? - can a run contain RTL text together with numbers? e) What specifies the base direction of the run if it contains both LTR and RTL text? f) What specifies how successive runs with different directions are laid out relative to one another? g) The specification does not seem to support directionality at more than 2 levels. How can it handle a Hebrew sentence containing some Latin words quoted inside a LTR paragraph? |
|
|
IL | Section 2.3.2.29 | "shadow (Shadow)"
, page 214 |
te | It say : "This element specifies that the
contents of this run shall be displayed as if each character has a shadow,
displayed beneath the text and to its right." |
For RTL text, the shadow should be displayed beneath the text and to its left. | |
IL | 13) Section 2.3.2.33 |
spacing (Character Spacing Adjustment)
, page 226 |
ed | The description for the val attribute says:
"Specifies a value whose contents shall contain a positive whole number,
whose contents consist of a positive or negative measurement in twentieths
of a point..." Question: how a positive whole number can
have contents consisting of a negative measurement? |
Correct the mistake in the description. | |
IL | Section 2.4.24 | "left (Table Cell Left Border)"
, page 347 |
te | The text should clarify if the meaning of
"left" is affected by possible specification of the bidiVisual element.
If not, this is a contradiction to the second paragraph of section 2.4.1 "bidiVisual (Visually Right to Left Table)" on page 281, in particular of the example appearing there. If yes, the name of this element should be changed to "lead". |
Provide more information on the border
property definitions to make this clearer. Change the name of the property to "lead" as appropriate. |
|
IL | Section 2.4.25 | "left (Table Cell Left Margin Exception)"
, page 353 |
te | The explanatory text mixes mentions of left
margins and bottom margin. We believe that this is an error and all
referred margins should be left margins. The text should clarify if the meaning of "left" is affected by possible specification of the bidiVisual element. If not, this is a contradiction to the second paragraph of section 2.4.1 "bidiVisual (Visually Right to Left Table)" on page 281. If yes, the name of this element should be changed to "lead". |
Correct the use of "bottom” and replace with
"left". Make it more clearly on how this works in RTL
tables. Change the name as appropriate |
|
IL | Section 2.4.26 | "left (Table Cell Left Margin Default)"
, page 355 |
te | The explanatory text mixes mentions of left
margins and bottom margin. This not understood and might be an
error, so that all referred margins should be left margins.
The text should clarify if the meaning of "left" is affected by possible specification of the bidiVisual element. If not, this is a contradiction to the second paragraph of section 2.4.1 "bidiVisual (Visually Right to Left Table)" on page 281. If yes, the name of this element should be changed to "lead". |
Correct the use of "bottom” and replace with
"left". Make it more clearly on how this works in RTL
tables. Change the name as appropriate. |
|
IL | Section 2.4.27 | left (Table Left Border)
, page 357 |
te | the text should clarify if the meaning of
"left" is affected by possible specification of the bidiVisual element. If
not, this is a contradiction to the second paragraph of section 2.4.1
"bidiVisual (Visually Right to Left Table)" on page 281, in particular of
the example appearing there.
If yes, the name of this element should be changed to "lead". |
Provide more information on the border
property definitions to make this clearer. Change name as appropriate. |
|
IL | Section 2.4.29 | "right (Table Cell Right Margin Default)"
, page 365 |
te | The explanatory text mixes mentions of right
margins and bottom margin. This not understood and might be an
error, so that all referred margins should be right
margins. The text should clarify if the meaning of
"right" is affected by possible specification of the bidiVisual element.
If yes, the name of this element should be changed to "trail". |
Correct the use of "bottom” and replace with
"right". Make it more clearly on how this works in RTL
tables. Change the name as appropriate. |
|
IL | Section 2.4.30 | right "(Table Cell Right Border)"
, page 366 |
te | the text should clarify if the meaning of
"right" is affected by possible specification of the bidiVisual element.
If not, this is a contradiction to the second paragraph of section 2.4.1 "bidiVisual (Visually Right to Left Table)" on page 281, in particular of the example appearing there. If yes, the name of this element should be changed to "trail". |
Provide more information on the border
property definitions to make this clearer. Change the name as appropriate. |
|
IL | Section 2.4.31 " | right (Table Cell Right Margin Exception)"
, page 373 |
te | The explanatory text mixes mentions of left
margins and bottom margin. I believe that this is an error and all
referred margins should be right margins. The text should clarify if the meaning of "right" is affected by possible specification of the bidiVisual element. If not, this is a contradiction to the second paragraph of section 2.4.1 "bidiVisual (Visually Right to Left Table)" on page 281. If yes, the name of this element should be changed to "trail".
|
Correct the use of "bottom” and replace with
"right". Make it more clearly on how this works in RTL
tables. Change the name as appropriate. |
|
IL | Section 2.4.32 | "right (Table Right Border)"
, page 375 |
te | the text should clarify if the meaning
of "right" is affected by possible specification of the bidiVisual
element. If not, this is a contradiction to the second paragraph of section 2.4.1 "bidiVisual (Visually Right to Left Table)" on page 281, in particular of the example appearing there. If yes, the name of this element should be changed to "trail". |
Provide more information on the border
property definitions to make this clearer. Change the name as appropriate. |
|
IL | Section 2.4.46 | "tblHeader (Repeat Table Row on Every New
Page)"
, page 421 |
ed | It is not understood why the explanatory text (second paragraph) mentions inheriting the "table cell spacing". This element is neither about cells nor about spacing. | Correct the bug in the spec. | |
IL | Section 2.4.51 | "tblLook (Table Style Conditional Formatting
Settings)"
, page 428 |
ed | the "val" attribute is described as "Two
Digit Hexadecimal Value", but the example is '<w:tblLook w:val="0010"
/>'. It seems to us that "0010" equals 2 only in binary notation, not as hexadecimal value. In other words, 2 is not equal to 4 in most counting systems. |
Correct the bug in the spec. | |
IL | Section 2.18.5 | "ST_BrClear (Line Break Text Wrapping
Restart Location)"
, page 1686 |
ed | The description for value "left" says:
"If this is the leftmost region of text flow on this line, advance
the text to the next position on the line. Otherwise, treat this as
a text wrapping break of type all... If the parent paragraph is
right to left, then these behaviours are reversed."
We don't think this is correct for leftmost region of the line in RTL paragraphs. |
The phrasing should be: "If the parent
paragraph is right to left and this is the leftmost region of text flow on
this line, advance the text to the next position on the next
line." Put in a clearer description here of what happens in an RTL paragraph. |
|
IL | Section 2.18.5 | "ST_BrClear (Line Break Text Wrapping
Restart Location)"
, page 1688. |
ed | The description for value "right" says:
"If this is the rightmost region of text flow on this line, advance
the text to the next position on the next line. Otherwise, treat
this as a text wrapping break of type all... If the parent paragraph
is right to left, then these behaviours are reversed." We don't think this is correct for rightmost region of the line in RTL paragraphs. |
The phrasing should be: "If the parent
paragraph is right to left and this is the rightmost region of text flow
on this line, advance the text to the next position on the
line." Put in a clearer description here of what happens in an RTL paragraph. |
|
IL | Section 2.18.100 | "ST_TextDirection (Text Flow Direction)"
, page 1829. |
ed | It seems that the description of value
"tbRl" is wrong |
Correct description to be: "Specifies that text in the parent object shall flow from top to bottom vertically, then right to left horizontally on the page." | |
Section 2.18.100 | "ST_TextDirection (Text Flow Direction)"
, page 1829. |
ed | There is no value for text flowing Right to Left, Top to Bottom, which leaves scripts like Arabic and Hebrew without proper description. | Add proper description also for text flowing from Right to Left (Arabic and Hebrew). | ||
IL | Section 3.17.7.344 |
The spreadsheet function NETWORKDAYS | te | This function is defined to return the
number of days between two dates, skipping over weekends in its
calculations. However, the definition of "weekend" is not defined. Is it Saturday/Sunday? Friday/Saturday? Thursday/Friday. Different definitions are used in different parts of the world, including Israel. But the OOXML definition misses this fact. |
Correct the NETWORKDAYS function to allow passing in an optional argument that defines which days are weekend days. | |
IL | The whole spec | The whole spec | ge | Unicode directional formatting codes (e.g. RLM and LRM) and other invisible or ambiguous characters should be converted to character entities and those entities should be defined by the OOXML standard. Currently, XML 1.1 doesn't specify character entities for directional formatting code, but it does allow custom entities to be defined by the author/vendor. As a side note, the current OOXML implementation by Microsoft Office 2007 doesn't convert directional formatting codes to entities; they remain invisible in the text. | Unicode directional formatting codes and other invisible or ambiguous characters should be converted to visible characters. | |
IL | Section 2.3.1.6 | bidi (Right to Left Paragraph Layout), page 51 | te | The text of the section says: "his property only affects the set of paragraph-level
properties, and shall not affect the layout of text within the contents of
this paragraph."
This leaves room to interpretation. |
To avoid ambiguity, the text should give a
complete list of the properties which are affected.
Conversely, the description of each such property should specify that it is affected by the orientation. |
|
IL | Section 2.3.1.12 | ind (Paragraph Indentation), page 78-80 | te | Since properties "left", "leftChars", "right", "rightChars" are affected by paragraph direction, their names are misleading. | Rename these properties respectively to "lead", "leadChars", "trail", "trailChars". | |
IL | The whole spec | te | Similar to the previous comment on section 2.3.1.12, wherever the meaning of "left" and "right" their derivatives may be inversed due to right-to-left direction of the concerned element, the names should be changed. | Replace "left" by "lead" and "right" by "trail". | ||
IL | Section 2.3.1.18 | mirrorIndents (Use Left/Right Indents as Inside/Outside Indents), page 94 | te | It seems that the example is wrong. It says that the inside border is on the right on an odd numbered page. It should be the contrary. | Correct the example if needed. | |
IL | Section 2.3.1.37 | tab (Custom Tab Stop), page 141 | te | The text says: "This element specifies a single
custom tab stop within a set of custom tab stops applied as part of a set
of customized paragraph properties in a document."
This seems to imply that those tabs apply at paragraph level. However, on page 142, we find in the description of the "pos" attribute: "Specifies the position of the current custom tab stop with respect to the current page margins." In the case of a RTL paragraph within a LTR page, it is not clear if the pos (tab stop position) value is measured starting from the left (page margins) or from the right (paragraph properties). |
The tab position should start from the right margin in RTL paragraphs. Make this clear in the text. | |
IL | Section 2.4.22 | jc (Table Row Alignment), on page 344 | te | The text says: "The interpretation of property
is reversed if the parent table is right to left using the bidiVisual
element."
Then in the formal description of the "val" attribute on page 345, we find: "The possible values for this attribute are always specified relative to the page, and do not change semantic from right-to-left and left-to-right documents." This looks as a contradiction, or at least
mightily confusing. |
Clarify the meaning. | |
IL | Section 3.8.1, on page 2092 | Alignment | te | The description of attribute "readingOrder" list 3 possible values but does not specify what is the effect of each value. | Define the meaning of the different values of this attribute, add some examples. | |
IL | Presentation | te | It is allowed to use the "rtl" attribute for text strings in a presentation. There is no specification of what should be the effect of this attribute. | Define the effect of the "rtl" attribute in presentation, add some examples. | ||
IL | Page 4367, 4398, 4439, 4476, 4512, 4539, 4576, 4603, 4631, 4666, 4695, 4722, 4734, 4860 | direction | ed | "test" is written instead of "text" (twice for each location) | ||
IL | Whole spec | ed | The description of a property may occurs
tens of times in the document with identical text. For instance, the
description of color, themeColor, themeShade, themeTint appears 37 times
identically in the document.
This inflates the document and makes everybody's work 37 times harder than necessary. |
Remove all identical occurrences except one
and replace physical presence by reference to the unique
occurrence.
This should be done for all property
descriptions, not only those mentioned as examples. Doing so will
reduce drastically the length of the document and make it much more
acceptable. This is very important. |
1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **)
2 Type of comment: ge = general te = technical ed = editorial
NOTE Columns 1, 2, 4, 5 are compulsory.
page of 1
ISO electronic balloting commenting template/version 2001-10
|
![]() |
|