XSL Formatter V2 Q&A

This phenomenon occurs because MSXML is used as a parser. The following shows the example:

[file name：test.fo]

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE root [ <!ENTITY testseg SYSTEM "testseg.fo"> ]>
<root xmlns="http://www.w3.org/1999/XSL/Format" >
  <layout-master-set>
    <simple-page-master master-name="frame">
      <region-body region-name="frame-body"/>
    </simple-page-master>
  </layout-master-set>

  <page-sequence master-reference="frame">
    <flow flow-name="frame-body">
      &testseg;
    </flow>
  </page-sequence>
</root>

[file name：testseg.fo]

<block>
    This is a test
</block>

When there is no namespace for each entity, MSXML identifies it as null namespace, not to be FO Object. As a result, XSL Formatter cannot display the content.

That is, the namespace of the block in the external entity (testseg.fo) doesn't change to the namespace specified in the document entity (test.fo).

Therefore it is expanded as follows.

[file name：test.fo (after expansion)]

<?xml version="1.0" encoding="utf-8"?>
<root xmlns="http://www.w3.org/1999/XSL/Format" >
  <layout-master-set>
    <simple-page-master master-name="frame">
      <region-body region-name="frame-body"/>
    </simple-page-master>
  </layout-master-set>

  <page-sequence master-reference="frame">
    <flow flow-name="frame-body">
      <block xmlns="">This is a test</block>
    </flow>
  </page-sequence>
</root>

Entity name &testseg; is expanded as <block xmlns="">This is a test</block>. As xmlns="" is no a FO namespace, XSL Formatter ignores it and doesn't process it. That's why it was not reflected in a formatted result.

In order to avoid this, declare FO namespace to the block in the external entity (testseg.fo), too.

[file name：testseg.fo (after modified)]

<block xmlns="http://www.w3.org/1999/XSL/Format">
    This is a test
</block>

As XSL Formatter conforms to the keeps and breaks properties in XSL Specification, you can specify it by using this property. For example, suppose a block that contains the title of the chapter is A, next block that contains the text of the chapter is B.

1. If you specify the property break-before="page" to A, the page always breaks before A block. As the result, A block is always placed at the beginning of the page.
2. If you specify keep-with-next.within-page="always" to A, A block must be kept with B block. Therefore, there are no cases that the title of the chapter is placed at the bottom of the page separated from its text.

It is possible to use several page masters in the document, so you can display pages by making each page master of portrait and landscape as follows:

<fo:simple-page-master master-name="Portrait"
  page-width="210mm" page-height="297mm">
  ...
</fo:simple-page-master>
<fo:simple-page-master master-name="Landscape"
  page-width="297mm" page-height="210mm">
  ...
</fo:simple-page-master>

When page-width="297mm" page-height="210mm" and landscape orientation are specified in FO data, you have to set the paper size and paper orientation in printer property. Otherwise you cannot get the proper one because the default paper setting is portrait.

In version V2.2, the paper orientation is automatically changed only when working in Windows NT/2000.

Inside fo:page-sequence, elements must be properly ordered. If they are not in order, there is no guarantee of success in formatting. However, XSL Formatter is generous enough to format without causing error.

Only when the trays are sorted by the size difference, XSL Formatter can select the trays. But if the trays are sorted by color and the sizes are the same, XSL Formatter cannot distinguish the difference.

To change the size or type of papers during printer process, specify "simple-page-master" in FO. Then, XSL Formatter formats the document in different pages. When printing the document, if the size of the paper is specified to the printer, XSL Formatter automatically selects the trays.

Tray A (A4)

<fo:simple-page-master page-height="210mm" page-width="297mm">

Tray B (B5)

<fo:simple-page-master page-height="182mm" page-width="257mm">

Tray C (B6)

<fo:simple-page-master page-height="128mm" page-width="182mm">

It's possible to have the different page layouts for the first page, for even and odd pages alternately, for blank pages by specifying "page-sequence-master" to the stylesheet.

Here is a sample code for generating different layouts on even and odd pages.

<fo:layout-master-set>
    <fo:simple-page-master master-name="odd-page-master">
        <fo:region-before region-name="odd-page-header"/>
        ......other descriptions
    </fo:simple-page-master>
    <fo:simple-page-master master-name="even-page-master">
        <fo:region-before region-name="even-page-header"/>
        ......other descriptions
    </fo:simple-page-master>

    <fo:page-sequence-master master-name="main">
        <fo:repeatable-page-master-alternatives>
            <fo:conditional-page-master-reference master-name="odd-page-master" odd-or-even="odd" />
            <fo:conditional-page-master-reference master-name="even-page-master" odd-or-even="even" />
        </fo:repeatable-page-master-alternatives>
    </fo:page-sequence-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="main">
    <fo:static-content flow-name="odd-page-header">
    ......contents for header on odd pages (Specify text-align="end")
    </fo:static-content>
    <fo:static-content flow-name="even-page-header">
    ......contents for header on even pages (Specify text-align="start")
    </fo:static-content>
    <fo:flow>
    ......contents of text
    </fo:flow>
</fo:page-sequence>

It's because the default of the force-page-count property is auto. force-page-count="auto" sets pages in order of odd-page, even-page, alternately. In this case, a front page is the first page and the next body text is specified as first page, then the order becomes odd-page, odd-page, even-page. A white page is created to make an order alternately.

The XSL Recommendation says

7.25.6 "force-page-count"

auto

Force the last page in this page-sequence to be an odd-page if the
initial-page-number of the next page-sequence is even.
Force it to be an even-page if the initial-page-number of the next
page-sequence is odd. If there is no next page-sequence or if the value of
its initial-page-number is "auto" do not force any page.

In order to avoid this, specify a value of "0" to initial-page-number for a front page, or specify a value of "no-force" to force-page-count.

In your stylesheet,

<fo:block-container>

    <!-- check if the table should have the landscape style -->
    <xsl:if test="@orientation='Landscape'">
        <xsl:attribute
name="page-break-before">always</xsl:attribute>
        <xsl:attribute
name="page-break-after">always</xsl:attribute>

        <xsl:attribute
name="reference-orientation">90</xsl:attribute>
        <xsl:attribute name="height">18.5cm</xsl:attribute>
        <xsl:attribute name="width">24.7cm</xsl:attribute>

    </xsl:if>

    ... rest of the table stylesheet...

</fo:block-container>

The reason for not breaking page is that you place the table in fo:block-container. In the fo:block container, if the contents overflow the page, page break doesn't occur even though page-break is specified. In this case reference-orientation cannot be used because you cannot use block-container for the above reason.

Make another simple-pagemaster for landscape mode and specify it to its page-sequence as follows:

<fo:simple-page-master master-name="Portrait"
  page-width="210mm" page-height="297mm">
  ...
</fo:simple-page-master>
<fo:simple-page-master master-name="Landscape"
  page-width="297mm" page-height="210mm">
  ...
</fo:simple-page-master>

When reference-orientation is specified to 'fo:simple-page-master', it rotates. It is the contents of 'page-reference-area'. And the outside is not rotated.

Please refer to the following:
6.4.12 fo:simple-page-master

There is no specific definition about this in XSL-FO spec. It depends on the implementation.

According to the implementation in XSL Formatter, oustide region is upper in Z-order, because after refion-body is illustrated, the outside region is illustrated.

However, there is a possibility that this implementation may be changed in the future version of XSL Formatter.

Normally, 'margin' should be specified to refion-body so that it may not overwap the outside region.

Your FO is as follows:

<fo:layout-master-set>
    <fo:simple-page-master master-name="firstpage" page-height="210mm" page-width="297mm">
                .
                .
                .
    </fo:simple-page-master>

    <fo:simple-page-master master-name="restpage" page-height="210mm" page-width="297mm">
                .
                .
                .
    </fo:simple-page-master>

    <fo:simple-page-master master-name="blankpage" page-height="210mm" page-width="297mm">
                .
                .
                .
    </fo:simple-page-master>

    <fo:page-sequence-master master-name="document">
        <fo:repeatable-page-master-alternatives>
            <fo:conditional-page-master-reference page-position="first" master-reference="firstpage"/>
            <fo:conditional-page-master-reference page-position="rest" master-reference="restpage"/>
            <fo:conditional-page-master-reference page-position="any" master-reference="blankpage"/>
        </fo:repeatable-page-master-alternatives>
    </fo:page-sequence-master>
</fo:layout-master-set>
            .
            .
            .
            .

See the description of "rest" in the W3C XSL-FO Spec 7.25.14 "page-position".

