Multiple sections in Ecma 376 (eg in Part 4, Section 2.15.3.26, Part 4, Section 2.15.3.31, Part 4, Section 2.15.3.32) specify implementation which is never defined. This makes it impossible for external implementators to implement the standard because there is no definition to follow.

Ecma 376 should be thoroughly reviewed to remove any vague and non-defined references.

Part 4, Section 2.15.3.26, Part 4, Section 2.15.3.31, Part 4, Section 2.15.3.32

te

Proposed Disposition of DIS 29500 Comment MY-0019 (Modified: 2008-01-13) Agreed; we will fully define the information necessary to implement each compatibility setting which was not previously completely described. In addition, we will remove each of these settings (and all other application compatibility settings) from their current location in the specification (Part 4, §2.15.3, pages 1,368-1,487), and place them into a new annex for deprecated features. Following the precedent set by other ISO standards (such as SQL’s ISO 9075:2003 Part 1 and C++’s ISO/IEC 14882:1998), we will make use of a new Annex that contains normative descriptions of all deprecated features. The intent of this Annex is to enable a transitional period during which existing binary documents being migrated to DIS 29500 can make use of those deprecated features to preserve their fidelity, while noting that new documents should not use them. Accordingly, the Conformance clause will also be changed to state that newly created documents (those not created by migrating existing binary documents) should not use deprecated features. All deprecated features will be removed from their current locations in the standard, but will be fully defined in this new Annex. The complete definition of these settings (including each setting identified by at least one National Body comment) is provided below. In each case, the text replaces the content currently specified for that setting: Part 4, §2.15.3.6, pages 1,378-1,379: 2.15.3.36 autoSpaceLikeWord95 (Incorrectly Adjust Text Spacing for Specific Unicode Ranges) This element specifies adjustments (detailed below) which should be applied to the spacing between adjoining regions of non-ideographic and ideographic text when the autoSpaceDE (§2.3.1.2) and autoSpaceDN (§2.3.13) elements have a value of true (or equivalent). This algorithm typically results in the following: An increase in the inter-character spacing added between non-ideographic and/or number characters and certain full-width characters No inter-character spacing between non-ideographic and/or number characters and certain half-width characters Typically, applications apply additional spacing between ideographic and non-ideographic characters/numeric characters when the autoSpaceDE / autoSpaceDN properties are applied. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall apply the following adjustments to this logic: Characters in the following Unicode ranges should be treated as ideographic, even though those characters are full-width forms of non-ideographic text: U+FF10­U+FF19, U+FF21­U+FF3A, and U+FF41­U+FF5A. [Note: This results in the unnecessary addition of space. end note] Characters in the following Unicode ranges should be treated as non-ideographic, even though those characters are ideographic: U+FF66­U+FF9F. [Note: This results in the omission of the intended additional space. end note] [Example: Consider a WordprocessingML document with two paragraphs containing a mix of East Asian and Latin characters: <w:p> <w:r> <w:t>ab</w:t> </w:r> <w:r> <w:t></w:t> </w:r> <w:r> <w:t></w:t> </w:r> <w:r> <w:t>cd</w:t> </w:r> </w:p> <w:p> <w:r> <w:t>ab</w:t> </w:r> <w:r> <w:t></w:t> </w:r> <w:r> <w:t></w:t> </w:r> <w:r> <w:t>cd</w:t> </w:r> </w:p> The first paragraph contains characters with Unicode value U+FF66 (). The second paragraph contains characters with Unicode value U+FF12 (). If autoSpaceDE is true , spacing is added in the first paragraph (between the ideographs and the non-ideographic characters), but not in the second (all four characters are not ideographs): If this compatibility setting is turned on: <w:compat> <w:autoSpaceLikeWord95 /> </w:compat> Then, although it appears incorrect, applications should not add space in the first paragraph and should apply it in the second: end example] Part 4, §2.15.3.26, pages 1,416, lines 9­17, through page 1,417 lines 1­12: 2.15.3.26 footnoteLayoutLikeWW8 (Ignore Page Break from Continuous Section Mark) This element specifies that applications should override the default behaviour for a continuous section break when one or more footnotes are present on the page with the footnote. This override typically results in text being displayed on the same page as a continuous section break (after the break, which would normally move all following text to the next page). Typically, applications render a continuous section break as a page break when one or more footnoteRef elements (§2.11.13) occur on that page before the break, as described in §2.1.8.84. This element, when present with a val attribute value of true (or equivalent), specifies that applications should allow any paragraph after the section break that contains no footnoteRef elements (§2.11.13) to be displayed on the same page. If the resulting content reaches the page extents, the section’s page break is ignored. [Example: Consider a WordprocessingML document with two footnotes contained in two sections, separated by a continuous section break: <w:p> <w:r> <w:t xml:space="preserve">Here is the first paragraph in the first section.</w:t> </w:r> </w:p> <w:p> <w:r> <w:t>Here is the second paragraph in the first section.</w:t> </w:r> <w:r> <w:rPr> <w:rStyle w:val="FootnoteReference" /> </w:rPr> <w:footnoteReference w:id="2" /> </w:r> </w:p> <w:p/> <w:p> <w:pPr> <w:sectPr> … </w:sectPr> </w:pPr> </w:p> <w:p> <w:r> <w:t>Here is the first paragraph in the second section.</w:t> </w:r> </w:p> <w:p> <w:r> <w:t xml:space="preserve">Here is the second paragraph in the second section.</w:t> </w:r> <w:r> <w:rPr> <w:rStyle w:val="FootnoteReference" /> </w:rPr> <w:footnoteReference w:id="3" /> </w:r> </w:p> <w:p> <w:r> <w:t xml:space="preserve">Here is the third paragraph in the second section. </w:t> </w:r> </w:p> <w:sectPr> <w:type w:val="continuous" /> … </w:sectPr> The default rendering of such a document results in the continuous section break as a page break, resulting in the following two page document: However, if this compatibility setting is turned on: <w:compat> <w:footnoteLayoutLikeWW8 /> </w:compat> Then the first paragraph following the section break (not having any footnote references) is displayed on the same page, despite the section break, resulting in the following output: end example] As well, the text in Part 4, §2.18.84, page 1,799, bottom table, will be clarified: Enumeration Value Description continuous (Continuous Section Break) Specifies a continuous section break, which begins the new section on the following paragraph. This means that continuous section breaks might not specify certain page-level section properties, since they must be inherited from the following section. These breaks, however, can specify other section properties, such as line numbering and footnote/endnote settings. If a footnote reference (§2.11.13) occurs on the same page as a section break of this type, the new section shall begin on the following page. Part 4, §2.15.3.31, pages 1,426, lines 5-24 through page 1,427, lines 1-2: 2.15.3.31 lineWrapLikeWord6 (Ignore Compression of Full-Width Punctuation Ending a Line) This element specifies that applications should ignore the character compression settings specified by the characterSpacingControl element (§2.15.1.18) when determining if one more character fits within the text margins on each line of the document. This setting typically results in a character being pushed to the following line, ignoring the fact that the character compression settings would have allowed it to fit within the text boundaries. Typically, an application would check the character compression settings, and apply any character-level whitespace compression before attempting to fit the last character on the line. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall ignore that compression and fit the character as if it should be displayed at its full width, regardless of whether the compression settings are applied. [Example: Consider a paragraph which ends with the following two characters (with each character’s bounding box outlined for illustrative purposes: If the document’s character compression settings were not set to doNotCompress and text extent fell at the location identified by this red line: The last character would have compression applied to its blank half, and would fit on the line. If this compatibility setting is turned on: <w:compat> <w:lineWrapLikeWord6 /> </w:compat> Then applications should compress the character, but should treat the character as full width when determining if it fits on the line; in this case, the second character would be displayed on the following line. end example] Part 4, §2.15.3.32, page 1,427, lines 9­21 through page 1,428, lines 1­11: 2.15.3.32 mwSmallCaps (Use Specific Small Caps Algorithm) This element specifies that applications should use a specific algorithm to determine the font size of small caps (the formatting resulting from the use of the smallCaps element (§2.3.2.31). This emulation typically results in small caps which are smaller than typical small caps at most font sizes. Typically, applications can utilize any algorithm that results in small caps formatting. This element, when present with a val attribute value of true (or equivalent), specifies that applications should determine the font size for small caps using the following algorithm: If 7 , then the font size for small caps is 7 points. Otherwise, sequentially iterate through until +1 , at which point the font size for small caps is points. where is an array defined as follows: 7,9,10,12,14,18,24,36,48,60,72,80, 1 , 2 , … , where = 80 + 10 . is an integer calculated as follows: The font size of the run to which small caps formatting is applied (in points). [Example: Consider a WordprocessingML document with small caps on its text contents. If this compatibility setting is turned on: <w:compat> <w:mwSmallCaps /> </w:compat> And the font size for a single run is 16 points, and performing the algorithm above would result in 14 points as the calculated font size for small caps. end example] Part 4, §2.15.3.41, page 1,422, lines 7­21 through page 1,423, lines 1­7: 2.15.3.41 shapeLayoutLikeWW8 (Ignore Text Wrapping around Objects at Bottom of Page) This element specifies that applications should ignore the line wrapping setting specified by a floating object, instead allowing text to be displayed beneath it under the specific set of conditions identified below. Typically, text wrapping around a floating object is dictated by the presence of one of the following as a child element of the object’s anchor element (§5.5.2.3): wrapNone (§5.5.2.16) element, which specifies no text wrapping wrapSquare (§5.5.2.17) element, which specifies square text wrapping wrapThrough (§5.5.2.18) element, which specifies through text wrapping wrapTight (§5.5.2.19) element, which specifies tight text wrapping wrapTopAndBottom (§5.5.2.20) element, which specifies top and bottom text wrapping This element, when present with a val attribute value of true (or equivalent), specifies that applications shall allow text to wrap beneath a floating object, ignoring the object’s true wrapping setting, when the following conditions are met: The floating object has any of the following elements present as a child of the object’s anchor element (§5.5.2.3): wrapSquare (§5.5.2.17), wrapTight (§5.5.2.19), or wrapTopAndBottom (§5.5.2.20). The floating object has a positionV element (§5.5.2.11) with a relativeFrom attribute value of line. The floating object has a negative value for the child posOffset element (§5.5.2.12) of the positionV element (§5.5.2.11). The paragraph containing the anchor element would appear directly after the previous paragraph if the wrapping settings were ignored. The paragraph containing the anchor element would be pushed to the next page if the wrapping settings were respected. [Example: Consider a WordprocessingML document containing a DrawingML object which meets the conditions outlined above: <w:p> <w:r> <w:t>Sample text. Sample text. Sample text. Sample text. Sample text. Sample text.</w:t> </w:r> <w:r> <w:drawing> <wp:anchor … > <wp:positionV relativeFrom="line"> <wp:posOffset>-428914</wp:posOffset> </wp:positionV> <wp:wrapTopAndBottom /> … </wp:anchor> </w:drawing> </w:r> <w:r> <w:t> Sample text. Sample text. Sample text. Sample text. Sample text. Sample text.</w:t> </w:r> … </w:p> When the wrapping settings are respected, the shape and its paragraph do not fit on the page, so they are moved to the next page (the paragraph containing the anchor has been highlighted for illustrative purposes): If this compatibility setting is turned on: <w:compat> <w:shapeLayoutLikeWW8 /> </w:compat> Then applications should ignore the wrapping setting and allow text to wrap below the object. This behaviour results in the following (again, the paragraph containing the anchor has been highlighted for illustrative purposes): end example] Part 4, §2.15.3.51, pages 1,462, lines 6­20 through page 1,463, lines 1­13: 2.15.3.51 suppressTopSpacingWP (Use Static Text Leading) (The terms internal leading and external leading as used below are defined in ISO/IEC 14496-22:2007.) This element specifies that applications should use the values defined below for the internal leading and external leading of this document. This typically results in lines appearing slightly condensed vertically. Typically, applications calculate both internal leading and external leading using the metrics defined by ISO/IEC 14496-22:2007. This element, when present with a val attribute value of true (or equivalent), specifies that applications should instead use the following values for these metrics: Internal leading = 0 points External leading = 2 points [Example: If this compatibility setting is turned on: <w:compat> <w:suppressTopSpacingWP /> </w:compat> Then applications ignore the actual leading values, and use a total leading of 2 points (0 pt internal, 2 pt external). end example] Part 4, §2.15.3.53, page 1,467, lines 5­26 through page 1,468, lines 1­2: 2.15.3.53 truncateFontHeightsLikeWP6 (Use Truncated Integer Division For Font Calculation) This element specifies that applications should perform a specific method of calculation when converting font heights, specified in points using the sz (§2.3.2.36) and szCs (§2.3.2.37) elements, into pixels. This algorithm often results in a smaller then typical visual appearance of text for a given point size. Typically, applications convert points to pixels using any approximate mathematical conversion mechanism (often, rounded integer division). This element, when present with a val attribute value of true (or equivalent), specifies that applications should use truncated integer division when performing this conversion (any non-integer value is truncated to determine the integer value resulting from the conversions). [Example: If this compatibility setting is turned on: <w:compat> <w:truncateFontHeightsLikeWP6 /> </w:compat> Then applications shall use truncated integer division when calculating the height of characters. For example, if the conversion is done as follows: = 1 72 where: = size in points = size in pixels = resolution in pixels per inch. Converting a 14 point font on a 96 dpi device results in = 14 96 1 72 = 18 23 . If this setting is on, the result is truncated and the font is displayed using 18 pixels, even though 19 would be closer to the actual value. end example] Part 4, §2.15.3.54, page 1,469, line 3: 2.15.3.54 uiCompat97To2003 (Disable Features Not Compatible With Other File Formats) This element is an instruction which specifies that, when working with this document, applications should prevent the use of any feature defined by this specification which is not supported by other word processing file formats also supported by the application. [Example: If an application can generate WordprocessingML and HTML output, this element specifies that any feature which cannot be represented in HTML should be disabled. end example] If this element is omitted, then applications should not prevent the use of any feature in the context of this document. [Example: Consider a WordprocessingML document that specifies that any feature incompatible with earlier word processing formats should be disabled. This requirement would be specified using the following WordprocessingML in the document settings part: <w:uiCompat97To2003 w:val="true"/> The uiCompat97To2003 element’s val attribute has a value of true specifying that any feature incompatible with earlier word processing formats should be disabled. end example] Part 4, §2.15.3.63, page 1,481, lines 5­24: 2.15.3.63 useWord2002TableStyleRules (Incorrectly Display Top Border of Conditional Columns) This element specifies whether applications should incorrectly calculate the top border of conditional columns (as specified by a tblStylePr element (§2.7.5.6) with a type attribute value of firstCol , lastCol , band1Vert , or band2Vert ) under the following conditions: A conditional formatting has also been defined for the first row (a tblStylePr element with a type attribute of firstRow ) That conditional formatting as been applied to the table using the tblLook element (§2.4.51) Typically, table styles are applied according to the logic defined in §2.7.5. This element, when present with a val attribute value of true (or equivalent), specifies that the top border of those conditionally formatted columns should instead be displayed as the top border of the following row. [Example: Consider a WordprocessingML document with table style that defines two conditional formats: The first column has a one point border The first row has red shading That style would be defined as follows: <w:style w:type="table" w:customStyle="1" w:styleId="TableTest"> <w:name w:val="CompatibilitySetting"/> <w:tblStylePr w:type="firstRow"> <w:tcPr> <w:shd w:val="clear" w:color="auto" w:fill="FF0000"/> </w:tcPr> </w:tblStylePr> <w:tblStylePr w:type="firstCol"> <w:tcPr> <w:tcBorders> <w:top w:val="single" w:sz="4" w:space="0" w:color="auto"/> <w:left w:val="single" w:sz="4" w:space="0" w:color="auto"/> <w:bottom w:val="single" w:sz="4" w:space="0" w:color="auto"/> <w:right w:val="single" w:sz="4" w:space="0" w:color="auto"/> </w:tcBorders> </w:tcPr> </w:tblStylePr> </w:style> If the first column and first row formatting is applied, the table would appear as follows: However, if this compatibility setting is turned on: <w:compat> <w:useWord2002TableStyleRules /> </w:compat> Then the condition described by this element causes the top border defined by the conditional format for the first column to be displayed as the top border for the second column, resulting in the following output: end example] Part 4, §2.15.3.64, page 1,482, lines 7­20 through page 1,483, lines 1­5: 2.15.3.64 useWord97LineBreakRules (Emulate Word 97 East Asian Line Breaking) This element specifies that applications should perform specific calculations (detailed below) when determining inter-character spacing under certain conditions. These calculations would not normally be considered correct. Typically, the behaviors specified by the following elements are applied unconditionally: The autoSpaceDE (§2.3.1.2) and autoSpaceDN (§2.3.13) elements The topLinePunct (§2.3.1.43) element The compatibility element described in this subclause, when present with a val attribute value of true (or equivalent), specifies that applications should ignore the settings listed above in the following scenarios: 1. If an ideographic character and a non-ideographic/numeric character are logically adjacent (ignoring all content which is not within a t element), but separated by a field boundary, i.e.: The first character is within a fldSimple element, but the second is not. The characters are separated by a fldChar element with a fldCharType attribute value of end Then any appropriate inter-character spacing should be omitted. [Note: Inter-character spacing should still be calculated correctly within the field result. end note] 2. If a full-width punctuation character appears at the start of a paragraph which also specifies numbering via the numPr element (§2.3.1.19), the compression specified by the topLinePunct element is ignored. [Example: Consider a paragraph which contains a field ending in an ideograph and another paragraph, with numbering, which contains a full-width punctuation character in the first character position: <w:p> <w:r> <w:fldChar w:fldCharType="begin" /> </w:r> … <w:r> <w:t></w:t> </w:r> <w:r> <w:fldChar w:fldCharType="end" /> </w:r> <w:r> <w:t>1</w:t> </w:r> </w:p> <w:p> <w:pPr> <w:numPr> … </w:numPr> </w:pPr> <w:r> <w:t></w:t> </w:r> </w:p> Typically, if both the autoSpaceDN and topLinePunct are true , additional spacing is added after the ideograph in the first paragraph and punctuation kerning is applied in the second paragraph (with gridlines added for visual reference): If this compatibility setting is turned on: <w:compat> <w:useWord97LineBreakRules /> </w:compat> Then applications should not add any inter-character spacing at the end of the field and should turn off punctuation kerning in the second paragraph: end example] Part 4, §2.15.3.65, page 1,483, lines 11­21, through page 1,484 lines 1­17: 2.15.3.65 wpJustification (Fit To Expanded Width When Performing Full Justification) This element specifies that applications should perform a specific algorithm when determining the contents of each line in a fully justified paragraph (resulting from the use of the jc element (§2.3.1.13)). This setting typically results in more words being fitted into lines (by reducing inter-word spacing as necessary). Typically, applying full justification to a paragraph does not change the placement of line breaks, as inter-word spacing is expanded to ensure the resulting text is fully justified. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall determine the contents of each line in a fully justified paragraph using the following algorithm: For each line in the fully justified paragraph, o Determine the actual line width, , in pixels o Calculate the “effective” line width by the following factor: = + 281 7200 o Determine the text which can be displayed in a line of the “effective” line width o Decrease the inter-word spacing as necessary to fit that text in the actual line width [Example: Consider a WordprocessingML document with one or more paragraphs using full paragraph justification: <w:p> <w:pPr> <w:jc w:val="both" /> </w:pPr> … </w:p> If this compatibility setting is turned on: <w:compat> <w:wpJustification /> </w:compat> Then, for a line 1000 pixels wide, an application would calculate the effective width as follows: = 1000 + 1000 281 7200 = 1039 This effective width is then used to determine how much text can be displayed on line. After calculating the text, the application can display the text on the actual line, fully justified. end example] Part 4, §2.15.3.66, page 1,485, lines 5­6: 2.15.3.66 wpSpaceWidth (Use Specific Space Width) (The terms ascent and descent are used as defined in ISO/IEC 14496-22:2007.) This element specifies that applications should perform determine the width of the space character for all proportional fonts used in this document using the calculation specified below. Typically, applications calculate the width of a whitespace character dynamically to optimize for the output device. This element, when present with a val attribute value of true (or equivalent), specifies that applications should instead use the following algorithm to determine the width of a whitespace character: = + 3 where is the width of a space character is the ascent for the font is the descent for the font [Example: Consider a WordprocessingML document with this compatibility setting turned on: <w:compat> <w:suppressTopSpacingWP /> </w:compat> If the font applied to a run specified an ascent value of 8 points and a descent value of 2 points, each space in that run would have a width of three and one-third points. end example] Similar Comments: BR-0001 , BR-0064 , CA-0020 , CA-0079 , CH-0016 , DE-0036 , DK-0041 , DK-0149 , DK-0154 , IE-0010 , IN-0005 , IN-0017 , IN-0076 , KR-0006 , PT-0043 , PT-0044 , SG-0001 , US-0002 , UY-0001 , VE-0008 , VE-0009