XFC automatically tries to infer the numbering style from the label of the first list item. Both bulleted and numbered lists are supported. Nested lists are supported.

When the heuristics used by XFC are insufficient to infer the type of a list, it's still possible to explicitly specify this type by adding an xfc:label-format extension attribute to the fo:list-block.

When the heuristics used by XFC are insufficient to infer the type of a list and the xfc:label-format attribute is absent from the fo:list-block, then the list items are output as plain paragraphs. That is, the list items look as expected, but will not behave as proper list items when edited in MS-Word or OpenOffice.org.

label-format -> [ bullet | number ]?

bullet -> String

number -> [String]? '%{' format '}' [String]

format -> 'decimal'|'lower-alpha'|'upper-alpha'|
          'lower-roman'|'upper-roman' [inherit]? [start]?

inherit -> ';inherit'

start -> ';start=' Positive_Integer

<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
         xmlns:xfc="http://www.xmlmind.com/foconverter/xsl/extensions">
  ...  
  <fo:list-block font-family="monospace" margin-left="10pt"
                 provisional-distance-between-starts="1cm"
                 provisional-label-separation="5pt"
                 space-before="2pt"
                 xfc:label-format="&#x2022;%{lower-roman;start=10}">
    <fo:list-item>
      <fo:list-item-label end-indent="label-end()">
        <fo:block>&#x2022;x</fo:block>
      </fo:list-item-label>

      <fo:list-item-body start-indent="body-start()">
        <fo:block>This is the first item 
        of the list.</fo:block>
      </fo:list-item-body>
    </fo:list-item>

    <fo:list-item>
      <fo:list-item-label end-indent="label-end()">
        <fo:block>&#x2022;xi</fo:block>
      </fo:list-item-label>

      <fo:list-item-body start-indent="body-start()">
        <fo:block>This is the second item 
        of the list.</fo:block>
      </fo:list-item-body>
    </fo:list-item>
  </fo:list-block>
  ...

For lack of a corresponding element in the output formats, leader objects are implemented by means of tab stops. This is not very convenient given the leader object specification, since there is no way for XFC to derive the tab position from the property values. Though XFC will usually set the tab position to a reasonable value by default, this arbitrary position is unlikely to result in the intended layout.