This master is eligible for selection if this is not
the first page nor the last page in the page-sequence.

page-position="rest" is applied for the page except for page-position="first" and page-position="last". There is no fo:conditional-page-master-reference specified as page-position="last".

XSL Formatter uses the last fo:conditional-page-master-reference in fo:repeatable-page-master-alternative as the next alternative when there is no fo:conditional-page-master-reference in fo:repeatable-page-master-alternative instead of showing an error message. Then, XSL Formatter continues formatting.

Therefore, in the case of the above FO, fo:conditional-page-master in which page-position="any" is specified becomes the next alternative. The last page is formatted by using "any".

However, since incorrect FO is formatted, the result is not warranted.

This is a limitation of XSL Formatter V2 version.

<fo:layout-master-set>
    <fo:simple-page-master master-name="master_first"
                        page-height="297mm" page-width="210mm" >
        <fo:region-body margin="10mm" column-count="3"/>
    </fo:simple-page-master>
    <fo:simple-page-master master-name="master_rest"
                        page-height="297mm" page-width="210mm">
        <fo:region-body margin="10mm" column-count="2"/>
    </fo:simple-page-master>
    <fo:simple-page-master master-name="master_last"
                        page-height="297mm" page-width="210mm">
        <fo:region-body margin="10mm" column-count="2"/>
    </fo:simple-page-master>

    <fo:page-sequence-master master-name="main-sequence">
        <fo:repeatable-page-master-alternatives>
            <fo:conditional-page-master-reference
                        master-reference="master_first" page-position="first"/>
            <fo:conditional-page-master-reference
                        master-reference="master_rest" page-position="rest"/>
            <fo:conditional-page-master-reference
                        master-reference="master_rest" page-position="last"/>
        </fo:repeatable-page-master-alternatives>
    </fo:page-sequence-master>
</fo:layout-master-set>

<fo:page-sequence master-reference="main-sequence">
    <fo:flow flow-name="xsl-region-body">
            .
            .
            .
    </fo:flow>
</fo:page-sequence>

In the above example, actually the first page is supposed to have three columns and the second page or later has to be a page of two columns. However, XSL Formatter cannot change the width of the column in mid-stream of fo:flow. Therefore, the second page or later becomes a page of three columns. (However, the characters flow up to the second column.

If you want to change the width of column, please create a new fo:flow for each different width of column.

Please specify the 'fo:break-after' or 'fo:break-before' properties to your desired position. Please refer to W3C spec 7.9.1. break-after, 7.19.2. break-before for more details.

According to the spec, the value of z-index is specified as the absolute value from z-index of its parent FO. If the plus value is specified, it is placed in front. If the minus value is specified, it is placed in the back face.

5.4.5 z-index Property
The value is converted to one that is absolute; i.e., the refined value
is the specified value plus the refined value of z-index of its parent
formatting object, if any.

Except for the value of minus 1, 0, and plus 1, z-index="0" is specified.

This is a limitation of XSL Formatter. Footnote was output to the next page. However, when the area is insufficient in the next page, it overflows.

Please reduce the font size of footnote-body, reduce the number of characters, or change the position of footnote by putting the text to the new page.

We fixed this problem in the Maintenance Relase 2 version of XSL Formatter. However, XSL Formatter cannot change page during footnote.

In the following fo:page-sequence-master, the error occurs and the output is not correct.

Sample FO:

<fo:page-sequence-master master-name="main">
        <fo:repeatable-page-master-alternatives maximum-repeats="10">
             <fo:conditional-page-master-reference odd-or-even="odd"
master-reference="one"/>
             <fo:conditional-page-master-reference odd-or-even="even"
master-reference="two"/>
        </fo:repeatable-page-master-alternatives>

    <fo:single-page-master-reference master-reference="blank_1"/>

    <fo:repeatable-page-master-alternatives maximum-repeats="4">
         <fo:conditional-page-master-reference odd-or-even="even"
master-reference="two"/>
         <fo:conditional-page-master-reference odd-or-even="odd"
master-reference="one"/>
    </fo:repeatable-page-master-alternatives>
</fo:page-sequence-master>

This problem is a bug of XSL Formatter. This problem was fixed with XSL Formatter V2.5 MR3.

In this case, specify <fo:table-cell display-align="after"> instead of vertical-align="bottom".

Please add border-width.conditionality="retain" to the fo:tabe-cell property. Then rules are created at the bottom of pages.

It's because in XSL Formatter V2 the start/end indent properties conform to the XSL Specification that did not in V1.1.

According to the XSL Spec. the inheritable properties are propagated down the formatting object tree from a parent to each child.

margin-left="-.2in" margin-right="-.2in" specified to fo:table are equivalent to start-indent, end-indent. The indent property is inherited to each table-cell.

<fo:table-cell start-indent="-.2in" end-indent="-.2in" ......>

Therefore, the border-spacings are wiped out by the inherited negative indents.

In order to get the same result and avoid unexpectable inheritance, specify start-indent="0in" end-indent="0in" on each fo:table-cell or its parent fo:table-body/header/footer.

<fo:table-body start-indent="0in" end-indent="0in">

Please specify as follows, then you can hide the borders around the table.

<fo:table border-collapse="collapse" border-style="hidden">

In your Fo, border-collapse="separate" is specified to fo:table. According to the XSL Recommendation, row groups cannot have borders and paddings if it is specified to fo:table.

6.7.6 fo:table-header
......
The following properties apply to this formatting object:
......
    * [7.7 Common Border, Padding, and Background Properties]

      NOTE:
      Only the background properties from this set apply.
      If the value of border-collapse is "collapse" or
      "collapse-with-precedence" for the table the border
      properties also apply.


......

7.26.5 "border-separation"
......
In the separate borders model, each cell has an individual border. The
"border-separation" property specifies the distance between the borders
of adjacent cells. This space is filled with the background of the table
element. Rows, columns, row groups, and column groups cannot have
borders (i.e., user agents must ignore the border properties for those
elements).

In order to avoid a line break in the middle of the cell, specify keep-together.within-page="always" to fo:table-row that surrounds fo:table-cell.

7.19.3 "keep-together"
XSL Definition:

Value:  <keep> | inherit
Initial:  .within-line=auto, .within-column=auto, .within-page=auto
Applies to:  block-level formatting objects, inline formatting objects,
             fo:table-caption, fo:table-row, fo:list-item, fo:list-item-label,
             and fo:list-item-body
Inherited:  yes
Percentages:  N/A
Media:  visual

This property imposes keep-together conditions on formatting objects

....
always
Imposes a keep-together condition with strength "always" in the appropriate context

So you speicfied like this:

<fo:block-container block-progression-dimension="6pc">
 <fo:block keep-together.within-column="auto">
  This is some text.
<fo:block  break-before="column"/>
  This is more text that should be in the next column.
 <fo:block>
</fo:block-container>

The block-container is interfering with the column breaking. You cannot use page break or column break in the "block-container" property. In this case I suggest using table. Please specify block-progression-dimension="6pc" to table-row.

Or if you want to use block-container, you can get a effect you want by using <fo:block span="all"/> as follows:

<fo:block-container block-progression-dimension="6pc">
 <fo:block>
  1A) This is some text.
 </fo:block>
</fo:block-container>
<fo:block-container block-progression-dimension="6pc" break-before="column">
 <fo:block>
  1B) This is more text that should be in the next column.
 </fo:block>
</fo:block-container>
<fo:block span="all"/>

<fo:block-container block-progression-dimension="6pc">
 <fo:block>
  2A) This is some text.
 </fo:block>
</fo:block-container>
<fo:block-container block-progression-dimension="6pc" break-before="column">
 <fo:block>
  2B) This is more text that should be in the next column.
 </fo:block>
</fo:block-container>
<fo:block span="all"/>

Click here to get fo sample file.

Your sample is:

<fo:table-cell>
<fo:block>This is the info for the step ..
<fo:float float="end">
<fo:block-container>
<fo:block>
<fo:external-graphic src="url(abc.eps)"/>
</fo:block>
</fo:block-container>
</fo:float>
</fo:block>
</fo:table-cell>

To achieve the following layout,

 +------------------------+
 |This is the .---------. |
 |info for    | graphic | |
 |the step    '---------' |
 +------------------------+

Place the anchor of float at the top of paragraph, that is before "This is...". Because text strings are flowed normally until a float is found. Then the float is positioned. Please refer to the float layout of IE or Mozilla for the following code:

<div>
  The quick brown fox jumps over the lazy dog.
  <div style="float:right; width:2cm; background: yellow">Here is float</div>
