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]

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.33 noColumnBalance (Do Not Balance Text Columns within a Section)

This element specifies whether the contents of sections with multiple columns defined using the cols element (§2.6.4) should automatically be balanced. In terms of column layout, balancing is the act of attempting to ensure that the number of lines in each column is equivalent (rather than completely filling one column before populating the next).

Typically, column balancing is automatically performed on the contents of sections with multiple columns. This element, when present with a val attribute value of true (or equivalent), specifies that column balancing shall not occur, and each column shall be filled individually until the end of the current page, until all text has been displayed, even if this means one or more columns are unused.

[Example: Consider a WordprocessingML document with an initial section with three columns, defined by the following section properties:

<w:sectPr>
  <w:cols w:num="3" w:space="720" />
</w:sectPr>

The default presentation would have the text in that section balanced between those three columns:

However, if this compatibility setting is turned on:

<w:compat>
  <w:noColumnBalance />
</w:compat>

Then the columns are not balanced, and the contents of the section are used to fill each column to the bottom of the current page in succession, resulting in the following output:

The next section is now forced to begin on the next page, as the columns on page one extend to the bottom of that 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.34 noExtraLineSpacing (Do Not Center Content on Lines With Exact Line Height)

This element specifies whether an exact line height using the spacing element (§2.3.1.33) in the paragraph's properties, each line shall not be automatically centered within the given amount of line spacing.

Typically, if the exact amount of spacing allotted to a line via the paragraph properties exceeds the amount of space required by that line, then the line of text shall be automatically centered when the text of the document is displayed. This element, when present with a val attribute value of true (or equivalent), specifies thatall additional spacing shall instead be placed below the normal layout of the line of text.

[Example: Consider a WordprocessingML document with a line with an exact height of 32 points:

<w:p>
  <w:pPr>
    <w:spacing w:line="640" w:lineRule="exact" />
  </w:pPr>
  <w:r>
    <w:t>This is text on a line that's exactly 32 points high.</w:t>
  </w:r>
</w:p>

The default presentation would have the resulting text centered on that line:

However, if this compatibility setting is turned on:

<w:compat>
  <w:noExtraLineSpacing />
</w:compat>

Then all line spacing is added after the text, 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.35 noLeading (Do Not Add Leading Between Lines of Text)

This element specifies whether the additional leading specified by the current font face shall be added between each line of text when that text is displayed. Leading refers to the additional spacing requested by a particular font in order to ensure that letters on subsequent lines do not display in a fashion where they are positioned too closely together.

Typically, leading should be added as specified by the associated font. This element, when present with a val attribute value of true (or equivalent), specifies that the additional leading specified by the font shall never be output when the text is displayed.

[Example: Consider a WordprocessingML document with three lines of text. The default presentation would have the text displayed as follows:

However, if this compatibility setting is turned on:

<w:compat>
  <w:noLeading />
</w:compat>

Then no leading is added between lines, resulting in the following output:

This adjustment is usually very minute in nature; therefore the result is better illustrated by showing how the characters were pushed out due to the leading added to 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.36 noSpaceRaiseLower (Do Not Increase Line Height for Raised/Lowered Text)

This element specifies whether the height which is allotted to any given line of text when the contents of this document are displayed shall include additional spacing in order to ensure that all raised and/or lowered text can be fully displayed.

Typically, any extra space needed is added to the line to prevent raised and lowered text from being truncated or hidden. This element, when present with a val attribute value of true (or equivalent), specifies that the height of the line shall be determined solely by the spacing settings on the parent paragraph, and any raised/lowered text shall just be clipped if it exceeds that space.

[Example: Consider a WordprocessingML document with both raised and lowered text. The default presentation would have that text visible:

However, if this compatibility setting is turned on:

<w:compat>
  <w:noSpaceRaiseLower />
</w:compat>

Then no additional space should be added to the line height, 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.37 noTabHangInd (Do Not Create Custom Tab Stop for Hanging Indent)

This element specifies whether applications should always create a hanging indent as a custom tab stop when handling tabs within the contents of a WordprocessingML paragraph. The dontUseIndentAsNumberingTabStop element (§2.15.3.22) specifies if this tab stop shall be used in the case of a tab added as the suffix to numbering in a numbered paragraph, while this element handles the same functionality in the generic case (i.e. this element, when set, renders that setting irrelevant as the tab stop is never used).

Typically, the hanging indent on a paragraph shall be treated as a custom tab stop location within that paragraph, allowing the first tab on the first line in the paragraph to advance to the location of the hanging indent. This element, when present with a val attribute value of true (or equivalent), specifies that no custom tab stop shall be created for a hanging indent on a line under any circumstances.

[Example: Consider a WordprocessingML document with two paragraphs (the second numbered, the first not), each with a 2" hanging indent defined as follows (assume the numbering suffix - not shown - is a tab character):

<w:p>
  <w:pPr>
    <w:ind w:left="2880" w:hanging="2880" />
  </w:pPr>
  <w:r>
    <w:t>A 2"</w:t>
    <w:tab/>
    <w:t>hanging indent</w:t>
  </w:r>
</w:p>

<w:p>
  <w:pPr>
    <w:numPr>
      <w:ilvl w:val="0" />
      <w:numId w:val="1" />
    </w:numPr>
    <w:ind w:left="2880" w:hanging="2880" />
  </w:pPr>
  <w:t>Text in a numbered paragraph.</w:t>
</w:p>

The default presentation would have both the numbering and the tab in the regular paragraph advancing to the 2" custom tab stop generated by the hanging indent:

However, if this compatibility setting is turned on:

<w:compat>
  <w:noTabHangInd />
</w:compat>

Then no tab stop exists at 2", and therefore the tab stops must advance to the location of the next automatic tab stop for this document (which is set to occur every 0.5"), 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.38 printBodyTextBeforeHeader (Print Body Text before Header/Footer Contents)

This element specifies the order in which the contents of the main document story and any headers and/or footers shall be sent to the printer.

Typically, the contents of a document are sent to the printer as follows:

• First, the contents of headers/footers are sent to the printer
• Finally, the contents of the main document story are sent to the printer

This element, when present with a val attribute value of true (or equivalent), specifies that this order shall be reversed, and that the body text shall be sent to the printer before any header/footer text. This reversal allows for the processing of PostScript codes in the text layer in the same order as afforded by some legacy word processing applications.

[Example: Consider a WordprocessingML document which is printed. The default resulting print order is the headers and footers for each page, followed by the page contents.

However, if this compatibility setting is turned on:

<w:compat>
  <w:printBodyTextBeforeHeader />
</w:compat>

Then this order shall be reversed, and the page contents shall be printed before the corresponding header and/or footer for each 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.39 printColBlack (Print Colors as Black And White without Dithering)

This element specifies the way in which colored text and/or objects shall be handled when printed to a printer whose printer settings indicate that it can only handle black and white text.

Typically, the contents of a colored document are sent to a black and white printer using grayscale (different shades of gray) to represent each of the possible colors. This element, when present with a val attribute value of true (or equivalent), specifies that colors will not be printed as mapped shades of grey, but rather exclusively in solid black and white. This setting prevents the fuzzy look that may occur when gray or blue content is dithered. Dithering is the process by which colors are simulated using various patterns of black dots on a white background

[Example: Consider a WordprocessingML document which is printed to a black and white printer. The default resulting printed content is typically dithered to appear in the appropriate shade of grayscale text.

However, if this compatibility setting is turned on:

<w:compat>
  <w:printColBlack />
</w:compat>

Then the page contents shall be printed as exclusively black or exclusively white text as needed, and no grayscale output shall occur. 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.40 selectFldWithFirstOrLastChar (Select Field When First or Last Character Is Selected)

This element specifies whether applications should automatically select the entire contents of a field in a WordprocessingML document when the first or last character is selected.

Typically, users can select any character individually within the result of a field in the document. This element, when present with a val attribute value of true (or equivalent), specifies that selecting the first or last character of that field result shall automatically result in the selection of the entire field.

[Example: Consider a WordprocessingML document which contains the following (with a field marked in gray shading):

The default presentation would allow the first character of that field to be selected:

However, if this compatibility setting is turned on:

<w:compat>
  <w:selectFldWithFirstOrLastChar />
</w:compat>

Then that selection would automatically result in the entire field being selected, resulting in the following:

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.41 shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 97) when determining how to wrap text around floating objects using topAndBottom wrapping defined using the Vector Markup Language (VML) syntax. This emulation typically results in the wrapping above and below the object allowing the text to wrap more tightly around the object (text wraps more tightly around the object than it normally would).

[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 floating shape using top and bottom wrapping.

If this compatibility setting is turned on:

<w:compat>
  <w:shapeLayoutLikeWW8 />
</w:compat>

Then applications should mimic the behavior of Microsoft Word 97 when determining the way in which text wraps around that object, 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.42 showBreaksInFrames (Display Page/Column Breaks Present in Frames)

This element specifies whether applications should honor the presence of page and/or column breaks which are present within the contents of paragraphs which have been defined as frames using the framePr element (§2.3.1.11).

Typically, breaks within frames shall be ignored and shall have no effect on the display of the paragraph in which they are contained. This element, when present with a val attribute value of true (or equivalent), specifies that rather than completely ignoring these breaks, applications should display the break and move the remaining frame content, and all subsequent text, to the next page and/or column, as needed.

[Example: Consider a WordprocessingML document with a paragraph contained within a text frame:

The default presentation would display the page break inline in the frame (breaking the frame into two) but would not actually break the page:

However, if this compatibility setting is turned on:

<w:compat>
  <w:showBreaksInFrames />
</w:compat>

Then the page breaks will be used even though they are present in the frame, breaking the page and 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.43 spaceForUL (Add Additional Space Below Baseline For Underlined East Asian Text)

This element specifies whether East Asian content in a WordprocessingML document which has been underlined using the u element shall have additional descent added to the properties of the font in order to ensure that there is adequate spacing between the characters in the font and the underlining applied to the text.

Typically, no adjustments are made to the contents of text runs containing East Asian text which have been underlined. This element, when present with a val attribute value of true (or equivalent), specifies that whenever the following conditions are met:

• The text run contains East Asian characters
• The text run is not using baseline font alignment as defined by the textAlignment property

That the larger of the following two values will be added to the descent property of that font in order to provide additional padding between the text characters and the underline:

• 3 percent of the font size
• 40 twentieths of a point (31 twentieths of a point for Japanese text)

[Example: Consider a WordprocessingML document consisting of a single run of underlined Japanese text, as follows:

<w:p>
  <w:r>
    <w:rPr>
      <w:u w:type="double" />
    </w:rPr>
    <w:t>クリスタ</w:t>
  </w:r>
</w:p>

If this document is displayed, then the text is laid out along with the underline, as follows:

However, if this compatibility setting is turned on:

<w:compat>
  <w:spaceForUL />
</w:compat>

Then the additional descent specified using the logic above is added to the text, 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.44 spacingInWholePoints (Only Expand/Condense Text By Whole Points)

This element specifies how applications should apply text expansion/compression defined using the spacing element (§2.3.2.33) within a set of run properties.

Typically, as defined in the spacing element, text within runs in a WordprocessingML document may be expanded or compressed in increments of twentieths of a point. This element, when present with a val attribute value of true (or equivalent), specifies that the expansion and compression of text shall only be performed in increments of points. Any value which is not equal to an expansion or compression of a whole point shall be rounded down to the nearest whole point when the text is expanded/compressed within the WordprocessingML document.

[Example: Consider a WordprocessingML document with three paragraphs of text, each expanded by a varying amount, as follows:

<w:p>
  ...
  <w:r>
    <w:t>This is text.</w:t>
  </w:r>
</w:p>

<w:p>
  ...
  <w:r>
    <w:rPr>
      <w:spacing w:val="20" />
    </w:rPr>
    <w:t>This is text.</w:t>
  </w:r>
</w:p>

<w:p>
  ...
  <w:r>
    <w:rPr>
      <w:spacing w:val="36" />
    </w:rPr>
    <w:t>This is text.</w:t>
  </w:r>
</w:p>

The default presentation would have each run of text expanded exactly as requested:

However, if this compatibility setting is turned on:

<w:compat>
  <w:spacingInWholePoints />
</w:compat>

Then the third line - with an expansion of 1.8 points - would instead be rounded down to the nearest whole number of points when expanded, resulting in the following output:

In the resulting output, the second and third lines are identical, as the third line has a next expansion of exactly one point. 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.45 splitPgBreakAndParaMark (Always Move Paragraph Mark to Page after a Page Break)

This element specifies whether a page break shall automatically complete the line on which it appears, moving the end of the paragraph to a new line on the next page, or if it shall behave as true run-level content within its current paragraph.

Typically, a page break defined using the br element (§2.3.3.1) is treated as run-level content, which means that although it delimits the end of the page, if there is no content after it within the current paragraph, that the paragraph shall also end on that page. This element, when present with a val attribute value of true (or equivalent), specifies that a page break shall always immediately end the current page, moving the paragraph mark which delimits the end of its parent paragraph to a new line on the next page.

Note that this setting only affects the case where there is no run-level content after the page break within the paragraph - if any further run content appears in the paragraph it shall appear on subsequent lines on the next page.

[Example: Consider a WordprocessingML document with two paragraphs of content - the first ending with a page break:

<w:p>
  <w:r>
    <w:t>This is text before a page break.</w:t>
    <w:br w:type="page" />
  </w:r>
</w:p>
<w:p>
  <w:r>
    <w:t>This is text on the next page.</w:t>
  </w:r>
</w:p>

The default presentation would have the text content This is text on the next page. as the first line of the second page, as there is no run content after the page break in paragraph one, and therefore no need for a new line on page two (in this image, a graphical illustration of the pilcrow and the page break have been added for clarity):

However, if this compatibility setting is turned on:

<w:compat>
  <w:splitPgBreakAndParaMark />
</w:compat>

Then even though it is followed by no additional content, the page break shall immediately end the first page, pushing the end of the first paragraph onto the first line of the second page, 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.46 subFontBySize (Increase Priority Of Font Size During Font Substitution)

This element specifies whether applications shall increase the priority of font size when performing font substitution in a WordprocessingML document. Font substitution is the process by which an application determines which font to use in place of a font that is referenced by a document, but is not available to the application trying to display the document.

Typically, applications may perform font substitution using any mechanism available. This element, when present with a val attribute value of true (or equivalent), specifies that finding a font with a similar font size shall have increased precedence when doing font substitution for this document.

[Example: Consider a WordprocessingML document with a series of characters in an unavailable font. The default presentation would use any method used by the application to perform that font substitution.

However, if this compatibility setting is turned on:

<w:compat>
  <w:subFontBySize />
</w:compat>

Then font size shall take precedence when performing font substitution for this document, 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.47 suppressBottomSpacing (Ignore Exact Line Height for Last Line on Page)

This element specifies whether an exact line height specified using the spacing element (§2.3.1.33) with a lineRule attribute value of exact shall be ignored for the last line on each page.

Typically, if an exact line height has been specified using the spacing element, then all lines within that paragraph have the necessary line spacing added to them in order to meet this constraint. This element, when present with a val attribute value of true (or equivalent), specifies that no additional spacing shall be added below the last line on each page as a result of these line spacing requirements - a line shall be placed on the bottom of the page if its characters fit on that page ignoring the necessary space after.

[Example: Consider a WordprocessingML document whose first paragraph has a line spacing setting requiring exactly 48 points of space per line:

<w:p>
  <w:pPr>
    <w:spacing w:line="960 w:lineRule="exact" />
  </w:pPr>
  ...
</w:p>

The default presentation would have the necessary amount of space added between each line such that all lines in the paragraph are centered within 48 points of spacing:

However, if this compatibility setting is turned on:

<w:compat>
  <w:suppressBottomSpacing />
</w:compat>

Then that constraint shall be lifted for the last line on the page (although all other lines are unaffected), resulting in the following output:

The first line from the following page was moved on the first page, as without being subjected to the line height constraint, it is possible to fit it at the bottom of the first 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.48 suppressSpacingAtTopOfPage (Ignore Minimum Line Height for First Line on Page)

This element specifies whether the minimum line height specified using the spacing element (§2.3.1.33) with a lineRule attribute value of atLeast shall be ignored for the first line on each page.

Typically, if a minimum line height has been specified using the spacing element, then all lines within that paragraph have the necessary line spacing added to them in order to meet this constraint. This element, when present with a val attribute value of true (or equivalent), specifies that no additional spacing shall be added above the first line on each page as a result of this line spacing requirements - the top of the text characters on the first line shall be at the top edge of the page.

[Example: Consider a WordprocessingML document whose first paragraph has a line spacing setting requiring at least 25 points of space per line:

<w:p>
  <w:pPr>
    <w:spacing w:line="500" w:lineRule="atLeast" />
  </w:pPr>
  ...
</w:p>

The default presentation would have the necessary amount of space added between each line such that all lines in the paragraph are centered within 25 points of spacing (highlighting has been added to the image below in order to illustrate the additional spacing above the first line):

However, if this compatibility setting is turned on:

<w:compat>
  <w:suppressSpacingAtTopOfPage />
</w:compat>

Then no additional line spacing shall be added above the first line on the page (although all other lines are unaffected), resulting in the following output:

However, if this line spacing constraint was exactly 25 points, then this setting would have no effect:

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.49 suppressSpBfAfterPgBrk (Do Not Use Space Before On First Line After a Page Break)

This element specifies that applications should not postpone any before paragraph spacing to the first line containing content after a page break.

Typically, a page break defined using the br element (§2.3.3.1) is treated as run-level content, which means that although it delimits the end of the page, if there is no content after it within the current paragraph, that the paragraph shall also end on that page. However, in the case where there is additional run-level content within the same paragraph, that content, although part of the same paragraph as the page break, is displayed on the following page.

This leads to a situation where the only run content on the page with the page break is the break itself, with all subsequent content on the following page. In this case, applications shall apply the value specified by the spacing element's before attribute to the first line on the new page (since it is ostensibly the only page with content in that paragraph).

This element, when present with a val attribute value of true (or equivalent), specifies the paragraph before spacing shall not be 'postponed' in this way - if the line with the page break has no content, then the spacing element's before attribute is simply ignored.

[Example: Consider a WordprocessingML document whose first paragraph specifies that it shall be preceded by 50 points of additional spacing:

<w:p>
  <w:pPr>
    <w:spacing w:before="1000" />
  </w:pPr>
  <w:r>
    <w:br w:type="page" />
    <w:t>This is sample text with 50 points before formatting.</w:t>
  </w:r>
</w:p>

The default presentation would have the necessary amount of space added to the first line on the second page, as the page break was not preceded by any run content (highlighting has been added to the image below in order to illustrate the additional spacing above the first line):

However, if this compatibility setting is turned on:

<w:compat>
  <w:suppressSpBfAfterPgBrk />
</w:compat>

Then the spacing shall not be added above the first line on the page (it is essentially ignored), 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.50 suppressTopSpacing (Ignore Minimum and Exact Line Height for First Line on Page)

This element specifies whether the minimum line height specified using the spacing element (§2.3.1.33) with a lineRule attribute value of atLeast or exact shall be ignored for the first line on each page.

Typically, if a minimum or exact line height has been specified using the spacing element, then all lines within that paragraph have the necessary line spacing added to them in order to meet this constraint. This element, when present with a val attribute value of true (or equivalent), specifies that no additional spacing shall be added above the first line on each page as a result of these line spacing requirements - the top of the text characters on the first line shall be at the top edge of the page.

[Example: Consider a WordprocessingML document whose first paragraph has a line spacing setting requiring exactly 25 points of space per line:

<w:p>
  <w:pPr>
    <w:spacing w:line="500" w:lineRule="exact" />
  </w:pPr>
  ...
</w:p>

The default presentation would have the necessary amount of space added between each line such that all lines in the paragraph are centered within 25 points of spacing (highlighting has been added to the image below in order to illustrate the additional spacing above the first line):

However, if this compatibility setting is turned on:

<w:compat>
  <w:suppressTopSpacing />
</w:compat>

Then no additional line spacing shall be added above the first line on the page (although all other lines are unaffected), 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.51 suppressTopSpacingWP (Emulate WordPerfect 5.x Line Spacing)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (WordPerfect 5.x) when determining the resulting spacing between lines in a paragraph using the spacing element (§2.3.1.33). This emulation typically results in line spacing which is reduced from its normal size.

[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 triple line spacing defined using the spacing element:

<w:pPr>
  <w:spacing w:line="720" w:lineRule="auto" />
</w:pPr>

If this compatibility setting is turned on:

<w:compat>
  <w:suppressTopSpacingWP />
</w:compat>

Then applications should mimic the behavior of WordPerfect 5.x when determining the resulting spacing between each line with additional line spacing, as needed.

As an example of the difference, the output of a normal pairing of triple spaced paragraphs (in black) and one intended to replicate WordPerfect 5.x (in red) is displayed below:

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.52 swapBordersFacingPages (Swap Paragraph Borders on Odd Numbered Pages)

This element specifies whether left and right paragraph borders defined under the pBdr element (§2.3.1.24) shall be swapped under conditions where it is possible that the those pages are intended to be used to create a book-like publication.

Typically, no changes shall be made to the positions of paragraph borders defined under the pBdr element - a right border is always on the right, and a left border is always on the left. This element, when present with a val attribute value of true (or equivalent), specifies that under the two following conditions:

• The margins in this document are mirrored using the mirrorMargins element (§2.15.1.57)
• The header/footers in this document are different on even and odd numbered pages using the evenAndOddHeaders element (§2.10.1)

That paragraph borders on odd-numbered pages will be swapped - that is, left borders shall be displayed on the right and right borders shall be displayed on the left.

[Example: Consider a WordprocessingML document for which the mirrorMargins element is present, and whose default paragraph style includes a paragraph border to be displayed on the right side of each paragraph:

<w:style w:type="paragraph" w:default="1" w:styleId="Normal" >
  ...
  <w:pPr>
    <w:pBdr>
      <w:right w:val="single" w:color="auto" />
    </w:pBdr>
    ...
  </w:pPr>
</w:style>

If a two-page document is created using this default paragraph style, then all paragraphs will have a border on the right side, as follows:

However, if this compatibility setting is turned on:

<w:compat>
  <w:swapBordersFacingPages />
</w:compat>

Then the borders on the first page (being an odd-numbered page) shall be swapped, 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.53 truncateFontHeightsLikeWP6 (Emulate WordPerfect 6.x Font Height Calculation)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (WordPerfect 6.x) when determining the character height for characters in a font. This emulation typically results slightly truncated character heights.

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

If this compatibility setting is turned on:

<w:compat>
  <w:truncateFontHeightsLikeWP6 />
</w:compat>

Then applications should mimic the behavior of WordPerfect 6.x when determining the height of characters, as needed.

As an example of the difference, the output of a normal pairing of triple spaced paragraphs (in black) and one intended to replicate WordPerfect 6.x (in red) is displayed below:

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.54 uiCompat97To2003 (Disable Features Incompatible With Earlier Word Processing Formats)

Disable UI functionality that is not compatible with Word97-2003

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.55 ulTrailSpace (Underline All Trailing Spaces)

This element specifies whether applications shall display underlining beneath all trailing spaces in the contents of a line when those contents are underlined. Trailing spaces are all space characters which are not followed by non-space characters on the same line.

Typically, applications do not display underlining on all trailing spaces which have the underline property applied to them. This element, when present with a val attribute value of true (or equivalent), specifies that all characters with underline applied, including trailing spaces, shall display underlining if it is applied to that content.

[Example: Consider a WordprocessingML document with the following line of Latin alphabetical character and punctuation, trailed by a series of spaces:

<w:r>
  <w:rPr>
    <w:u w:val="single"/>
  </w:rPr>
  <w:t>Example text. Example text. Example text. Example text. Example text.                           </w:t>
</w:r>

The default presentation would have no underlining on those trailing spaces:

However, if this compatibility setting is turned on:

<w:compat>
  <w:ulTrailSpace />
</w:compat>

Then all trailing spaces would be underlined, 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.56 underlineTabInNumList (Underline Following Character Following Numbering)

This element specifies whether applications shall underline the character following the numbering defined using the suff element (§2.9.30) when both the numbering itself and the first letter of the corresponding numbered paragraph is underlined.

Typically, the tab or space character generated between numbering and the corresponding paragraph of text is never formatted, since it is automatically generated by the suff element. This element, when present with a val attribute value of true (or equivalent), specifies that the tab or space shall tab or space shall be underlined the same way as the numbering symbol itself in the following conditions:

• The numbering is underlined
• The first character of the paragraph is underlined

[Example: Consider a WordprocessingML document with two numbered paragraphs: one with underlined text and the other without. The default presentation would have the tab characters free of underlining in both cases:

However, if this compatibility setting is turned on:

<w:compat>
  <w:underlineTabInNumList />
</w:compat>

Then the second paragraph meets the criteria defined above for having the suffix character underlined, 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.57 useAltKinsokuLineBreakRules (Use Alternate Set of East Asian Line Breaking Rules)

This element specifies an alternate set of characters which may be used to determine which characters can begin and/or end a line when kinsoku line breaking rules are enabled using the kinsoku element (§2.3.1.16).

Typically, the characters used to determine which characters shall not end a line are those listed by the kinsoku element in the paragraph properties subclause of this document. This element, when present with a val attribute value of true (or equivalent), specifies that the following settings shall be used instead (for brevity, only those settings which are different are listed below):

Chinese (Simplified)

• Cannot start a line:
  !),.:;?]}¨·ˇˉ―‖'"...∶、。〃々〉》」』】〕〗！＂＇），．：；？］｀｜｝～￠
• Cannot end a line:
  ([{·'"〈《「『【〔〖（．［｛￡￥

Chinese (Traditional)

• Cannot start a line:
  !),.:;?]}¢·----'"•‥...‧′╴、。〉》」』】〕〞︰︱︳︴︶︸︺︼︾﹀﹂﹄﹏﹐﹑﹒﹔﹕﹖﹗﹚﹜﹞！），．：；？｜｝､

Korean

• Cannot end a line:
  ([\{£¥'"〈《「『【〔＄（［｛￦

[Example: Consider a line of text in a WordprocessingML document within a paragraph marked as Chinese (Simplified) which begins with a % symbol, as follows:

%...

Typically, the kinsoku settings for Chinese (Simplified) do not allow this character to begin a line, so the character before that symbol would be moved down onto this line:

〖%...

However, if this compatibility setting is turned on:

<w:compat>
  <w:useAltKinsokuLineBreakRules />
</w:compat>

Then the alternate kinsoku rules are in place, which do not prevent the % character from beginning the new 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.58 useAnsiKerningPairs (Use ANSI Kerning Pairs from Fonts)

This element specifies whether applications shall use the ANSI or Unicode kerning pair information from fonts stored in the document when displaying those characters within the document's contents.

Typically, applications shall use the Unicode kerning pair information in order to determine all possible kerning pairs in the fonts in use. This element, when present with a val attribute value of true (or equivalent), specifies that the ANSI kerning information shall be used instead.

[Example: Consider a WordprocessingML document with text that contains one or more kerning pairs.

If this compatibility setting is turned on:

<w:compat>
  <w:useAnsiKerningPairs />
</w:compat>

Then the ANSI kerning pairs are used in place of the Unicode kerning pairs, potentially resulting in different line breaks.

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.59 useFELayout (Do Not Bypass East Asian/Complex Script Layout Code)

This element specifies that applications shall not bypass code relating to the layout of East Asian and/or Complex Script characters when presenting this document.

[Guidance: Previous word processing applications relied on this flag to determine whether to perform functions which allow for the correct layout of East Asian and Complex Script text. Although current applications no longer rely on this flag (as they should correctly use the Unicode subranges and code pages of the text in use), this flag should be output in order to ensure that files with this content can be viewed correctly in previous word processors. end guidance]

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

If this compatibility setting is turned on:

<w:compat>
  <w:useFELayout />
</w:compat>

Then the flag is set telling previous applications that East Asian content is present, and they should display the document accordingly. 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.60 useNormalStyleForList (Do Not Automatically Apply List Paragraph Style To Bulleted/Numbered Text)

This element specifies whether applications shall automatically apply the paragraph style with the styleId attribute ListParagraph when numbering is applied to a paragraph currently formatted using the default paragraph style.

Typically, when a paragraph is formatted using the default paragraph style, and numbering is subsequently applied, the paragraph style with the styleId attribute ListParagraph when numbering is applied to ensure that paragraph properties are appropriate for a numbered paragraph. This element, when present with a val attribute value of true (or equivalent), specifies that no alternate paragraph style shall ever be applied

[Example: Consider a WordprocessingML document with five unnumbered paragraphs:

If numbering is applied to the three center paragraphs, the default presentation would have the ListParagraph style applied as well:

However, if this compatibility setting is turned on:

<w:compat>
  <w:useNormalStyleForList />
</w:compat>

Then the new paragraph style shall not be applied, 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.61 usePrinterMetrics (Use Printer Metrics To Display Documents)

This element specifies whether applications shall use the printer metrics of the currently active printer when determining how to display the contents of a WordprocessingML document. Printer metrics are printer-specific settings which can be queried to tell an application how and where text shall be displayed on a printed page.

Typically, applications display the content of a document in a device independent manner - the application is therefore not changing the layout of a document based on the currently attached printer, and instead shall dictate to the printer where characters shall be presented on the page when printed. This element, when present with a val attribute value of true (or equivalent), specifies that the metrics of the current printer shall be used to display the document instead.

Specifically, when this setting is enabled, the printer metrics are used to determine the number of pixels per logical inch along the screen width and height. This should then be used to compute the pixel height of the fonts requested when displaying the document, as well as to scale between any logical units within the document (e.g. drawing object sizes) to the appropriate device units. Those units would then need to be scaled back into screen units for final display to a screen, but not scaled again when displayed to a printer.

[Note: On the Windows platform, you can use the GetDeviceCaps function to retrieve device-specific information for the specified printer. For this specific setting, you can use GetDeviceCaps(hdc, LOGPIXELSX) and GetDeviceCaps(hdc, LOGPIXELSY) with a printer DC to retrieve the number of pixels per logical inch along the screen width and height. With this, you can then use those DPI metrics to compute a pixel value for the font request in the LOGFONT structure (the LOGFONT structure defines the attributes of a font). A common formula to do this is. end note]

[Example: Consider a WordprocessingML document. The default shall use device-independent layout to present the contents of the page.

However, if this compatibility setting is turned on:

<w:compat>
  <w:usePrinterMetrics />
</w:compat>

Then the printer metrics of the current active printer shall be used to determine the display of the contents of the document instead, 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.62 useSingleBorderforContiguousCells (Use Simplified Rules For Table Border Conflicts)

This element specifies whether applications should use an alternate simplified algorithm when handling conflicts between adjacent table borders within a table.

Typically, the conflicts between two adjacent table borders are handled using the conflict resolution algorithm defined in §2.4.38 of this Office Open XML Standard. This element, when present with a val attribute value of true (or equivalent), specifies that rather than using that algorithm to determine the outcome of the conflict to two adjacent borders, that the following logic shall be used instead:

• Cell borders shall supersede table borders
• Cell borders to the right shall supersede cell borders to the left (i.e. the rightmost border wins in conflicts between vertical borders)
• Cell borders below shall supersede cell borders above (i.e. the bottommost border wins in conflicts between horizontal borders)

[Example: Consider a WordprocessingML document with cell and table borders defined as follows. In the image below, 0.1" of padding has been added between each cell temporarily to clearly illustrate the borders on each cell and on the table:

The default presentation would have the border conflicts resolved using the algorithm defined by this Office Open XML Standard, resulting in the following table:

However, if this compatibility setting is turned on:

<w:compat>
  <w:useSingleBorderForContiguousCells />
</w:compat>

Then the simplified table algorithm above shall be used instead (bottom and right cell borders always win), 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.63 useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 2002) when determining the formatting resulting from table styles applied to tables within a WordprocessingML document.

[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 tables with table styles applied.

If this compatibility setting is turned on:

<w:compat>
  <w:useWord2002TableStyleRules />
</w:compat>

Then applications should mimic the behavior of Microsoft Word 2002 when determining the formatting resulting from the use of table styles. 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.64 useWord97LineBreakRules (Emulate Word 97 East Asian Line Breaking)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 97) when determining the line breaking rules for East Asian text within a WordprocessingML document.

[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 run content.

If this compatibility setting is turned on:

<w:compat>
  <w:useWord97LineBreakingRules />
</w:compat>

Then applications should mimic the behavior of Microsoft Word 97 when determining the line breaking from the use of the East Asian characters. 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.65 wpJustification (Emulate WordPerfect 6.x Paragraph Justification)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (WordPerfect 6.x) when performing full paragraph justification using a val attribute value of both on the jc element (§2.3.1.13). This alternate justification method involves biasing towards compressing rather than expanding spaces when needed to justify a line.

[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 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 applications should mimic the behavior of WordPerfect 6.x when performing full justification on text in these paragraphs. 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.66 wpSpaceWidth (Space width)

Set the width of a space like WordPerfect 5.x.

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.67 wrapTrailSpaces (Line Wrap Trailing Spaces)

This element specifies whether applications shall perform line wrapping on trailing spaces in the contents of a line when displaying in it a paragraph. Trailing spaces are all space characters which are not followed by non-space characters on the same line.

Typically, applications do not line wrap trailing spaces, instead allowing an unbounded number of trailing spaces on a line, with the next non-space character starting at the first character position on the next line. This element, when present with a val attribute value of true (or equivalent), specifies that all characters, including trailing spaces, shall be line wrapped normally.

[Example: Consider a WordprocessingML document with the following paragraph of text, including a long interstitial of spaces which become trailing spaces when the paragraph is displayed:

<w:r>
  <w:t> This is some text followed by a long number of trailing spaces.
                                                                       
                                                                       
               And some more text.</w:t>
</w:r>

The default presentation would not wrap those trailing spaces, so the text at the end of the run would begin at the first character position on the second line:

However, if this compatibility setting is turned on:

<w:compat>
  <w:wrapTrailSpaces />
</w:compat>

Then all trailing spaces would be handled as regular characters when line wrapping, 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>