Re: Why so much differences with the PDF generated by Apache FOP?

Hussein Shafie <[email protected]> Mon, 12 Dec 2016 17:14:42 +0100
Newsgroups gmane.text.xml.xfc.general
Message-ID <[email protected]>
IMPORTANT: My answer assumes that you are aware that Evaluation Edition 
generates useless output containing random duplicate letters. See "About 
Evaluation Edition" in http://www.xmlmind.com/foconverter/downloadeval.shtml



Premysl S. wrote:
>
> we are seriously considering buying java xfc license for server. We need to be able to make docx/odt file, which looks like generated pdf, from xsl-fo files similar to the attached one. When I use pdf converter, the result is too much different to generated docx. I have attached one example in zip file with all necessary stuff for docx/odt compilation and result pdf, odt and docx. Have you please any idea, how we could fix it? Or do we use any functions, your software doesn’t support?
>

I've seen nothing really wrong in test.odt (didn't look at test.docx but 
I guess it looks the same).

The differences you have are caused by the fact that you have only 
tested the XSL-FO you create against a single XSL-FO processor: Apache FOP.

Please find attached to this email xslfo.pdf, which is xslfo.txt 
converted to PDF but this time using RenderX XEP. Notice for example, 
the same problems with the page footers as with XMLmind XSL-FO Converter.



--> In practice, this means that you'll have to slightly change your 
doc.xslt to make it support XSL-FO processors other than Apache FOP.

This is done as follows. Excerpts from our own XSLT 2.0 stylesheets:
---
<xsl:choose>
...
<xsl:when test="$foProcessor eq 'FOP'">
    <!-- FOP does not support table-layout=auto. -->
    <xsl:attribute name="table-layout">fixed</xsl:attribute>

    <xsl:variable name="columns" select="count(./*[1]/*)"/>

    <xsl:for-each select="1 to $columns">
      <fo:table-column column-number="{.}"
                       column-width="proportional-column-width(1)"/>
    </xsl:for-each>
</xsl:when>

<xsl:otherwise>
    <xsl:attribute name="table-layout">auto</xsl:attribute>
</xsl:otherwise>
...
</xsl:choose>
---

The important line in the snippet above being
<xsl:when test="$foProcessor eq 'FOP'">

$foProcessor is a parameter you should pass to the XSLT stylesheet. Its 
value typically specifies the nickname (FOP, XEP, XFC, etc) of the 
XSL-FO processor you'll use to process the generated XSL-FO



--> After looking at your sample, I would say that solving all the 
discrepancies found in test.docx and test.odt should be simple and 
quick. Of course, for that, you'll need an XSLT programmer who will take 
the time to carefully read "XMLmind XSL-FO Converter - User's Guide, 5. 
Support of the XSL-FO v1.0 standard", 
http://www.xmlmind.com/foconverter/_distrib/doc/user/index.html

Example 1: in attached xslfo2.txt I have very quickly changed the tables 
contained in the header and in the footer (Unlike any other XSL-FO 
Processor, Apache FOP only support fixed table layout). This gives 
attached xslo2.odt, which already looks better than the test.odt you 
sent us.

Example 2: proprietary extensions xfc:tab-position, xfc:tab-align may be 
used to solve the <fo:leader> problem of the TOC. See "4.3. Leaders", 
http://www.xmlmind.com/foconverter/_distrib/doc/user/implementation.html#leaders



--> This being said, there are a few things our XMLmind XSL-FO Converter 
cannot do, for example:

1) Compute  <fo:page-number/>, <fo:page-number-citation>, etc.

As explained in this FAQ -- 
http://www.xmlmind.com/foconverter/faq.html#fields -- only the word 
processor opening the generated ODT or DOCX can do that.

2) Embed TTF fonts in the ODT or DOCX.

You can certainly reference fonts Eurostile and Roboto in the ODT or 
DOCX, but not embed them.








--
XMLmind FO Converter Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/xfc-support