</div>

The float, "Here is float", is positioned at the next line of "..lazy dog". If you change the code to:

<div>
  <div style="float:right; width:2cm; background: yellow">Here is float</div>
  The quick brown fox jumps over the lazy dog.
</div>

The float is positioned at the same line of "The quick brown...". Next, the width of float is decided by its content, but the width of block-container is not specified. The width of block-container is set at the same value as its ancestor, in this case, table-cell. If you use fo:block instead of fo:block-container, the width of float is set at the width of its content. Following is the revised code:

<fo:table-cell>
<fo:block>
<fo:float float="end">
<fo:block>
<fo:external-graphic src="url(abc.eps)"/>
</fo:block>
</fo:float>This is the info for the step ..
</fo:block>
</fo:table-cell>

This issue is not a bug but a specification of CSS2 referenced by W3C Recommendation. See more detail here.

http://www.w3.org/TR/REC-CSS2/tables.html#width-layout

However, the table layout in the case that table-layout = "auto" is not determined in the CSS2 Recommendation. So, authors are not required to implement this algorithm. Therefore when the column is spanned, the text doesn't line -wrap and cell width is expanded to fit the text on a single line in the current XSL Formatter.

In order to avoid this, please specify the total width of column-width to fo:table.

By the way, from V2.3 XSL Formatter is modified so that the column width becomes fixed whether column spans or not, when table-layout="auto" is specified.

It's possible by specifying like this: <fo:table-and-caption text-align="outside">

This behavior was a bug until V2.3 in Algorithm of auto table layout. The column width is determined by the width of the cell content. At that time the border width specified to the cell is also processed.

e.g.

<table border-collapse="collapse-with-precedence">
<table-body>
<table-row>
<table-cell
    border-end-precedence="9"
    border-end-style="hidden"
    border-end-width="2pt">
    <block>r1c1</block>
</table-cell>
<table-cell
    border-start-precedence="10"
    border-style="solid"
    border-start-width="2pt">
    <block>r1c2</block></table-cell>
</table-row>
</table-body>
</table>

In this example, although the border-end of r1c1 is hidden, border-style="solid" border-start-width="2pt" is specified to r1c2 and it takes precedence for collapse-with-precedence, it becomes the border between r1c1 and r1c2.

When calculating the necessary column width for r1c1 under the condition of 'table auto layout', the border specified to the next is ignored. For this reason, by the column width decided by auto layout, the width of a cell may become narrow by the part of the border, and an undesirable line breaking occurs without the contents having entered.
We would like to fix it in the future.

This issue is a limitation of XSL Formatter spec. Pages in a nested table cannot be broken.

XSL Formatter V3 does not have this limitation.

The following shows the example:

<fo:table table-layout="auto" inline-progression-dimension="100%">
 <fo:table-column column-width="2in"/>
  <fo:table-column/>
  <fo:table-column/>
  <fo:table-column/>
   <fo:table-body>
    <fo:table-row>
     <fo:table-cell border-start-style="solid" border-before-color="black">
       <fo:block>
        Row 1 Cell 1
       </fo:block>
      </fo:table-cell>
     <fo:table-cell border-start-style="solid" border-before-color="black" >
       <fo:block>
        Row 1 Cell 2
       </fo:block>
      </fo:table-cell>
       ......
       ......
  </fo:table-row>
 </fo:table-body>
</fo:table>

When table-layout="auto" is specified, in some cases, it may happen that the width of the table column doesn't become the one specified by column-width. It depends on the algorithm of Automatic table layout.

cf. CSS2 17.5.2 Table width algorithms: the 'table-layout' property http://www.w3.org/TR/REC-CSS2/tables.html#propdef-table-layout

The value specified to the column-width becomes the minimum width of the column. When inline-progression-dimension of the table is specified and the value is larger than the width of the table decided from column width, the width of the extra part is distributed and added to the column width.

Please get more info form Automatic table layout in CSS2 17.5.2.

In order to rotate a table you need to use reference-orientation. In the XSL-FO Spec, reference-orientation cannot be specified to fo:block or fo:table-and-caption reference-orientation is a property applied to fo:block-container. Then specify fo:table under fo:block-container.

However, pages cannot be broken inside the area of fo:block-container with XSL Formatter (V2.3MR-1). Therefore unfortunately its impossible to rotate a table that overflows across several pages. Although this way is effective when a table is within a page.

XSL Formatter V3 does not have this limitation.

In XSL Formatter V2, if fo:table is nested, pages cannot be broken and the overflow error occurs. This is a limitation of current XSL Formatter V2. In addition, even if you don't intend to nest the table, there may be a case that the table is nested according to the stylesheet written as follows:

<xsl:template match="paragraph">
  <fo:table>
    <fo:table-body width="165mm">
      <fo:table-row width="165mm">
        <fo:table-cell width="25mm">
          <fo:block id="{@link_id}" font-size="12pt" font-family="Arial">
            <xsl:value-of select="@number"/>
          </fo:block>
        </fo:table-cell>
        <fo:table-cell width="140mm">
          <fo:block font-family="Arial" font-size="12pt" text-align="justify">
            <xsl:apply-templates/>
          </fo:block>
        </fo:table-cell>
      </fo:table-row>
    </fo:table-body>
  </fo:table>
</xsl:template>

If the whole paragraph is achieved by fo:table and there is a table inside the paragraph, it becomes a nest of fo:table. In order to achieve such paragraph (the layout divided into right and left), please use fo:list-block.

<xsl:template match="paragraph">
  <fo:list-block provisional-distance-between-starts="25mm">
    <fo:list-item>
      <fo:list-item-label end-indent="label-end()">
          <fo:block id="{@link_id}" font-size="12pt" font-family="Arial">
            <xsl:value-of select="@number"/>
          </fo:block>
      </fo:list-item-label>
      <fo:list-item-body start-indent="body-start()">
          <fo:block font-family="Arial" font-size="12pt" text-align="justify">
            <xsl:apply-templates/>
          </fo:block>
      </fo:list-item-body>
    </fo:list-item>
  </fo:list-block>
</xsl:template>

Also it's necessary to specify the start-indent="0mm", and the end-indent="0mm" properties to fo:table-header, fo:table-body and fo:table-footer in order to avoid the inheritance of unexpected indent.

XSL Formatter V3 does not have this limitation.

Yes. The header is not shown if true is specified to the fo:block table-omit-header-at-break(omit header) property. The default value of table-omit-header-at-break is "false" and when the page breaks table-header is output.

space-after is effective if it is placed in the last of reference-area by specifying space-after="8mm" space-after.conditionality="retain".

It means that when the page breaks, space-after is effective to each divided page (a page before break and a page after break). Therefore the space of 8mm is generated also after the table on the page before break.

Please specify padding-after instead of space-after in this case.

You have to specify the height of the cell contens.

W3C Recommendation says as follows:

6.7.10 fo:table-cell
The method for determining the block-progression-dimension of the cell
in the grid is governed by the row-height trait.

Therefore, you need to specify inline-progression-dimension to the block-coutainer in the table-cell.

This problem occurs when there is a table which corresponds to the following all conditions and the column and the page break in the table.

• The border property is specified for fo:table.
• There are either fo:table-header or fo:table-footer in the table. Or, the both are in the table.
• The value of table-omit-header-at-break or the table-omit-footer-at-break is "false".

The problem doesn't occur when neither fo:table-header nor fo:table-footer are used. Moreover, if border-width is thin(1pt), it might be all right in use.

It is possible to draw correctly by the following ways.

• Specify border-top/border-right/border-left for fo:table-header.
• Specify border-bottom/border-right/border-left for fo:table-footer.
• Specify border-right/border-left for fo:table-body.

This problem is a limitation of XSL Formatter V2.

XSL Formatter V3 does not have this limitation.

No. In the XSL-FO specification, such a function is not provided.

No. It is impossible. Span property must be "all" or "none".Please refer to XSL Specification 7.20.4.

In XSL-FO Spec, such a function is not provided. However, if <fo:block spam="all" /> is inserted at the end of fo:flow, it is possible.

No, It' impossible. It's not permitted in the W3C Recommendation.

According to the W3C Recommendation :

The fo:footnote is typically used to produce footnote-citations within
the region-body of a page and the corresponding footnote in a separate
area nearer the after-edge of the page.

Additionally, an fo:footnote is not permitted to have as a descendant an
fo:block-container that generates an absolutely positioned area.

In addition, by using the extension function "axf:footnote-position" of XSL Formatter , it's possible to place the footnote on each column. Please see also the online manual of XSL Formatter.

