Paragraphs in table cells in PDF via XSL-FO output

[kirkilj]

I've noticed that any time a table cell's content is wrapped in a paragraph, it shifts the text down unconditionally in the rendered output beyond the padding of 3pt. The shift is

I just rendered a simple test with Oxygen 22's DITA to PDF via XSL-FO. If a table cell just has text in it, there are 3pts of space around it within the cell's borders. If the text is wrapped in a paragraph, then it's about 7.4pts worth of space. The stylesheets have a common.block attr set with .6em above and below, which converts to 7.2pts, roughly.

Code: Select all

  <!-- paragraph-like blocks -->
  <xsl:attribute-set name="common.block">
    <xsl:attribute name="space-before">0.6em</xsl:attribute>
    <xsl:attribute name="space-after">0.6em</xsl:attribute>
  </xsl:attribute-set>

The generated FO in topic.fo has:

Code: Select all

<fo:table-cell border-after-color="black" border-after-style="solid"
    border-after-width="1pt" border-before-color="black"
    border-before-style="solid" border-before-width="1pt" text-align="left">
    <fo:block end-indent="3pt" font-weight="bold" space-after="3pt"
        space-after.conditionality="retain" space-before="3pt"
        space-before.conditionality="retain" start-indent="3pt">
        <fo:block space-after="0.6em" space-before="0.6em" text-indent="0em"
            >Header is wrapped in paragraph</fo:block>
    </fo:block>
</fo:table-cell>

Given my measurements, it appears that the 0.6em spacing is used and the 3pts from the block inside the cell isn't used, presumably because of the area stacking algorithm. It seems to me that the space-before and space-after attributes may need to be adjusted in general so the stacking algorithm can do the right thing or overridden just for the first paragraph in a cell. Is there some combination of the conditionality, minimum, maximum, or optimum qualifiers that would take care of commonblock spacing in such circumstances? It seems that the actual spacing at the top and bottom of a paragraph in a table cell should be 3pts and ignore the commonblock's space-before measurement, which is the opposite of what it's doing.

What is the expected layout behavior in this case?

Here is my attempt at using Acrobat's measuring "tool" to document the results:

[Dan]

Yes, the DITA-OT has an attribute set defined for the paragraphs and blocks, in the commons-attr.xsl:

Code: Select all

<!-- paragraph-like blocks -->
  <xsl:attribute-set name="common.block">
    <xsl:attribute name="space-before">0.6em</xsl:attribute>
    <xsl:attribute name="space-after">0.6em</xsl:attribute>
  </xsl:attribute-set>

And one for the table cells, in tables-attr.xsl:

Code: Select all

  <!-- contents of table entries or similer structures -->
  <xsl:attribute-set name="common.table.body.entry">
    <xsl:attribute name="space-before">3pt</xsl:attribute>
    <xsl:attribute name="space-before.conditionality">retain</xsl:attribute>
    <xsl:attribute name="space-after">3pt</xsl:attribute>
    <xsl:attribute name="space-after.conditionality">retain</xsl:attribute>
    <xsl:attribute name="start-indent">3pt</xsl:attribute>
    <xsl:attribute name="end-indent">3pt</xsl:attribute>
  </xsl:attribute-set>

As you seen, there area different values for the table cells, and the result is that the margins will not collapse well. For cells with no paragraphs the processor will use the 3pt value, for the ones with paragraphs, the 0.6em (it collapses the smaller 3pt value of the cell).
The solution is to create a DITA customization plugin and alter the common.table.body.entry set.
You can find information here:
https://www.dita-ot.org/dev/topics/pdf- ... ample.html
https://www.dita-ot.org/dev/topics/pdf- ... aches.html

We are currently developing a publishing engine for oXygen - this is already included in the oXygen XML Editor and oXygen XML Author installations and it produces PDF and WebHelp. For PDF you may use the transformation scenario is "DITA Map to PDF - based on HTML5 and CSS" listed in the Configure Transformation Scenario dialog. The advantage is that all the customization is based on CSS and is much more easier to customize and maintain. The documentation is here:
https://www.oxygenxml.com/doc/versions/22.0/ug-ope/

Many regards,
Dan