However, the actual tab position may be specified to XFC by setting an additional property on the leader object. This property is named tab-position and must be defined in the XFC namespace (http://www.xmlmind.com/foconverter/xsl/extensions). The property value is a <length> as defined in section 5.11 of the Recommendation. A positive value specifies the tab position relative to the left margin, whereas a negative value specifies the position relative to the right margin.

An additional property named tab-align specifies how the content following a tab is horizontally aligned. The possible values for this property are: left, center, right and decimal. Using the tab-align property is optional. By default, the content following a tab is left aligned.

The code samples below are excerpts from file xslutil_install_dir/addon/config/docbook/xsl/fo/autotoc.xsl. They illustrate a typical use of the tab-position and tab-align properties in an XSL stylesheet.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:fo="http://www.w3.org/1999/XSL/Format"
                xmlns:xfc="http://www.xmlmind.com/foconverter/xsl/extensions"
                version='1.0'>

<fo:leader leader-pattern="dots"
           leader-pattern-width="3pt"
           leader-alignment="reference-area"
           xfc:tab-position="-30pt"
           xfc:tab-align="right"
           keep-with-next.within-line="always"/>

Without this information, the word processor thinks that the document is entirely written in its default language; which may be very annoying when this is not the case (false errors reported by the spell checker).

	For attribute language and, optionally, attribute country (or equivalently, xml:lang) to be considered to generate information for use by the word processor, attribute language (or equivalently, xml:lang) must be specified at least on the fo:root element.

Other limitations:

	For East Asian language (e.g. zh, ja, ko) detection by MS-Word to work on a Windows computer having a Western locale, you must select "Region and Language Options" from Windows Control Panel and check "Install files for East Asian languages"; you may have to use a font having East Asian glyphs (e.g. "MS Gothic") for the text runs containing East Asian characters.

Element xfc:document-information may be used to to add metadata^[4] to the documents created by XFC^[5]. This element is expected to be a child element of standard XSL-FO element fo:declarations.

<xfc:document-information>
  Content: [ xfc:meta ]*
</xfc:document-information>

<xfc:meta 
  name = non empty string
  content = string
/>

Example:

<xfc:document-information>
  <xfc:meta name="xfc:creator" content="Fox Mulder" />
  <xfc:meta name="xfc:created" content="1993-09-10" />
  <xfc:meta name="xfc:keywords" 
            content="extraterrestrial life, abduction, supernatural" />
  <xfc:meta name="is_classified" content="true" />
</xfc:document-information>

It's also possible to restrict editing in the documents created by XFC using command-line arguments /meta name value.

When both element xfc:document-information and the aforementioned command-line argument are specified, it's the command-line argument which is used. In the case of the above xfc:document-information example, /meta is_classified false may be used to replace the is_classified custom metadata.

The attributes of element xfc:meta are:

Element xfc:document-protection may be used to control the type of changes which can be made to the documents created by XFC^[6]. This element is expected to be a child element of standard XSL-FO element fo:declarations.

<xfc:document-protection
  restrictions = Restrictions
  password = string
/>

Restrictions = [ limited-formatting ]?
  [ read-only|comments-only|tracked-changes-only|fill-forms-only ]?

Example:

<xfc:document-protection password="changeit"
 restrictions="tracked-changes-only limited-formatting" />

It's also possible to restrict editing in the documents created by XFC using command-line arguments /prot restrictions and /password password.

When both element xfc:document-protection and any of the aforementioned command-line arguments are specified, it's the command-line argument which is used. In the case of the above xfc:document-protection example, /password "" may be used to discard the password.

The attributes of element xfc:document-protection are:

XFC uses an instance of the System.Text.Encoding class to determine if a given character can be represented in the output encoding. Characters that cannot be encoded are then represented using a Unicode control word (RTF output) or an XML character reference (WML, Open XML and OpenDocument output).

	This feature is supported by the ODT, WML and DOCX output formats, but not by the RTF output format.

When using East Asian fonts in a XSL-FO file^[7] to render CJK (Chinese Japanese Korean) text, these fonts must be declared to XFC.

This is done using the eastAsiaFontFamilies property. This property is specified using command line option /eaf map. The value of this property is a font family map having the following syntax:

map -> entry [',' entry]*

entry -> east_asian_family '=' western_family

Note that western_family must be an actual font family (e.g. Arial). Generic font families (e.g. sans-serif) are not supported here.

Example ("MS UI Gothic" is a Japanese font):

<fo:inline font-family="MS UI Gothic">ねこ ‎romaji neko</fo:inline>

Let's suppose the font family map used for the XSL-FO file containing the above example is:

MS UI Gothic=Times New Roman,Meiryo=Calibri

The above font family map has two effects on XFC:

XFC supports all conditional-page-master-reference element combinations that can be accommodated by a single RTF section. This means the following page sequence layouts are supported:

This applies to all output formats. Also, note that a single RTF section can handle different headers/footers on left/right/first pages, but does not allow page geometry changes, except for switching left and right margins on facing pages. This restriction does not apply to OpenDocument output.

Note: By default RTF, WML and Open XML output documents are given a double-sided page layout regardless of the input document properties. This results in all sections having separate headers/footers for odd and even pages, even though the content of both headers/footers may be identical. It may also result in blank pages being inserted in the document in order for every section to start on an odd page.

Adding a watermark to the generated document is done the way which is supported by all the other XSL-FO processors, that is, by setting the background-image property of fo:region-body. Example:

<fo:simple-page-master master-name="center"
                       margin-bottom="1.5cm" margin-left="1.5cm"
                       margin-right="1.5cm" margin-top="1.5cm"
                       page-height="29.7cm" page-width="21cm">
  <fo:region-body border-style="solid" border-width="1pt"
                  margin-bottom="0.5cm" margin-top="0.5cm" padding="7.5pt"
                  background-image="url(images/draft.png)"
                  background-position="center"/>
  <fo:region-before display-align="before" extent="0.5cm" />
  <fo:region-after display-align="after" extent="0.5cm" />
</fo:simple-page-master>

Note that only the background-image, background-position-horizontal and background-position-vertical properties (and the corresponding shorthand properties) are supported. Other background image properties such as background-repeat are ignored. Moreover the only supported values for background-position-horizontal are: left, 0%, center, 50%, right, 100% and the supported values for background-position-vertical are: top, 0%, center, 50%, bottom, 100%.

Use of expressions for property values specification is supported, subject to the following restrictions:

In addition to the decoration type (underline, overline, line-through, etc) supported by XSL-FO property text-decoration, it's possible to specify the color, style (solid, double, dotted, dashed, wavy) and thickness of the text decoration. The syntax used for extended simple properties^[8] is identical to the syntax of CSS3 property text-decoration.

text-decoration = 'inherit' | [ line || style || color || thickness ]

line = 'none' |
       [ [ 'underline' | 'no-underline' ] || [ 'overline' | 'no-overline' ] || 
         [ 'line-through' | 'no-line-through' ] || [ 'blink' | 'no-blink' ] ] 

style = 'solid' | 'double' | 'dotted' | 'dashed' | 'wavy'

color = 'currentcolor' | Hexadecimal_color | RGB_color

thickness = 'auto' | 'from-font' | Length | Percentage

Actual support of the “simple properties” comprising text-decoration by the RTF, WML, DOCX, ODT output formats varies:

	Remember that OpenOffice/LibreOffice automatically underlines hyperlinks
	By default, OpenOffice/LibreOffice automatically underlines and gives a blue color to hyperlinks. In some cases, this automatic feature may give you the impression that there is something wrong with the text-decoration property you have specified, except that you probably did not specify any text-decoration property there at all!