No. It's impossible with XSL Formatter. We consider the possibilities of providing a proprietary solution with the future version.

In your stylesheet, you should have

<fo:layout-master-set>
       <fo:simple-page-master master-name="first_page" page-height="11in"
page-width="8.5in">

rather than

  <fo:layout-master-set page-height="11in" page-width="8.5in">
       <fo:simple-page-master master-name="first_page">

Even though you want to specify letter size for paper size, as it doesn't specify any paper size and XSL Formatter takes the default paper size 'A4'. Your footer is supposed to be placed in A4 and it cannot be printed in your letter-size paper. That's why your footer disappears.

It is impossible. And, the function is not provided in the XSL-FO spec.

However we are going to support this as AXF extention function in the future.

Contents of a current page, header, and footer can be synchronized by using fo:marker and fo:retrieve-marker.

See XSL-FO spec 6.11.3 fo:marker and 6.11.4 fo:retrieve-marker.

XSL Formatter places a footnote on the next page when the footnote cannot be placed on the same page as an anchor when processing before-float and footnote. Please refer to [No.2003011003] for this.

However, the footnote that should be output to the same page might be output to the page as follows or after that. This matter happens when the string of the anchor of the footnote is empty.

This problem was fixed with XSL Formatter V2.5 MR3.

<fo:block margin-top="10pt" xsl:use-attribute-sets="MIDASHI">

margin-top is equivalent to space-before in XSL, but only the difference is that margin-top is considered to be space-before.conditionality="retain", and as the result, top margin is set right after braking pages. In order to avoid this, use space-before instead of margin-top.

<fo:block space-before="10pt" xsl:use-attribute-sets="MIDASHI"> 

Because margin-left is not affected by writing-mode, that is written in the XSL specification. Writing-mode affects start-indent, end-indent, space-before, space-after. Please use start-indent instead of margin-left.

It's because of the inheritance. In W3C Recommendation, some of the properties are "inheritable" from a parent to each child. It is called [inheritance].

'margin-left' is not an inheritable property originally. However, margin-left is supposed to be converted to start-indent and start-indent is an inheritable property.

start-indent = margin-corresponding + padding-corresponding + border-corresponding-width
end-indent = margin-corresponding + padding-corresponding + border-corresponding-width

(See W3C Recommendation. XSL Spec. 5.3.2)

Therefore when specifying margin-left (if border, padding are 0), it is the same as specifying start-indent and it is inherited inside the table.

If you don't want to let start-indent/end-indent inherited, specify start-indent="0cm" to table-body/table-header/table-footer.

In the following FO, the text is not indented.

<fo:block start-indent="from-nearest-specified-value(start-indent) + 1cm">
     First line
<fo:block start-indent="from-nearest-specified-value(start-indent) + 1cm">
     Second line
<fo:block start-indent="from-nearest-specified-value(start-indent) + 1cm">
     Third line
</fo:block>
</fo:block>
</fo:block>

The formatted result is as follows.

First line
Second line
Third line

This is a bug of XSL Formatter. It should be placed as follows.

First line
    Second line
        Third line

We'll fix it in the future version.

<fo:block font-size="10pt"
          line-height="12pt"
          start-indent="1.5pc"
          text-align-last="justify"
          end-indent="3pc"
          last-line-end-indent="-3pc">
          AAAA BBBB CCCC DDDD EEEE FFFF GGGG HHHH IIII JJJJ KKKK LLLL MMMM OO
          <fo:leader leader-pattern="dots"/>
          Z
</fo:block>

This was a bug of XSL Formatter until V2.3. We will fix it in the next version.

Although, by specifying 'keep', it's possible to avoid placing only the page numbers on the left so that leader and page-number-citation are not separated.

<fo:block font-size="10pt"
          line-height="12pt"
          start-indent="1.5pc"
          text-align-last="justify"
          end-indent="3pc"
          last-line-end-indent="-3pc">
          AAAA BBBB CCCC DDDD EEEE FFFF GGGG HHHH IIII JJJJ KKKK LLLL MMMM OO
          <fo:leader leader-pattern="dots"/>
          <fo:inline keep-together.within-line="always">
                <fo:leader leader-pattern="dots"/>
                Z
          </fo:inline>
</fo:block>

This problem was fixed with XSL Formatter V2.4.

XSL-FO specification says as follows:

5.11. Property Datatypes
    If the computed value of a corresponding relative property is set
    from the corresponding absolute property, the latter is used in determining
    all the components of the former.
    For example, assuming a block-progression-direction of "top-to-bottom",
    in a specification of
    margin-top="10.0pt"
    space-before.minimum="4.0pt"
    the explicit setting of one of the components of the corresponding relative
    property will have no effect.

Therefore, XSL Formatter uses margin. The result might be different from other software.

Sample FO:

<fo:list-item>
  <fo:list-item-label text-align="end" end-indent="label-end()">
    <fo:block>1.</fo:block>
  </fo:list-item-label>
  <fo:list-item-body start-indent="body-start()">
    <fo:block-container>
      <fo:table start-indent="0pt">
        <fo:table-body>
          <fo:table-row>
            <fo:table-cell>
              <fo:block>fo:table start-indent="0pt"</fo:block>
            </fo:table-cell>
          </fo:table-row>
        </fo:table-body>
      </fo:table>
    </fo:block-container>
  </fo:list-item-body>
</fo:list-item>

In this case, start-indent of fo:list-item-body is inherited to fo:block-container. And, the reference area of block-container is generated. In this reference area, start-indent specified for fo:table is effective. Therefore, the indent inherited to the reference area remains.

When start-indent="0pt" is specified for fo:block-container, the indent of the reference area is reset.

You need to specify value of "span" property as "all" to place an object span on multiple columns. This "span" property is implemented in XSL Formatter.

U+000A code is generally treated as a character. And U+000A code is converted to U+0020(space) code by the linefeed-treatment property. If you want to line-break with U+000A code, specify the linefeed-treatment="preserve" property to fo:block.

W3C description:

7.29.23 "white-space"

CSS2 Definition:
......
The CSS property shall be treated as a shorthand by XSL and maps as follows:
pre
    linefeed-treatment="preserve"
    white-space-collapse="false"
    white-space-treatment="preserve"
    wrap-option="no-wrap"

The following program doesn't break line.

<xsl:attribute name="white-space">
pre
</xsl:attribute>

white-space="pre" is the same as specifying the above 4 properties. The reason why the word does not wrap is "pre" includes the instruction of "no-wrap". Please specify as follows:

<xsl:attribute name="linefeed-treatment">
preserve
</xsl:attribute>

<xsl:attribute name="wrap-option">
wrap
</xsl:attribute>

In your file, fo:character is used in the wrong way. According to the XSL Spec, you can specify only one character to fo:character.

<fo:character character="Glossary "/>
<fo:character character=", "/>
(Two characters, comma and space, are specified)

In order to avoid this, use another property for plural characters instead of fo:character.

In your stylesheet,

<fo:block  position="absolute" top="10mm" right="30mm">
     This text should be positioned?
</fo:block>

The absolute position property is applied to fo:block container not to fo:block. Please specify as follows:

<fo:block-container  position="absolute" top="10mm" right="30mm">
   <fo:block>This text should be positioned ?</fo:block>
</fo:block-container>

In your stylesheet,

<fo:block white-space-treatment="preserve"
linefeed-treatment="preserve">
  apple
      4, 7, 7, 12
</fo:block>

Initial value of the white-space-collapse property replaces all remaining runs of two or more consecutive spaces by a single space, then any remaining space immediately adjacent to a remaining linefeed is also discarded. Initial value is true. So you have to specify "false"to avoid this.

You need one more property as follows:

<fo:block white-space-treatment="preserve"
linefeed-treatment="preserve" white-space-collapse="false">
  apple
      4, 7, 7, 12
</fo:block>

The "block-progression-dimension" property and the "reference-orientation" property can't be specified to fo:block. Please specify them to fo:block-container.

The space becomes wider if you specify plus value to "word-spacing" and "word-spacing.precedence" property. If you need narrow space, please set minus values to this property. However, it's inevitable that space between words in a narrow column becomes somewhat wider.

The space between words may look much wider because the function of "justify" does not widen the space between characters with the current XSL Formatter. Even though you specify "hyphenation = true" there is a limitation because the place where the word can be split has a limitation.

The default space width depends on fonts. And the default space width is equal to the width of white space of that font. Space width of Western fonts such as "Times New Roman" is usually 0.25em.

