DocumentID: ECMA-376/Part4/2.15.3
Title: ECMA-376, Part4: 2.15.3 Compatibility Settings
Extracted-From: ECMA-376 Office Open XML File Formats, 1st Edition / December 2006
Warning: Coverted to HTML format by a script known to have bugs

• Next: 2.15.3 Compatibility Settings
• Up: 2.15 Settings
• Table of contents: Table of contents
• Previous: 2.15.2 Web Page Settings

2.15.3 Compatibility Settings

The last group of settings stored in WordprocessingML is compatibility settings. Compatibility Settings are optional settings used to preserve visual fidelity of documents created in earlier word processing applications. Some of these settings provide affordance for specific behaviors, described in detail below; and others simply instruct applications to mimic the behavior of an existing word processing application.

If compatibility settings are needed, they are stored in the Document Settings part.

It is important to note that all compatibility settings are optional in nature - applications may freely ignore all behaviors described within this section and these settings should not be added unless compatibility is specifically needed in one or more cases. The compatibility settings are provided for backward compatibility with documents created in legacy applications. As such, a number of the settings reference specific applications and specific versions of those applications. This is solely for backward compatibility reasons, and any of those settings are ignorable.

[Example: Consider the following WordprocessingML fragment for the compatibility settings in a WordprocessingML document:

<w:settings>
  ...
  <w:compat>
    <w:noTabHangInd />
  </w:compat>
</w:settings>

The compat element contains all of the document settings for this document. In this case, the single setting applied is the suppression of a tab stop when using a hanging indent using the noTabHangInd element (§2.15.3.37). end example]

2.15.3.1 adjustLineHeightInTable (Add Document Grid Line Pitch To Lines in Table Cells)

This element specifies whether a document grid defined using the docGrid element (§2.6.5) that specifies a line grid (manually adding additional pitch to each line in the section) shall also be applied to lines within table cells in this section.

Typically, when additional line pitch is added to all lines in a section via the document grid, it is not applied to text in tables. This element, when present with a val attribute value of true (or equivalent), specifies that additional line pitch shall be added to lines in table cells.

