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:  
"When this element is present, the lead indent shall become the inside indent and the trail indent shall become the outside indent."

 
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?

  1. Suggested change to the text to say “how each phrase is laid out, where a phrase is any text between two punctuation characters”
  2. Provide a list of possible punctuations
  3. Provide a real life scenario and examples. Consult with NB in Israel to provide the examples.
  4. The handling of directionality has to be explained much more clearly.
  5. There is a need to specify the text base direction at a level above runs (i.e. paragraph), because a piece of text typically contains several runs.  The "bidi" property cannot be use for that purpose, since it explicitly states that it "shall not affect the layout of text within the contents of this 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?  
see also the example on page 227 which mentions an attribute value of -720.

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 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.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.

 

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


Top