Enclose the text with fo:block, or specify linefeed-treatment="preserve" to fo:block and specify #x0A（line feed code）to the position you want to linefeed.

In your FO:

<fo:simple-page-master master-name="master"
     page-height="11in"
     page-width="8.5in">
<fo:region-body/>
        .
  <fo:region-start extent="0.5in"/>
        .
</fo:simple-page-master>
        .
        .
        .
<fo:static-content flow-name="xsl-region-start">
  <fo:block-container reference-orientation="90">
    <fo:block text-align="center">
      content text.
    </fo:block>
  </fo:block-container>
</fo:static-content>

The size of reference-area created by fo:block-container becomes the size of the content automatically because there is no size specified. Therefore the size is equal to the size of the text content of 'start edge'. Because of that reason, even though text-align="center"is specified, it doesn't work. If you want to center the text content, please specify display-align="center" to fo:region-start.

In your file:

<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
<fo:layout-master-set>
<fo:simple-page-master master-name="master1"
        page-height="11in"
        page-width="8.5in">
<fo:region-body/>
<fo:region-after extent="0.5in"/>
<fo:region-before extent="0.5in"/>
<fo:region-start extent="0.5in"/>
<fo:region-end extent="0.5in"/>
</fo:simple-page-master>
</fo:layout-master-set>

<fo:page-sequence master-reference="master1" font-size="12pt">
   ...
<fo:flow flow-name="xsl-region-body" display-align="center">
   ...
<fo:block-container
              writing-mode="tb-rl"
              inline-progression-dimension="20%"
              block-progression-dimension="100%">
<fo:block>
      This is a content.
      This is a content.
      This is a content.
</fo:block>
</fo:block-container>
</fo:flow>
</fo:page-sequence>
</fo:root>

The reason why error occurs is because you specify block-progression-dimension="100%" to fo:block-container.

You specify page-height is 11inch, page-width is 8.5inch, margin of region-body is zoro. Page direction is lr-tb as default because nothing specified. As you specify writing-mode as tb-rl to fo:block-container, block-progression-dimention becomes the width of the block containter.

Before XSL Formatter V2.3MR1, if you specify block-progresion-dimention by percent value, it is calculated from the size of the nearest ancestor.

That is, as block-container is directly under fo:flow, the value is calculated from block-progression-dimension of the page. As writing-mode of the page is lr-tb, block-progression-dimension of the page is 11inch and it is equal to specfy 100% of the page. Because Actual width of the page is 8.5inch, XSL Formatter trys to set block container of 11inch-width. Then the overflow error occurs.

In XSL Spec it is unclear where the value of percent value should be taken from in the case that the reference area is rotated. We are planning to change the way of taking the standard percent value. Please do not specify percent value as size when the reference-area is rotated.

This issue is limitation of XSL Formatter V2.x spec. XSL Fromatter can't break pages in process of fo:block-container.

XSL Formatter V3 does not have this limitation.

This is a bug of XSL Fomratter. Your FO is as follows:

<fo:list-item>
    <fo:list-item-label>
        <fo:block text-align="end"> 1 </fo:block>
    </fo:list-item-label>
    <fo:list-item-body>
        <fo:block space-after="1.0em"> aaa </fo:block>
    </fo:list-item-body>
</fo:list-item>

<fo:list-item>
    <fo:list-item-label>
        <fo:block text-align="end"> 2 </fo:block>
    </fo:list-item-label>
    <fo:list-item-body>
        <fo:block space-after="1.0em"> bbb </fo:block>
    </fo:list-item-body>
</fo:list-item>

<fo:list-item>
    <fo:list-item-label>
        <fo:block text-align="end"> 3 </fo:block>
    </fo:list-item-label>
    <fo:list-item-body>
        <fo:block space-after="1.0em"> ccc </fo:block>
    </fo:list-item-body>
</fo:list-item>

In this FO, when the page breaks between the list-item "aaa" and the list-item "bbb", space-after="1.0em" specified to fo:block of "bbb" is ignored. We will fix it in the future version.

This problem was considered as a bug of XSL Formatter when it was reported before. This was because the space resolution rule for the ordinary block was applied to the spacing in list-item.

However the specification interpretation of the space of list-item was corrected in XSL Formatter V2.4. According to the XSL specification 6.8.3 fo:list-item, space-before and space-after speicified to the block in the list-item are disregarded altogether in spite of the page breaking.

Therefore, the formatted results may differ from that of V2.3 or before. Thank you for your understanding.

Please specify space-after to fo:list-item instead of fo:block as follows:

<fo:list-item space-after="1.0em">
    <fo:list-item-label>
        <fo:block text-align="end"> 1 </fo:block>
    </fo:list-item-label>
    <fo:list-item-body>
        <fo:block> aaa </fo:block>
    </fo:list-item-body>
</fo:list-item>

I have to say that it is specification of XSL. The 'text-decoration' property is valid for text contents only. Please refer to the following W3C description:

--------------------------------------------------
7.16.4 "text-decoration"
CSS2 Definition:

... If the element has no content or no text content (e.g., the IMG
element in HTML), user agents must ignore this property.

It's impossible. The position of list-block is decided according to indent. Therefore, you can't specify text-align to list-block. Please refer to '6.8 Formatting Objects for Lists' on W3C Recommendation.

On the other hand, CSS 16.2 Alignment: the 'text-align' property says that 'This property describes how inline content of a block is aligned'. Therefore this property doesn't describe how blocklevel object is aligned.

For example if you specify as follows:

<fo:block text-align="center">
<fo:list-block>…

text-align is applied to the inline contents in the list-item-label and the list-item-body properties.

The standard value for each position is the distance from the outside area of fo:block-container as follows:

• top: Off-set from the top edge of the containing area
• bottom: Off-set from the bottom edge of the containing area
• right: Off-set from the right edge of the containing area
• left: Off-set from the left edge of the containing area

Sample FO:

<fo:float float="outside">
<fo:block>* THIS IS A FLOAT *</fo:block>
</fo:float>

<fo:block  intrusion-displace="block">
<fo:block>
    First Block
</fo:block>
<fo:block>
    Second Block
</fo:block>
<fo:block>
    Third Block
</fo:block>
</fo:block>

In this case, intrusion-displace="block" of "Third Block" doesn't work when the page is changed in the "Second Block".

Moreover, when you specify float="inside/outside" in fo:float and specify intrusion-displace="block" in fo:block, side doesn't change even if the page breaks in this block.

This problem is a limitation of XSL Formatter V2.

The span property cannot be specified for the list in XSL-FO. Therefore, the content of the message is wrong.

This problem was fixed with XSL Formatter V2.5 MR3.

This matter happens when the output area of fo:page-number in fo:block-container for which width is specified is insufficient.

This problem was fixed with XSL Formatter V2.5 MR3.

No.

<fo:block/> doesn't generate the inline area. Therefore, even if <fo:block/> is consecutive, the blank line is not generated.

It is necessary to include FO or the text that generates the inline area in fo:block.

The blank line is generated when there is <fo:block>&#xA0;</fo:block>.

This problem was fixed with XSL Formatter V2.5 MR3.

This error occurs when there is FO such as <fo:block>3&#x200C;</foblock> or <fo:inline>aa&#x200C;</fo:inline>. This problem was fixed with XSL Formatter V2.5 MR3.

This problem occurs in block for which keep-together.within-page="always" is specified when the column and the page break.

This problem is a limitation of XSL Formatter V2.

XSL Formatter V3 does not have this limitation.

keep-together="always" is equivalent to a specification of the followings.

 keep-together.within-line="always"
 keep-together.within-colums="always"
 keep-together.within-page="always"

When keep-together.within-line="always" is specified, the hyphenation doesn't work with XSL Formatter V2. The reason is that the hyphenation is unnecessary in the line that doesn't break.

On XSL-FO specification, keep-together="always" should be inherited to the child element. However, XSL Formatter V2 does not inherit.

This is a limitation of XSL Formatter V2.

There is no problem when keep-together.within-line/.within-columns/.within-page is specified. Or it works by enclosing the content of fo:block with fo:inline as follows.

<fo:block keep-together="always">
    <fo:inline>
        Sample Contents....
    </fo:inline>
</fo:block>

XSL Formatter V3 does not have a limitation of inherit of keep-together="always".

The treatment of white space at a line break point is different in V2/V3.0/V3.1R1 and V3.1MR1.

In XSL Formatter V2/V3.0/V3, the treatment of white space at a line-break point is specified by suppress-at-line-break property.

• http://www.w3.org/TR/xsl/slice7.html#suppress-at-line-break