[Example: Consider a WordprocessingML document with a single section, whose document grid is defined such that 25.9 points of additional line pitch are added to each line in the section, as follows:

<w:docGrid w:type="lines" w:linePitch="518"/>

If text was entered into this section, the default behavior would have line pitch only added to lines which are not in a table cell:

However, if this compatibility setting is turned on:

<w:compat>
  <w:adjustLineHeightInTable />
</w:compat>

Then all lines in this document would have the line pitch from the document grid added to them, resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.2 alignTablesRowByRow (Align Table Rows Independently)

This element specifies whether applications shall align each row within a table independently based on the alignment setting of the jc element (§2.4.22) when displaying the contents of a table in a WordprocessingML document.

When the justification of a table using the jc element is typically applied, that alignment is applied to the contents of the table (the table is centered, left justified, or right-aligned), and then individual rows are laid out based on the resulting table's position. This element, when present with a val attribute value of true (or equivalent), specifies that each table row shall be independently aligned based on the table alignment setting, ignoring the placement of all other rows.

[Example: Consider a WordprocessingML document with a single centered table, whose second row is defined such that one-half of an inch is left before the row begins, as follows:

<w:tbl>
  <w:tblPr>
    <w:jc w:val="center" />
  </w:tblPr>
  <w:tr>
    ...
  </w:tr>
  <w:tr>
    <w:trPr>

      <w:gridBefore w:val="1" /> 

      <w:wBefore w:w="720" w:type="dxa" />  
    </w:trPr>
    ...
  </w:tr>
  <w:tr>
    ...
  </w:tr>
</w:tbl>

The default presentation would have the entire table centered, then the second row indented beyond that by 720 points:

However, if this compatibility setting is turned on:

<w:compat>
  <w:alignTablesRowByRow />
</w:compat>

Then that second row would instead be centered on the page independently of the other table rows, resulting in the following output:

In this case, the wBefore element's value is ignored, since the row was centered on the line as a row, and there is no table to be indented relative to. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.3 allowSpaceOfSameStyleInTable (Allow Contextual Spacing of Paragraphs in Tables)

This element specifies whether the suppression of additional space (contextual spacing) defined using the contextualSpacing element (§2.3.1.9) shall be applied to paragraphs contained within tables.

Typically, the rules for the removal of additional paragraph spacing via the contextualSpacing element are applied to all paragraphs in a WordprocessingML document. This element, when present with a val attribute value of true (or equivalent), specifies that this setting shall always be ignored for paragraphs in table cells (and additional spacing shall be allowed).

[Example: Consider a WordprocessingML document with a default paragraph style with additional spacing after and contextual spacing set, as follows:

<w:style w:name="Normal" w:default="1">
  ...
  <w:pPr>
    <w:spacing w:after="200" />
    <w:contextualSpacing />
  </w:pPr>
</w:style>

The default presentation would have the spacing suppressed between all paragraphs, since they are all of the default paragraph style defined above (contextual spacing applies):

However, if this compatibility setting is turned on:

<w:compat>
  <w:allowSpaceOfSameStyleInTable />
</w:compat>

Then the paragraphs in the table will never have their spacing suppressed, resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.4 applyBreakingRules (Use Legacy Ethiopic and Amharic Line Breaking Rules)

This element specifies whether applications shall use a legacy set of line breaking rules when determining line breaks for text consisting of Ethiopic and/or Amharic characters.

Typically, when line breaking this text, applications should allow line breaks to occur after a character between the UTF-16 (hexadecimal) values 0x1361 and 0x1368 when those characters appear in the document's content. This element, when present with a val attribute value of true (or equivalent), specifies that when a line break would occur after a character between the UTF-16 hexadecimal) values 0x1361 and 0x1368, the line break shall occur before all instances of these characters (i.e. no break opportunity shall be afforded after a character in this range).

[Example: Consider a WordprocessingML document with a series of Ethopic characters in this range. The default presentation would have any line breaks pushed before or after these characters, ensuring that the characters remain together on a single line.

However, if this compatibility setting is turned on:

<w:compat>
  <w:applyBreakingRules />
</w:compat>

Then a line break opportunity shall be afforded at any point in a range of these characters, as needed. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.5 autofitToFirstFixedWidthCell (Allow Table Columns To Exceed Preferred Widths of Constituent Cells)

This element specifies that when performing an AutoFit on a table in a WordprocessingML document in order to display it, applications shall alter that logic slightly in order to mimic the behavior of a previous word processing application.

Normally, the AutoFit behavior of a table is as is described in the associated simple type. This element, when present with a val attribute value of true (or equivalent), specifies that this logic shall be changed as follows:

• If the width of a grid column in a table has been set by a preferred table cell width, then that column's width may be enlarged by the content of cells which themselves do not have a preferred width (in contrast, the normal logic never allows the content of cells to override a preferred width on a grid column).

[Example: Consider a WordprocessingML table with only one preferred cell width, a width of 720 points on the second cell in the first column, as follows:

<w:tbl>
  <w:tr>
    <w:tc>
      <w:p/>
    </w:tc>
    <w:tc>
      <w:p/>
    </w:tc>
  </w:tr>
  <w:tr>
    <w:tc>
      <w:tcPr>
        <w:tcW w:w="720" w:type="dxa" />
      </w:tcPr>
      <w:p/>
    </w:tc>
    <w:tc>
      <w:p/>
    </w:tc>
  </w:tr>
</w:tbl>

The default presentation would have the first column constrained to 720 points by the preferred width of the second cell in the first column:

However, if this compatibility setting is turned on:

<w:compat>
  <w:autofitToFirstFixedWidthCell />
</w:compat>

Then the column would be resized proportionally based on the content (ignoring the preferred width in that row), resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 95) when determining the spacing between full-width East Asian characters in a document's content.

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

Typically, applications shall not perform this compatibility. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall attempt to mimic that existing word processing application in this regard.

[Example: Consider a WordprocessingML document with a series of full-width East Asian characters.

If this compatibility setting is turned on:

<w:compat>
  <w:autoSpaceLikeWord95 />
</w:compat>

Then applications should mimic the behavior of Microsoft Word 95 when determining the space between those characters, as needed. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.7 balanceSingleByteDoubleByteWidth (Balance Single Byte and Double Byte Characters)

This element specifies whether applications shall balance the width of Single Byte Character Set characters and Double Byte Character Set characters when rendering WordprocessingML documents. Specifically, this element specifies to adjust the fixed pitch fonts' half-width space character and full-width space character to attain a 1 to 2 ratio.

[Note: This element is used with East Asian content. Layout and line breaking for East Asian text is dependent on the character width. Half width characters (or Hankaku characters) are one half of an em wide, and full width characters (or Zenkaku characters) are one em wide. Legacy encoding often used a single byte to encode half-width characters and two bytes to encode full width characters. end note]

Typically, no adjustment is done on any character when it is displayed as part of a WordprocessingML document. This element, when present with a val attribute value of true (or equivalent), specifies that character sizes shall be adjusted as needed to meet the 1:2 ratio described above.

[Example: Consider a WordprocessingML document with both SBCS and DBCS characters. The default presentation would have the text displayed as follows:

However, if this compatibility setting is turned on:

<w:compat>
  <w:balanceSingleByteDoubleByteWidth />
</w:compat>

Then this character-level adjustment must be performed, resulting in the following output:

This adjustment is usually very minute in nature, therefore the result is better illustrated by showing how the characters after the English text were pushed out due to the width balancing of that text:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.8 cachedColBalance (Use Cached Paragraph Information for Column Balancing)

This element specifies whether applications shall incorrectly calculate the height of a paragraph for the purposes of column balancing when rendering WordprocessingML documents. Specifically, this element specifies that when a paragraph's lines have differing heights, an application shall treat this paragraph as though it had only one line equaling the full paragraph height, regardless of the actual number of lines in the paragraph.

[Guidance: It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from a legacy application. end guidance]

Typically, lines are correctly measured for their height when balancing columns as part of a WordprocessingML document. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall perform the incorrect calculation in the conditions described above.

[Example: Consider a WordprocessingML document with two columns of text which shall be balanced.

If this compatibility setting is turned on:

<w:compat>
  <w:cachedColBalance />
</w:compat>

Then applications should perform the calculation described above to balance the columns, as needed. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.9 compat (Compatibility Settings)

This element specifies a set of optional compatibility options for the current document.

All settings in this section are optional, but some are very commonly used by different languages, and those which are typically used are as follows:

For Thai, Lao, Khmer, Tibetan, and Armenian:

• The applyBreakingRules setting (§2.15.3.4)

For East Asian languages:

• The adjustLineHeightInTable setting (§2.15.3.1)
• The balanceSingleByteDoubleByteWidth setting (§2.15.3.7)
• The doNotExpandShiftReturn setting (§2.15.3.15)
• The doNotLeaveBackslashAlone setting (§2.15.3.16)
• The spaceForUL setting (§2.15.3.43)
• The ulTrailSpace setting (§2.15.3.55)

[Example: Consider a WordprocessingML document with a series of compatibility settings:

<w:settings>
  <w:compat>
    ...
  </w:compat>
</w:settings>

The compat element specifies the set of compatibility settings for a document. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_Compat">

<sequence>

<element name="useSingleBorderforContiguousCells" type="CT_OnOff" minOccurs="0"/>

<element name="wpJustification" type="CT_OnOff" minOccurs="0"/>

<element name="noTabHangInd" type="CT_OnOff" minOccurs="0"/>

<element name="noLeading" type="CT_OnOff" minOccurs="0"/>

<element name="spaceForUL" type="CT_OnOff" minOccurs="0"/>

<element name="noColumnBalance" type="CT_OnOff" minOccurs="0"/>

<element name="balanceSingleByteDoubleByteWidth" type="CT_OnOff" minOccurs="0"/>

<element name="noExtraLineSpacing" type="CT_OnOff" minOccurs="0"/>

<element name="doNotLeaveBackslashAlone" type="CT_OnOff" minOccurs="0"/>

<element name="ulTrailSpace" type="CT_OnOff" minOccurs="0"/>

<element name="doNotExpandShiftReturn" type="CT_OnOff" minOccurs="0"/>

<element name="spacingInWholePoints" type="CT_OnOff" minOccurs="0"/>

<element name="lineWrapLikeWord6" type="CT_OnOff" minOccurs="0"/>

<element name="printBodyTextBeforeHeader" type="CT_OnOff" minOccurs="0"/>

<element name="printColBlack" type="CT_OnOff" minOccurs="0"/>

<element name="wpSpaceWidth" type="CT_OnOff" minOccurs="0"/>

<element name="showBreaksInFrames" type="CT_OnOff" minOccurs="0"/>

<element name="subFontBySize" type="CT_OnOff" minOccurs="0"/>

<element name="suppressBottomSpacing" type="CT_OnOff" minOccurs="0"/>

<element name="suppressTopSpacing" type="CT_OnOff" minOccurs="0"/>

<element name="suppressSpacingAtTopOfPage" type="CT_OnOff" minOccurs="0"/>

<element name="suppressTopSpacingWP" type="CT_OnOff" minOccurs="0"/>

<element name="suppressSpBfAfterPgBrk" type="CT_OnOff" minOccurs="0"/>

<element name="swapBordersFacingPages" type="CT_OnOff" minOccurs="0"/>

<element name="convMailMergeEsc" type="CT_OnOff" minOccurs="0"/>

<element name="truncateFontHeightsLikeWP6" type="CT_OnOff" minOccurs="0"/>

<element name="mwSmallCaps" type="CT_OnOff" minOccurs="0"/>

<element name="usePrinterMetrics" type="CT_OnOff" minOccurs="0"/>

<element name="doNotSuppressParagraphBorders" type="CT_OnOff" minOccurs="0"/>

<element name="wrapTrailSpaces" type="CT_OnOff" minOccurs="0"/>

<element name="footnoteLayoutLikeWW8" type="CT_OnOff" minOccurs="0"/>

<element name="shapeLayoutLikeWW8" type="CT_OnOff" minOccurs="0"/>

<element name="alignTablesRowByRow" type="CT_OnOff" minOccurs="0"/>

<element name="forgetLastTabAlignment" type="CT_OnOff" minOccurs="0"/>

<element name="adjustLineHeightInTable" type="CT_OnOff" minOccurs="0"/>

<element name="autoSpaceLikeWord95" type="CT_OnOff" minOccurs="0"/>

<element name="noSpaceRaiseLower" type="CT_OnOff" minOccurs="0"/>

<element name="doNotUseHTMLParagraphAutoSpacing" type="CT_OnOff" minOccurs="0"/>

<element name="layoutRawTableWidth" type="CT_OnOff" minOccurs="0"/>

<element name="layoutTableRowsApart" type="CT_OnOff" minOccurs="0"/>

<element name="useWord97LineBreakRules" type="CT_OnOff" minOccurs="0"/>

<element name="doNotBreakWrappedTables" type="CT_OnOff" minOccurs="0"/>

<element name="doNotSnapToGridInCell" type="CT_OnOff" minOccurs="0"/>

<element name="selectFldWithFirstOrLastChar" type="CT_OnOff" minOccurs="0"/>

<element name="applyBreakingRules" type="CT_OnOff" minOccurs="0"/>

<element name="doNotWrapTextWithPunct" type="CT_OnOff" minOccurs="0"/>

<element name="doNotUseEastAsianBreakRules" type="CT_OnOff" minOccurs="0"/>

<element name="useWord2002TableStyleRules" type="CT_OnOff" minOccurs="0"/>

<element name="growAutofit" type="CT_OnOff" minOccurs="0"/>

<element name="useFELayout" type="CT_OnOff" minOccurs="0"/>

<element name="useNormalStyleForList" type="CT_OnOff" minOccurs="0"/>

<element name="doNotUseIndentAsNumberingTabStop" type="CT_OnOff" minOccurs="0"/>

<element name="useAltKinsokuLineBreakRules" type="CT_OnOff" minOccurs="0"/>

<element name="allowSpaceOfSameStyleInTable" type="CT_OnOff" minOccurs="0"/>

<element name="doNotSuppressIndentation" type="CT_OnOff" minOccurs="0"/>

<element name="doNotAutofitConstrainedTables" type="CT_OnOff" minOccurs="0"/>

<element name="autofitToFirstFixedWidthCell" type="CT_OnOff" minOccurs="0"/>

<element name="underlineTabInNumList" type="CT_OnOff" minOccurs="0"/>

<element name="displayHangulFixedWidth" type="CT_OnOff" minOccurs="0"/>

<element name="splitPgBreakAndParaMark" type="CT_OnOff" minOccurs="0"/>

<element name="doNotVertAlignCellWithSp" type="CT_OnOff" minOccurs="0"/>

<element name="doNotBreakConstrainedForcedTable" type="CT_OnOff" minOccurs="0"/>

<element name="doNotVertAlignInTxbx" type="CT_OnOff" minOccurs="0"/>

<element name="useAnsiKerningPairs" type="CT_OnOff" minOccurs="0"/>

<element name="cachedColBalance" type="CT_OnOff" minOccurs="0"/>

</sequence>

</complexType>

2.15.3.10 convMailMergeEsc (Treat Backslash Quotation Delimiter as Two Quotation Marks)

This element specifies whether applications should perform a conversion of the contents of a mail merge data source when reading those contents in order to perform a mail merge operation with their contents.

Typically, the contents of a mail merge data source are read in exactly as specified when performing a mail merge with the contents of a data source. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall interpret delimiters composed of a backslash and quotation mark (\") as two quotation marks (""), within external data sources to be connected to via a mail merge.

[Example: Consider a WordprocessingML document with the following content in its data source:

This is a \"test\".

The default presentation would have the resulting merged data read in just as it appears:

This is a \"test\".

However, if this compatibility setting is turned on:

<w:compat>
  <w:convMailMergeEsc />
</w:compat>

Then instances of a backslash and quotation mark would be converted, resulting in the following output:

This is a ""test"".

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.11 displayHangulFixedWidth (Always Use Fixed Width for Hangul Characters)

This element specifies whether applications should assume that all characters in the Hangul Syllables Unicode sub range (character values between 0xAC00 and 0xD7FF) are of a single fixed width or shall use the characters widths defined by the font in use (typical for a proportional width font).

Typically, applications shall retrieve the character width for any character in a document from the associated font, allowing each character to be of its own width (a proportional width character). This element, when present with a val attribute value of true (or equivalent), specifies that applications shall instead assume a single fixed width for all characters in the Hangul Syllables sub range, by reading the width of Unicode character 0x4E00 from the associated font and using that width for all Hangul characters (or, if that character is not present, the next available character in the font).

[Example: Consider a WordprocessingML document with three Hangul characters:

The default presentation would have each of those characters using the widths defined by the font (the highlighting indicates that each character has its own width):

However, if this compatibility setting is turned on:

<w:compat>
  <w:displayHangulFixedWidth />
</w:compat>

Then all three characters are forced to the fixed width of character 0x4E00 from the font (or, in this case, the next available character), resulting in the characters in the font being forced to that fixed width, which results in the following output:

Notice from the highlighting that the characters have been compressed to the width of the single character and displayed at that fixed width. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.12 doNotAutofitConstrainedTables (Do Not AutoFit Tables To Fit Next To Wrapped Objects)

This element specifies whether applications shall allow tables to be resized to the remaining available line width when they are using the AutoFit algorithm and part of that line is filled by a shape with a wrapping type with a value of square or tight.

Typically, a table which is AutoFit and has a preferred width shall have its width reduced in order to allow a floating shape to wrap around its contents within the document, as that shape simply reduces the width of the line and the AutoFit algorithm applies to the remaining line width. This element, when present with a val attribute value of true (or equivalent), specifies that tables shall never have any preferred width overridden to allow them to wrap around that floating object, and shall instead be pushed to the next full width line in the document to be displayed.

[Example: Consider a WordprocessingML document with a floating shape centered in the document, followed by a table with preferred cell widths of 2.22", as follows:

The default presentation of this document overrides the preferred cell widths to force the table to fit on the line next to the floating shape with tight wrapping.

However, if this compatibility setting is turned on:

<w:compat>
  <w:dontAutofitConstrainedTables />
</w:compat>

Then that table is not resized, so it cannot fit and must be pushed to the next full width line, resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.13 doNotBreakConstrainedForcedTable (Don't Break Table Rows Around Floating Tables)

This element specifies whether applications shall allow a table row to be split in two when its contents are displayed under the following circumstances:

• The table row exceeds one page in height (it must be split into two pages)
• The table row would need to be split in order to accommodate a floating table also on the page (tables which have been set to floating using the tblpPr element (§2.4.54))

Typically, assuming the cantSplit property (§2.4.6) is not set, a table row which cannot fit on one single page shall be split as needed around any floating table on a page, in order to allow its contents to be fully displayed across two or more pages. This element, when present with a val attribute value of true (or equivalent), specifies that table rows which exceed one page in height shall never be split around floating tables in the document, and shall instead be displayed on the first page below the floating table, even if that means that part of the table row is clipped by the edge of the page.

[Example: Consider a WordprocessingML document with a long single table row which must be split across two separate pages in the document, in order to accommodate a floating table anchored in the footer, as follows:

The default presentation of this document forces that row to be split as needed around that floating table.

However, if this compatibility setting is turned on:

<w:compat>
  <w:dontBreakConstrainedForcedTable />
</w:compat>

Then that table row is never split around the floating table, so it is always placed below that floating table on the page, and allowed to flow off the page as needed, resulting in the following output:

This example, while extreme, shows how the row is placed below the floating table, rather than breaking around it. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.14 doNotBreakWrappedTables (Do Not Allow Floating Tables To Break Across Pages)

This element specifies whether applications shall allow tables which have been set to floating using the tblpPr element (§2.4.54) shall be allowed to break across multiple pages when needed.

Typically, a table whose contents cannot all be displayed on one page is broken as needed across multiple pages in order to preserve the location of the table (just as a paragraph of multiple lines is broken across pages as needed). This element, when present with a val attribute value of true (or equivalent), specifies that floating tables shall never be broken across pages, and shall instead be put on the first page by adjusting the starting position of the table as needed to fit on that single page.

[Example: Consider a WordprocessingML document with a floating table positioned at the bottom of a page , as follows:

The default presentation of this document results in that table being broken across two pages of content.

However, if this compatibility setting is turned on:

<w:compat>
  <w:dontBreakWrappedTables />
</w:compat>

Then that table is not broken across the page boundary, so it must be moved further up on the first page to accommodate its entire size, resulting in the following output:

Notice that the table now flows into the page margins in order to keep it on one page. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.15 doNotExpandShiftReturn (Don't Justify Lines Ending in Soft Line Break)

This element specifies whether applications should fully justify the contents of incomplete lines which end in a soft line break when the parent paragraph is fully justified using the jc element (§2.3.1.13).

Typically, applications shall fully justify all lines in a paragraph when that setting is specified using the jc element except for the last line in the paragraph (the line ending with the paragraph mark). This element, when present with a val attribute value of true (or equivalent), specifies that any line which ends in a soft line break shall also not be fully justified when the paragraph specifies that setting.

[Example: Consider a WordprocessingML document with a paragraph whose first single line consists of East Asian characters followed by a soft paragraph mark. The default presentation would have the contents of that line fully justified:

However, if this compatibility setting is turned on:

<w:compat>
  <w:doNotExpandShiftReturn />
</w:compat>

Then this line is not fully justified, as it ends with a soft line break, resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.16 doNotLeaveBackslashAlone (Convert Backslash To Yen Sign When Entered)

This element specifies whether applications should automatically convert the backslash character into the yen character when it is added through user keyboard input.

Typically, no automatic conversion of one character to another is done when characters are entered by the user. This element, when present with a val attribute value of true (or equivalent), specifies that all entries of the backslash (\) character shall automatically be converted to a yen symbol (¥) when the former is entered.

[Example: Consider a WordprocessingML document where the user types the following:

Hello \ world.

The default presentation would have exactly that:

Hello \ world.

However, if this compatibility setting is turned on:

<w:compat>
  <w:doNotLeaveBackslashAlone />
</w:compat>

Then the backslash would be converted, resulting in the following output:

Hello ¥ world.

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.17 doNotSnapToGridInCell (Do Not Snap to Document Grid in Table Cells with Objects)

This element specifies whether a document grid defined using the docGrid element (§2.6.5) shall be applied to the contents of table cells in that section which also contain floating objects defined using the Vector Markup Language syntax. Note that the floating object must be part of the cell, and simply not displayed over the cell due to its anchoring relative to another part of the document.

Typically, if a floating object is present in a table cell, then that setting shall have no impact on whether East Asian text in that cell is snapped to the document grid (as text is always snapped to the grid). This element, when present with a val attribute value of true (or equivalent), specifies that whenever a floating object defined using VML is present in a table cell, that the cell's contents shall not be snapped to the document grid.

[Example: Consider a WordprocessingML document consisting of a single section, whose document grid settings specify that each page shall be exactly 10 characters wide, as follows:

<w:sectPr>
  <w:docGrid w:type="snapToChars" w:charSpace="146636" />
</w:sectPr>

If this document contains a table with a single cell, containing some text and a single shape defined using the Vector Markup Language syntax, the contents of the cell are still snapped to the 10 characters per line character grid, as follows:

However, if this compatibility setting is turned on:

<w:compat>
  <w:doNotSnapToGridInCell />
</w:compat>

Then the presence of a floating object in each cell shall result in the document grid setting being ignored, resulting in the following output:

The additional character pitch was still added to each character on the line, but those characters are no longer snapped to the document grid. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.18 doNotSuppressIndentation (Do Not Ignore Floating Objects When Calculating Paragraph Indentation)

This element specifies whether applications should ignore the presence of floating objects when calculating the starting position of paragraphs which are wrapped around floating objects defined using the Vector Markup Language (VML) syntax.

Typically, the presence of a floating object on the same line or lines as a paragraph shall only affect the text when the floating object occurs where that text would normally be presented. [Example: Text at a 1" indentation would only be displaced by a floating object that appears at that position and not one that appears from 0" to 0.5" on the same line. end example].

This element, when present with a val attribute value of true (or equivalent), specifies that floating objects shall always impact paragraphs on the same line in two ways:

• If the paragraph is not numbered, then it shall tightly wrap any floating object which precedes it on the same line, ignoring its own indentation settings. [Example: A paragraph with a 1" left indent shall tightly wrap a floating object which appears at only 0.25" on the same line. end example]
• If the paragraph is numbered using the numPr element (§2.3.1.19), then it shall calculate and use its full indent relative to the edge of the floating object, not relative to the edge of the page. [Example: A numbered paragraph with a 1" left indent shall appear 1.5" into the page if it is preceded by a floating object which appears at 0.5" on the same line. end example]

[Example: Consider a WordprocessingML document with a narrow floating object at 0.5" on the page, surrounded by both numbered and unnumbered paragraphs.

The default presentation would have no impact on the paragraphs based on that floating object, since two two do not intersect:

However, if this compatibility setting is turned on:

<w:compat>
  <w:doNotSuppressIndentation />
</w:compat>

Then the two alternate rules defined above would apply, resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.19 doNotSuppressParagraphBorders (Do Not Suppress Paragraph Borders Next To Frames)

This element specifies whether applications should suppress paragraph borders defined using the pBdr element (§2.3.1.24) when those borders would be displayed next to the contents of paragraphs which have been defined as frames using the framePr element (§2.3.1.11).

Typically, when a paragraph's borders appear next to a frame, those borders are suppressed to avoid having two borders in close proximity. This element, when present with a val attribute value of true (or equivalent), specifies that those borders shall not be suppressed.

[Example: Consider a WordprocessingML document with a paragraph with a paragraph border that is bounded on its bottom let side by a text frame.

The default presentation would suppress the borders which intersect the frame (in this case, the right border of lines three through eight):

However, if this compatibility setting is turned on:

<w:compat>
  <w:doNotSuppressParagraphBorders />
</w:compat>

Then no border suppression shall take place, resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.20 doNotUseEastAsianBreakRules (Do Not Compress Compressible Characters When Using Document Grid)

This element specifies whether applications should compress characters with identical compression rules when the document grid has been defined using the docGrid element (§2.6.5). Compression rules refer to the additional bearing on the left and/or right side of a typical character, which can be compressed as needed without modifying the actual width of the character (its breadth).

Typically, punctuation characters with an identical set of compression rules are compressed when the contents of a document are displayed. This element, when present with a val attribute value of true (or equivalent), specifies that if a document grid is defined for the current section, compression shall never be performed on any character - all compressible characters shall be individually snapped to the document grid.

[Example: Consider a WordprocessingML document with a document grid set to allow 10 characters per line:

<w:sectPr>
  <w:docGrid w:type="snapToChars" w:charSpace="146636" ... />
</w:sectPr>

The default presentation would allow characters with identical compression rules to compress and utilize a single slot on the document grid (notice that the four parenthesis on the first line are combined since they can be compressed identically, while the two parenthesis with different compression on line two are not):

However, if this compatibility setting is turned on:

<w:compat>
  <w:useEastAsianBreakRules />
</w:compat>

Then no character with compression is compressed and instead are snapped to the grid individually, resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.21 doNotUseHTMLParagraphAutoSpacing (Use Fixed Paragraph Spacing for HTML Auto Setting)

This element specifies whether applications should use a fixed definition when interpreting automatic paragraph spacing defined by a value of true (or equivalent) on the beforeAutospacing and/or afterAutospacing attributes on the spacing element (§2.3.1.33).

Typically, applications shall interpret these settings to match the behavior of most HTML user agents, mimicking the default spacing above and below an HTML p element without additional spacing information. This element, when present with a val attribute value of true (or equivalent), specifies that those two attributes shall result in the following settings for each value:

• beforeAutospacing = 5 points of spacing before
• afterAutospacing = 10 points of spacing after

[Example: Consider a WordprocessingML document with a three paragraphs using HTML autospacing, as follows:

<w:p>
  <w:pPr>
    <w:spacing w:beforeAutospacing="true" w:afterAutospacing="true" />
  </w:pPr>
  <w:r>
    <w:t>Paragraph One</w:t>
  </w:r>
</w:p>
<w:p>
  <w:pPr>
    <w:spacing w:beforeAutospacing="true" w:afterAutospacing="true" />
  </w:pPr>
  <w:r>
    <w:t>Paragraph Two</w:t>
  </w:r>
</w:p>
<w:p>
  <w:pPr>
    <w:spacing w:beforeAutospacing="true" w:afterAutospacing="true" />
  </w:pPr>
  <w:r>
    <w:t>Paragraph Three</w:t>
  </w:r>
</w:p>

The default presentation would result in output designed to match that of all common HTML user agents:

However, if this compatibility setting is turned on:

<w:compat>
  <w:doNotUseHTMLParagraphAutoSpacing />
</w:compat>

Then the paragraphs will have exact spacing of 5 points before and 10 points after, resulting in the following output:

Notice that the paragraphs are more condensed in the second example. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.22 doNotUseIndentAsNumberingTabStop (Ignore Hanging Indent When Creating Tab Stop After Numbering)

This element specifies whether applications shall use the custom tab stop generated by the hanging indent (if any) when advancing the text after the numbering for a numbered paragraph.

Typically, a hanging indent on a paragraph creates a virtual custom tab stop at that location, and therefore a tab added after the numbering on a numbered paragraph by the suff element (§2.9.30) shall advance to that tab stop, so that the text of the numbered paragraph begins at that location. This element, when present with a val attribute value of true (or equivalent), specifies that a tab stop added as the suffix to the numbering of a numbered paragraph shall ignore that virtual custom tab stop and shall instead advance to the next real tab stop (custom or automatic) on the current line.

[Example: Consider a WordprocessingML document with numbering, whose first level of numbering specifies a tab stop suffix, a hanging indent at 1", and a custom tab stop at 2":

<w:abstractNum w:numId="0">
  ...
  <w:lvl w:ilvl="0">
    <w:suff w:val="tab" />
    <w:pPr>
      <w:ind w:left="1440" w:hanging="1440" />
      <w:tabs>
        <w:tab w:val="2880" />
      </w:tabs>
    </w:pPr>
  </w:lvl>
</w:abstractNum>

The default presentation of this document results in the tab stop generated by the numbering advancing to the virtual tab stop generated by the hanging indent at 1", as follows:

However, if this compatibility setting is turned on:

<w:compat>
  <w:dontUseIndentAsNumberingTabStop />
</w:compat>

Then that tab suffix ignores the virtual tab stop of the hanging indent, so it must advance to the next custom tab stop on the line (at 2"), resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.23 doNotVertAlignCellWithSp (Don't Vertically Align Cells Containing Floating Objects)

This element specifies whether applications shall vertically align the contents of a table cell, even when the contents of that table cell include one or more floating objects defined using the Vector Markup Language syntax. Note that the floating object must be part of the cell, and simply not displayed over the cell due to its anchoring relative to another part of the document.

Typically, if the alignment of a table cell in a WordprocessingML document is specified, then the entire contents of that cell are aligned as specified [Example: The entire contents of the cell are centered vertically and moved right-aligned horizontally at that point. end example]. This element, when present with a val attribute value of true (or equivalent), specifies that whenever a floating object defined using VML is present in a table cell, that no vertical alignment shall be applied to the contents of that cell, and the contents of the cell shall instead always be top aligned to the cell's contents.

[Example: Consider a WordprocessingML table with two cells, each containing some text and a single shape defined using the Vector Markup Language syntax. The first cell is vertically aligned to the bottom of the cell, and the second cell is vertically aligned to the center of the cell.

The default presentation of this document results in each cell (including the extents of the floating objects) being vertically aligned as specified, as follows:

However, if this compatibility setting is turned on:

<w:compat>
  <w:dontVertAlignCellWithSp />
</w:compat>

Then the presence of a floating object in each cell shall result in the vertical alignment setting being ignored (each vertical alignment shall be top-aligned relative to the cell), resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.24 doNotVertAlignInTxbx (Ignore Vertical Alignment in Textboxes)

This element specifies whether applications shall allow text within text boxes to be vertically aligned when the v-text-anchor property is set within the parent VML shape.

Typically, if when the v-text-anchor property is set within the parent VML shape, then based on the value of that property, the text is top, center, or bottom aligned appropriately. This element, when present with a val attribute value of true (or equivalent), specifies that the property shall be ignored, and instead the contents of the table shall always be top-aligned.

[Example: Consider a WordprocessingML table with a single center-aligned text box:

<v:shape id="_x0000_s1026" type="#_x0000_t202" style="v-text-anchor:middle">
  <v:textbox>
    <w:txbxContent>
      <w:p>
        <w:r>
          <w:t>This text is centered vertically.</w:t> 
        </w:r>
      </w:p>
    </w:txbxContent>
  </v:textbox>
</v:shape>

The default presentation of this document results in the contents of the text box being center aligned, as follows:

However, if this compatibility setting is turned on:

<w:compat>
  <w:doNotVertAlignInTxbx />
</w:compat>

Then the text shall always be top aligned, regardless of the -text-anchor property, resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.25 doNotWrapTextWithPunct (Do Not Allow Hanging Punctuation With Character Grid)

This element specifies whether applications shall allowing hanging punctuation when:

• The overflowPunct element (§2.3.1.21) is turned on for a paragraph
• A document grid is defined using the docGrid element (§2.6.5) which defines the number of characters per line

Typically, paragraphs which allow hanging punctuation shall allow the number of characters on a line as specified by the document grid to be exceeded by one in order to allow for hanging punctuation. This element, when present with a val attribute value of true (or equivalent), specifies that the document grid shall never be exceeded for hanging punctuation.

[Example: Consider a WordprocessingML document with a document grid set to allow 10 characters per line:

<w:sectPr>
  <w:docGrid w:type="snapToChars" w:charSpace="146636" ... />
</w:sectPr>

If the eleventh character on the line was a punctuation characters, the default presentation would allow that character to behave as hanging punctuation on the first line:

However, if this compatibility setting is turned on:

<w:compat>
  <w:wrapTextWithPunct />
</w:compat>

Then the character grid cannot be exceeded even for the hanging punctuation, resulting in the following output:

The hanging punctuation was disallowed, moving it (and the character before it, since that character cannot begin a line) to the following line. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.26 footnoteLayoutLikeWW8 (Emulate Word 6.x/95/97 Footnote Placement)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 6.x/95/97) when determining the placement of the contents of footnotes relative to the page on which the footnote reference occurs. This emulation typically involves some and/or all of the footnote being inappropriately placed on the page following the footnote reference.

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

Typically, applications shall not perform this compatibility. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall attempt to mimic that existing word processing application in this regard.

[Example: Consider a WordprocessingML document with a series of footnotes.

If this compatibility setting is turned on:

<w:compat>
  <w:footnoteLayoutLikeWW8 />
</w:compat>

Then applications should mimic the behavior of Microsoft Word 6.x/95/97 when determining the placement of those footnotes on the displayed page, as needed. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.27 forgetLastTabAlignment (Ignore Width of Last Tab Stop When Aligning Paragraph If It Is Not Left Aligned)

This element specifies how applications should handle the final tab stop on a line when aligning the contents of a paragraph as specified by the jc element (§2.3.1.13) in the paragraph's properties.

Typically, aligning the contents of a paragraph involves the following:

• Determining the layout of that line before the alignment (including all tab stops)
• Aligning the resulting contents of the line

This is done to ensure that tab stops on a line do not change when the contents of the paragraph are aligned (i.e. the tab stops should not have to take into account the paragraph alignment).

This element, when present with a val attribute value of true (or equivalent), specifies that applications shall ignore the additional line width generated by the last tab stop (and only the last tab stop) when the alignment of the tab stop as defined by the val attribute on the tab element (§2.3.1.37) is not left (or bar, which as defined by this Office Open XML Standard, is not a tab stop per se) when determining the width of the line. The resulting full line shall then be aligned at the position where the line would have been aligned without that tab stop.

[Example: Consider a WordprocessingML document with two center aligned paragraphs of text - the first also containing a centered tab stop positioned at 2":

<w:p>
  <w:pPr>
    <w:tabs>
      <w:tab w:val="center" w:pos="2880" />
    </w:tabs>
    <w:jc w:val="center" />
  </w:pPr>
  <w:r>
    <w:t>Text Before</w:t>
    <w:tab/>
    <w:t>Text After</w:t>
  </w:r>
</w:p>
<w:p>
  <w:pPr>
    <w:jc w:val="center" />
  </w:pPr>
  <w:r>
    <w:t>Text BeforeText After</w:t>
  </w:r>
</w:p>

The default presentation would determine the full width of each line including the tab stops, finally aligning the resulting text to the center position as requested by the jc element:

However, if this compatibility setting is turned on:

<w:compat>
  <w:forgetLastTabAlignment />
</w:compat>

Then the width added to the line by the last tab is ignored when centering the paragraph because that tab is a center aligned tab stop, resulting in the following output:

In the resulting output, the starting location of both lines is at the same place on the page, as the resulting width of both lines is identical when the tab stop is removed from the line width calculation. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.28 growAutofit (Allow Tables to AutoFit Into Page Margins)

This element specifies whether applications shall allow a table which is using the AutoFit table layout algorithm to extend beyond the margins of the page if the minimum width of each table cell would result in an overall table width which is wider than those page margins.

Typically, if a table is using the AutoFit layout algorithm, then based on the definition of that logic, each column in the table shall be increased to the minimum width of its contents (e.g. the longest non-breaking run of text contained within it and/or the width of an inline image contained in one of its cells) until the overall width of the table reaches that of the text extents on the page, at which point text shall be broken and images shall be clipped as needed to maintain the width of the table at the page width (i.e. the page width is an immutable maximum width for the table). This element, when present with a val attribute value of true (or equivalent), specifies that the minimum width of the cells shall not be constrained by the page width, and instead the table shall be allowed to extend into the page margins as needed in order to meet the minimum widths of each of its cells.

[Example: Consider a WordprocessingML table with three cells in each row. If the contents of each cell in that first row each contain a long non-breaking string (such that the minimum widths of each cell's contents exceed the page width), then the rules for table AutoFit specify that each cell must be broken proportionally when the overall width of the table reaches the page width.

The default presentation of this document results in each cell being broken as needed to maintain the table width, as follows:

However, if this compatibility setting is turned on:

<w:compat>
  <w:growAutofit />
</w:compat>

Then the presence of those long non-breaking strings (and the resulting large minimum widths for each table cell) shall result in a table width which is then allowed to override the page margins, resulting in the following output:

The resulting table is clipped by the edge of the page on its right side, but the minimum widths of each cell are maintained as defined by the long non-breaking string contents of each. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.29 layoutRawTableWidth (Ignore Space Before Table When Deciding If Table Should Wrap Floating Object)

This element specifies how tables which have been indented from the margin using the tblInd element (§2.4.48) shall be wrapped around floating objects defined using the Vector Markup Language (VML) syntax.

Typically, when a table is positioned next to a floating object, the table shall only remain next to the object if it can fit in the remaining space on the line when considering the full width needed for the table: the space before the table, plus the width of the table. This element, when present with a val attribute value of true (or equivalent), specifies that the calculation determining whether the table shall fit next to the object shall not include the space before the table, even if that means that the table is actually clipped by the object.

[Example: Consider a WordprocessingML document with a floating VML shape using square wrapping, next to a table which has been indented one inch from the left margin:

<w:tbl>
  <w:tblPr>
    <w:tblInd w:w="1440" w:type="dxa" />
  </w:tblPr>
  ...
</w:tbl>

The resulting presentation would place the table next to the object:

If this object is then moved to the left, such that it would clip the table, the default presentation would have the entire table moved below the shape, since it does not fit in the remaining space on the line:

However, if this compatibility setting is turned on:

<w:compat>
  <w:layoutRawTableWidth />
</w:compat>

Then the determination to move the table is done ignoring the spaced needed before the table, resulting in the following output:

The resulting table is clipped behind the object, as the fit calculation ignores the space needed before the table. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.30 layoutTableRowsApart (Allow Table Rows to Wrap Inline Objects Independently)

This element specifies whether tables which are wrapping around floating objects defined using the Vector Markup Language (VML) syntax shall wrap around the object as a whole, or if each table row shall individually wrap the object as needed (causing a more stuttered, yet tighter, wrapping of the object).

Typically, when a table wraps around a floating object, the table must wrap the object as a unit (i.e. the whole table square wraps the object). This element, when present with a val attribute value of true (or equivalent), specifies that wrapping is applied to each row in the table one by one, even if its means that each row has a different resulting position with respect to the table.

[Example: Consider a WordprocessingML document with a floating VML shape using square wrapping.

The default presentation would have the entire table wrapping around that shape:

However, if this compatibility setting is turned on:

<w:compat>
  <w:layoutTableRowsApart />
</w:compat>

Then each row would wrap around the shape one by one, resulting in the following output:

end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.31 lineWrapLikeWord6 (Emulate Word 6.0 Line Wrapping for East Asian Text)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 6.0) when determining the whitespace compression of the final character on each line in the document. This emulation typically results in characters ending a line that may be compressed on the right being compressed on the right irrespective to whether the compression will allow another character to be included on the given line or not.

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

Typically, applications shall not perform this compatibility. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall attempt to mimic that existing word processing application in this regard.

[Example: Consider a WordprocessingML document with East Asian text.

If this compatibility setting is turned on:

<w:compat>
  <w:lineWrapLikeWord6 />
</w:compat>

Then applications should mimic the behavior of Microsoft Word 6.0 when determining the character compression of those characters at the end of each line on the displayed page, as needed. end example]

The following XML Schema fragment defines the contents of this element:

<complexType name="CT_OnOff">

<attribute name="val" type="ST_OnOff"/>

</complexType>

2.15.3.32 mwSmallCaps (Emulate Word 5.x for the Macintosh Small Caps Formatting)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 5.x for the Macintosh) when determining the resulting formatting when the smallCaps element (§2.3.2.31) is applied to runs of text within this WordprocessingML document. This emulation typically results in small caps which are smaller than typical small caps at most font sizes.

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

Typically, applications shall not perform this compatibility. This element, when present with a val attribute value of true (or equivalent), specifies that applications shall attempt to mimic that existing word processing application in this regard.

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

Then applications should mimic the behavior of Microsoft Word 5.x for the Macintosh when determining the formatting for small caps of characters which specify this formatting, as needed.

As an example of the typical differences, the output of a normal small caps implementation (in black) and one intended to replicate Word 5.x for the Macintosh (in red) are displayed below for several font sizes:

end example]