Initial value of suppress-at-line-break is auto, and code point U+0020 is treated as if 'suppress' had been specified. As a result, the generated area is deleted.

To retain white space at line-break point, please specify usage-context-of-suppress-at-line-break="ignore" such as:

<fo:block white-space-collapse="false" usage-context-of-suppress-at-line-break="ignore">
     &#x0020;
</fo:block>.

usage-context-of-suppress-at-line-break (UCSLB) property was introduced in Errata in REC-xsl-20011015.

• http://www.w3.org/2001/10/REC-XSL-20011015-errata

In current XSL 1.0 Errata, the specification of suppress-at-linebreak and white-space-treatment are changed, and usage-context-of-suppress-at-line-break is deleted. Before it was changed, the following specifications had been defined.

7.16.4 "usage-context-of-suppress-at-line-break"
XSL Definition:

Value:  auto | observe | ignore | inherit
Initial:  auto
Applies to:  fo:block, fo:inline, fo:page-number, fo:page-number-citation
Inherited:  yes
Percentages:  N/A
Media:  visual

This property specifies the usage context of the character property
"suppress-at-line-break". It specifies if this character property
should apply or not.

Values for this property have the following meanings:

auto
If the value of the "wrap-option" trait on the current formatting
object to which the "usage-context-of-suppress-at-line-break"
applies is "no-wrap", the "auto" value specifies the same processing
of descendant fo:character formatting objects as if "ignore" had been
specified for the "usage-context-of-suppress-at-line-break" property.
Otherwise it specifies the same processing of descendant fo:character
formatting objects as if "observe" had been specified for the
"usage-context-of-suppress-at-line-break" property.

observe
Specifies that descendant fo:character formatting objects should be
treated using the computed value of the "suppress-at-line-break" property
of the fo:character formatting object.

ignore
Specifies that descendant fo:character formatting objects should be
treated as if the "suppress-at-line-break" property of the fo:character
formatting object had the value "retain".

It may control the suppress-at-line-break (SLB) property as follows:

R: white space is retained.

D: white space is deleted.

In XSL Formatter, suppress-at-line-break is not supported. Therefore, it is processed as an initial value "auto". However, this property cannot be specified for fo:block even if supported.

The reason is that this property is applied to fo:character, and it is not inherited. Therefore, it is necessary to specify property by using fo:character as follows.

<fo:block>
    <fo:character character="' '" suppress-at-line-break="retain"/>
</fo:block>

XSL Formatter supports usage-context-of-suppress-at-line-break. Therefore, when usage-context-of-suppress-at-line-break="ignore" is specified, the space is not deleted in suppress-at-line-break="auto".

XSL Formatter V3.1MR1 changed the processing of white-space-treatment and suppress-at-line-break according to latest XSL 1.0 Errata and XSL 1.1 WD. If white-space-treatment="preserve" is specified, the white space of line-break point is retained. And usage-context-of-suppress-at-line-break is maintained for compatibility. If the value is auto, it works as observe. ( If value is auto and wrap-option="no-wrap", it works as ignore before these are changed. ) If usage-context-of-suppress-at-line-break="ignore" is specified, the white space is retained as well as before.

XSL-FO spec says as follows:

7.16.7 "treat-as-word-space"
...
auto
The value of this property is determined by the Unicode code point for
the character.

As the default behavior:

The characters at code points U+0020 and U+00A0 are treated as if 'true'
had been specified. All other characters are treated as if 'false' had
been specified.

This property does not automatically apply word spacing to the fixed
spaces (U+2000 through U+200A) or the ideographic-space (U+3000).

As for XSL Formatter, the treatment of the space in justify also follows this spec and a full-width white space is processed as 1 character of full width, unlike a half-width white space. Therefore it is not treated as the adjustment target of justify.

Moreover, unlike a half-width white space, the full-width white space is not deleted when it comes to the head/end of the line. Please refer to the following URL to see the treatment of the half-width white space when it comes to the head/end of the line.

• [No.2003101601]

Hyphenation is done by hyphenation dictionary.

Hyphenation dictionary is a TeX file that is compatible with the FOP hyphenation dictionary. XSL Formatter hyphenate words by converting existing TeX hyphenation dictionary to XML file and copying it to the hyphenation folder.

XSL Formatter attaches only English hyphenation dictionary because of the copyright. Therefore if you want to use the hyphenation dictionary that is not attached, you must prepare for it.

In case of Spanish:

1. Convert Spanish TeX hyphenation dictionary to FOP compatible hyphenation dictionary. (This is manual operation. see hyphenation.dtd in the on-line manual) (Recommended encoding is UTF-8 or UTF-16)
2. Give the name of es.xml to this FOP compatible hyphenation dictionary. And copy this file to the hyphenation folder where XSL formatter is installed.
3. To do hyphenation, specify the language and hyphenation to FO explicitly.

   <fo:block xml:lang="es" hyphenate="true">
   ...
   </fo:block>
   

4. Execute XSL Formatter.

Antenna House provides you with the availability of an optional hyphenation package for XSL Formatter.

This optional module greatly simplifies setup for hyphenating over 40 different languages, extends the number of languages supported, improves the quality of hyphenation, and further enhances overall performance.

The software is currently only available for Windows users with Version 2.5 or later.

It's possible to hyphenate by inserting "&#xAD;", the special character for Soft Hyphen.

func­tio­nality

"&#xAD;" is usually not shown. If the word breaks at the point, it changes into a hyphen and the word is hyphenated.

Your original fo is as follows:

<fo:block font-size="8pt">
<fo:float float="start">
<fo:block>
<fo:inline font-size="30pt">H</fo:inline>
</fo:block>
</fo:float>ere, we have a crop cap that should be 3-lines high.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
</fo:block>

It should be corrected as follows:

<fo:block font-size="8pt">
<fo:float float="start">
<fo:block space-after="-8pt" space-after.conditionality="retain">
<fo:inline font-size="30pt">H</fo:inline>
</fo:block>
</fo:float>ere, we have a crop cap that should be 3-lines high.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
Now is the time for all good men.
</fo:block>

Key points are 'space-after="-8pt"' that eliminate the after space of the block object in the float. And 'space-after.conditionality="retain"' to set the space-after effective at the after-edge of reference area. Please note that space-before/after is discarded at the start/after-edge of reference area, because the default value of space-before/after-conditionality is discard.

The width of fo:float is decided depending on its content. According to the XSL-FO Recommendation:

6.10.2 fo:float
...
Side-floats derive their length in the inline-progression-dimension
intrinsically from their child areas; the length is not determined by an
explicit property value.

Thinking from this part:

Side-floats derive their length in the inline-progression-dimension
intrinsically from their child areas

There is no definition in case the content of side-float has no width, XSL Spec seems to assume that long text strings, which require line breaking, does not become the content of float.

As this specification does not permit us to specify inline-progression-dimension (width) directly to fo:float, Place fo:block-container in fo:block and specify inline-progression-dimension to fo:block-container.

Comparing these examples below. When writing FO as follows, the body text and the text in the float area are placed side by side closely.

<fo:float float="start"><fo:block-container>
<fo:block border-style="solid" border-color="black" border-width="1pt">
<fo:block  start-indent="1em" text-align="justify">
    Float example No.1 Float example No.1 Float example No.1
</fo:block>
</fo:block>
</fo:block-container>
</fo:float>

Then consider the following example to interspace between the body text and the text in the float area by specifying indent to the block as the child element of float.

As [fo:float float="start"] is specified in the following example, end-indent is specified to the block-container as a child element.

<fo:float float="start">
<fo:block-container end-indent="1em">
<fo:block border-style="solid" border-color="black" border-width="1pt">
<fo:block  start-indent="1em" text-align="justify">
    Float example No.1 Float example No.1 Float example No.1
</fo:block>
</fo:block>
</fo:block-container>
</fo:float>

In the following example, start-indent is specified to [fo:float float="end"].

Note: In this case start-indent is specified to the block-container, and again it is specified to the block as a child element of the block-container. In this case, the inheritance of start-indent specified to the block-container is re-set by the start-indent specified to the block. Then the indent value specified to the block-container is added to the indent value specified to the block by using 'inherit'.

<fo:float float="end">
<fo:block-container start-indent="1em">
<fo:block border-style="solid" border-color="black" border-width="1pt">
<fo:block start-indent="1em+inherit" text-align="justify">
     Float example No.2 Float example No.2 Float example No.2
</fo:block>
</fo:block>
</fo:block-container>
</fo:float>

When there is a text after fo:float, and intrusion-displace="block" is specified for block, intrusion-displace="block" doesn't work.

Sample FO

<fo:block intrusion-displace="block">
    <fo:float float="end">
        <fo:block>float text</fo:block>
    </fo:float>
Sample Text Sample Text
</fo:block>

It works by enclosing the text with fo:block. Please refer to the following samples.

<fo:block intrusion-displace="block">
    <fo:float float="end">
        <fo:block>float text</fo:block>
    </fo:float>
<fo:block>Sample Text Sample Text</fo:block>
</fo:block>

This problem is a limitation of XSL Formatter V2.

fo:wrapper is convenient when you want to specify inheritable properties. For example: If you want to set the same indent in the child blocks of the fo:block-container,

<fo:block-container>
  <fo:wrapper start-indent="..." end-indent="...">
    <xsl:apply-templates/>
  </fo:wrapper>
</fo:block-container>

It is because block-container itself is indented and child of block-container is also indented, if you specify "indent" to fo:block-container instead of fo:wrapper.

Also you can specify non-inheritable property to fo:wrapper, then the child is inherited from its parent.

If the property is not specified to fo:wrapper, it is equivalent to specify default value. Then it looks as if fo:wrapper inhibits the inheritance.

<fo:flow border-before-style="solid">
  <fo:wrapper>
    <fo:block border-before-style="inherit">
The "inherit" value is none.

<fo:flow border-before-style="solid">
  <fo:wrapper border-before-style="inherit">
    <fo:block border-before-style="inherit">
The "inherit" value is solid.

This behavior is not peculiar to the matter of indent. Most of the problem of getting an unexpected result is the matter of inheritance. Please think of the inheritence first.

As the first step, check if the parent property is inherited or not. There are two types in the property specifed to the parent FO. One is inherited, the other is non-inherited. The inherited property affects the child property and the affected result is often shown as an unexpected format.

If you don't want to have it double indented, you need to reset the property (specify 'start-indent=0in' to fo:block, for example) and finish inheritting.

W3C Recommendation
http://www.w3.org/TR/2001/REC-xsl-20011015/

Until V2.2, it's a restriction that axf:suppress-duplicate-pagebasic-link-number works on the condition that fo:page-number-citation should be siblings. From V2.3, we remove this restriction. Therefore page number reduction is available with no problem.

XSL Formatter outputs all the document information data to the PDF file. However, there is a problem. In the PDF specification, the limitations of the display of Acrobat are 255 bytes.

And, It is necessary to store the document information with PDFDocEncoding (ASCII corresponding) or Unicode. XSL Formatter stores everything with Unicode. Therefore, the display is short.

This process is modified with XSL Formatter V2.5 PDF Option MR2. Only when all characters in the information can be converted into PDFDocEncoding, XSL Formatter stores everything with PDFDocEncoding. However, displayed string is shorter in case the string exceeds the limitation of Acrobat.

In Extentions of XSL Formatter V3, axf:background-image is provided. If the background image is specified by using this property, you can put the watermark in the page.

In the Graphics on the Sample tutorial page, there is a watermark sample that uses SVG.

Yes. You can output a table of contents by taking out the text of table of contents from XML document, when transformed by XSLT.

No, it's impossible with XSL Formatter. This will be reviewed if it's available in the future version.

Yes, It's possible. Katakana numbering is generated by specifying <xsl:number format="&#x30A4;" /> in the stylesheet.

Please refer to the following:

XSLT Spec 7.7.1 Number to String Conversion Attribltes
format="ア" specifies Katakana numbering
format="イ" specifies Katakana numbering in the "iroha" order

Be sure you have XSLT Processor installed. Antenna House confirmed MSXML4 is available.

In your XSL-FO:

<fo:table-cell margin-top="10pt" margin-bottom="10pt" font-weight="bold">
  <fo:block text-align="justify" keep-together="always">
    Antenna House XSL Formatter
  </fo:block>
  <fo:block text-align="justify" keep-together="always">
    <fo:inline font-weight="bold">
      XSL Formatting engine that is based on XSL Version 1.0, a recommendation of the W3C.
    </fo:inline>
  </fo:block>
</fo:table-cell>

keep-together="always" is specified to fo:block. keep-together has the 'within-page', 'within-column' and 'within-line' components. Therefore if you specify the keep-together="always" property, it is equal to specifying "always" to all the three components, and "always" is specified to keep-together.within-line.

And it is inherited to fo:inline. Therefore this property tries to set in single string.

In your document, it's better to specify keep-together.within-page="always" rather than keep-together="always", so that the table cell fits in one page.

<fo:table-cell margin-top="10pt" margin-bottom="10pt" font-weight="bold">
  <fo:block text-align="justify" keep-together.within-page="always">
    Antenna House XSL Formatter
  </fo:block>
  <fo:block text-align="justify" keep-together.within-page="always">
    <fo:inline font-weight="bold">
      XSL Formatting engine that is based on XSL Version 1.0, a recommendation of the W3C.
    </fo:inline>
  </fo:block>
</fo:table-cell>

It's possible by using script in a stylesheet. (Note: As it's an extensional function of XSLT, it depends on XSTL processor you use.)

<xsl:stylesheet version="1.0"
    xmlns:fo="http://www.w3.org/1999/XSL/Format"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:msxsl="urn:schemas-microsoft-com:xslt">
    <!-- msxsl:script get date -->
    <msxsl:script language="JScript" implements-prefix="user">
        function date(nodelist) {
            var DateObj = new Date()
            return DateObj.getFullYear() + "yy" +
                    (DateObj.getMonth() +1 )+ "mm" +
                        DateObj.getDate() + "dd";
        }
    </msxsl:script>

-----syncopation----

    <!-Output creation date -->
    <fo:block text-align="right">
        Creation date<xsl:value-of select="user:date()"/>
    </fo:block>

FO is as follows:

<fo:page-sequence-master master-name="PageMaster">
    ...
    <fo:conditional-page-master-reference master-reference="last-page-left"
        odd-or-even="even" blank-or-not-blank="not-blank" page-position="last"/>

    <fo:conditional-page-master-reference master-reference="blank-page"
        odd-or-even="even" blank-or-not-blank="blank" page-position="last"/>
</fo:page-sequence-master>
    ...
<fo:page-sequence master-reference="PageMaster" force-page-count="end-on-even">
    ...
    <fo:static-content flow-name="first-and-rest-footer">
        <fo:block>
            Total number of pages = <fo:page-number-citation ref-id="LastPage" />
        </fo:block>
    </fo:static-content>
    <fo:static-content flow-name="last-page-left-footer">
        <fo:block id="LastPage" />
    </fo:static-content>
    <fo:static-content flow-name="blank-page-footer">
        <fo:block id="LastPage-blank" />
    </fo:static-content>
    ....

There are two pages for which "page-position="last"" is specified.

And, the ID that refers to the total page number, in other words, the page number of the last page indicates the ID of the block that exists in only one-sided pages.

When this page master is used, the last page becomes either of master-reference="last-page-left" or master-reference="last-page-left". Which it is used is influenced by the value of force-page-count of fo:page-sequence.

When force-page-count="end-on-even" is specified and contens of fo:flow ends with the even page, As for the layout of the last page, master-reference="last-page-left" is used.

And, the page number is output to <fo:page-number-citation ref-id="LastPage" />. However, when contents of fo:flow ends with the odd page, the even page is added, and master-reference="blank-page" is used. Therefore, page-number-citation loses referred id. As a result, the total number of pages is not output. When the page number is not obtained, XSL Formatter outputs "***".

xsl:script is a specification added with XSLT1.1. What is the XSLT processor that you are using? And, does it support XSLT1.1

XSL Formatter uses MSXML at default. MSXML does not support xsl:script. However, it contains msxsl:script as an extentions element.

The usage of msxsl:script is in MSXML SDK.

Please specify the text-transform property. The text is converted.

See XSL-FO spec 7.16.6 "text-transform".

According to the W3C Recommendation :

6.6.11 fo:page-number-citation
The fo:page-number-citation is used to reference the page-number for
the page containing the first normal area returned by the cited
formatting object.

fo:wrapper does not generate the area. Therefore, it is not possible to refer from fo:page-number-citation.

This problem is a bug of V2.4MR1 version. This problem was fixed with XSL Formatter V2.5.

"scale-to-fit" scales the size of an image according to the specified value of width/height. When width/height is not specified, it is displayed with the original size of an image. Please specify the width/hight of the image.

This problem is improved by XSL Formatter MR2 or later. Please check the version of XSL Formatter which you are using. If the version is old, please update XSL Formatter.

This is big issue of XSL Specification. Antenna House selected to be conformant to XSL Specification, while RenderX does not. See following in detail.

> We noted that Antenna House tool will inherit the start-indent= property
> from the block in which the footnote is placed, while RenderX does not.

See the RenderX's "Non-Conformance Issues" http://www.renderx.com/Tests/doc/html/spec.html#N4831

| XEP 2.7 is known to have the following non-conformities to the XSL
| 1.0 Recommendation:
...
| Inherited properties on <fo:footnote-body> and <fo:float> elements
|     In the XSL 1.0 Recommendation, <fo:footnote-body> and <fo:float>
|     obey to common inheritance rules. It implies that they get
|     inherited properties from the anchor point -- despite being
|     formatted into a separate area. This scheme turned out to be
|     extremely unpractical: footnotes/floats would inherit font
|     attributes from inline elements, keep-together constraints from
|     headings, indents from lists etc. To ensure that footnotes and
|     floats look uniformly in the XSL Recommendation model, a
|     stylesheet writer would have to care to specify an explicit
|     value for virtually every inhertable property on each
|     <fo:footnote-body>/<fo:float>.
|
|     In this situation, we could not help sacrifying conformance to
|     usability. In XEP 2.7 as in previous versions of XEP, out-of-line
|     elements inherit properties from their ancestor <fo:flow>, thus
|     introducing a kind of "region-to-region" inheritance -- from
|     body-region to its conditional subregions.

> Looking at 6.10.4 in the Recommendation, it does not say one way or the other that
> inheritable properties of <footnote-body> contents are inherited from the
> ancestors of the <footnote> construct. 

The W3C Recommendation says:

| 5.1.4 Inheritance
|
| ... The inheritable properties are propagated down the formatting
|object tree from a parent to each child. ...

To avoid unexpected inheritance, you should specify inheritable properties (start-indent="0pt" text-align="start" etc.) on every fo:footnote-body.

> But, we turned on the
> text-decoration= inheritable property and note that that inheritable
> property is not being inherited by the <footnote-body> descendants.

The text-decoration is not inherited because text-decoration is not an inheritable property. (see the spec 7.16.4 "text-decoration")

Your fo is as follows:

<fo:flow flow-name="xsl-region-body">
    <fo:block>
        content text 1
    </fo:block>
    <fo:block-container reference-orientation="90" >
        <fo:block-container reference-orientation="-90" >
            <fo:block>
                content text 2
            </fo:block>
        </fo:block-container>
    </fo:block-container>
</fo:flow>

In other word, reference-orientation is specified to fo-block-container and again in this fo-block-container there is nested fo-block-container. Only when reference-orientation is specified to the parent fo:block-container, 'content text 1' and 'content text 2' fit into 1 page. However, in the above FO, 'content text 1' and 'content text 2' are divided into 2 pages.

When fo:blok-container is rotated by specifying reference-orientation="90" and block-progression-dimension, inline-progression-dimension are auto (nothing secified), XSL-FO Spec doesn't define clearly how the size of reference-area should be decided.

(The difference of understanding is the difference of the formatted resultbetween AXF and XEP.)

Antenna House XSL Formatter takes the following process:

<fo:block-container reference-orientation="90">

The above block-container has no block-progression-dimension property nor inline-progression-dimension property. In this case, as Antenna House XSL Formatter rotates 90 degrees, the size of block-progression-dimension of the reference-area becomes the size of inline-progresson-dimention of outside reference-area(in other word, resion-body). And the size of inline-progression-dimension is set as the size of the block-progression-dimention of resion-body temporarily, and after formatting the content of block-container, the size of inline-progression-dimension is adjusted according to the formatted result.

However, fo:block-container is nested as follows:

<fo:block-container reference-orientation="-90">

Therefore, the size of the reference-area created by fo-block-container fills up the region-body area and is displayed to the next page.

In order to avoid this, please be sure to specify block-progression-dimension and inline-progression-dimension to fo:block-container, when you use fo:block-container that is nested and rotated.

However, Please be careful to the following:

Before XSL Formatter V2.3MR1, if you specify block-progresion-dimension by %, it is calculated from the size of the nearist ancestor. At that time if the reference-area is rotated, block-progression-dimension, inline-progression-dimension take the percentage of the nearest block-progression-dimension, inline-progression-dimension as its size.

However, in XSL Spec it is unclear where the value of % should be taken from in the case that the reference area is rotated. We are planning to change the way of taking the standard % value. Please do not specify % value as size when the reference-area is rotated.

XSL Formatter conforms to the XSL Spec. Please let me explain about XSL=FO 7.27.7 "writing-mode".

When "writing-mode" is applied to the simple-page-master, it is used to
determine the placement of the five regions on the master.

Then, as you mentioned, when writing-mode is specified to fo:simple-page-master, it affects the positioning of 5 regions. (fo:region-body, fo:region-before, fo:region-after, fo:region-start, fo:region-end) Next, writing-mode is an inheritable property. Therefore if writing-mode is specified to fo:simple-page-master, it is inherited to the child property, fo:region-*. That is, writing-mode is supposed to be specified to region-*, too.

In case that writing-mode is specified to region-*, XSL-FO Spec says as follows:

When "writing-mode" is applied to the fo:region-*, it defines the
column-progression within each region. The inline-progression-direction
is used to determine the stacking direction for columns (and the default
flow order of text from column-to-column).

In XEP, when writing-mode is specified to fo:region-body, only the column-progression-direction of region-body is changed, it doesn't affect to block-progression-direction / inline-progression-direction of region-body.

While, XSL Formatter changes the column-progression-direction of region-body, furthermore, it also changes block-progression-direction and inline-progression-direction.

According to the explanation in the XSL-FO Spec, I suppose the sentence 'it defines the column-progression within each region.' may be misunderstood. It's saying about column but it's not saying 'only column'. The main text of writing-mode definition, that is a premise of this explanation, says it also defines block-/inline-progression-direction/shift-direction. This means that the content of region-body also change its writing mode.

In the XSL 1.0 Spec, the writing-mode property is applied to neither fo:flow nor fo:page-sequence. The same is true of fo:block.

As the writing-mode property is set to reference-area, it is applied to fo that defines reference-area (fo:region-body, fo:block-container, for example). The area inside the reference-area basically inherits the writing-mode of reference-area.

fo:region-body defines the writing-mode of region-reference-area or normal-flow-reference-area. The writing-mode of block-area becomes the same.

This looks inconsistent with the inheritance model of FO tree in the XSL 1.0 spec, (fo:region-body is not an ancestor of fo:block as a content of fo:flow in the FO tree structure, however the writing-mode affects the fo:region-body ) however, we suppose it's because the writing-mode is considered to be special as it defines the character of reference-area.

Otherwise, the writing-mode in the normal-flow-reference-area should be able to specified to fo:flow. However if it can be done, a funny phenomenon that the flow in the columns with vertical writing mode becomes all in the horizontal mode may occur and the spec becomes complicated. Then we assume that this way may not be taken.

In addition, there is a description as follows in the XSL-FO Spec 'writing-mode':

To change the "writing-mode" within an fo:flow or fo:static-content,
either the fo:block-container or the fo:inline-container, as appropriate,
should be used.

In this explanation, it is telling the case of changing writing-mode differently from that of fo:region within a fo:flow or fo:static-content besides the setting of writing-mode to fo:region-*. It does not limit the way of writing-mode setting.

According to the above reason, we consider that XSL Formatter conforms to XSL-FO Specification. The content text of page master is set according to the writing-mode that is specified to fo:simple-page-master/fo:region-*.

When formatting using the following FO, the line height of the formatted result is different in XSL Formatter and FOP.

<fo:block line-height="1.5" font-size="12pt" font-family="serif">
This is a text string. This is a text string. This is a text string.
</fo:block>

XSL Formatter generates the accurate value of the line height according to the W3C Consortium.

7.15.4 "line-height" XSL modifications to the
 CSS definition:
In XSL the "line-height" property is used in
 determining the half-leading trait.

You can get the actual size by measuring with a rule after printing the formatted result. The result value generated by FOP seems narrower than the specified one. We don't know the reason.

The default value is considered as the cause in the difference of border width.

An initial value of border-width is medium. In the XSL-FO specification, this value is written dependence on the user agent. XSL Formatter defines the following values as an initial value.

"thin" = 1pt
"medium" = 3pt
"thick" = 5pt

These values can be changed by the Formatting Option.

In FOP, the value when border width is not specified is 1pt. It is a better way to specify width to obtain the same result.