Frequently Asked Questions

Q: I'm supposed to be allowed to upgrade Professional Edition for free. How can I do that?

A: Please use this form: http://www.xmlmind.com/store/download.php , generally accessed through this page: http://www.xmlmind.com/foconverter/upgrade.html.

Tip: If you want to be sent an email each time a new version of XMLmind XSL-FO Converter (Personal and Professional Editions) is released, please subscribe to the xfc-announce mailing list. This is done by using the form found in this page: http://www.xmlmind.com/mailman/listinfo/xfc-announce .

Q: Do you have a trial version of XFC Professional Edition?

A: No. XFC Personal Edition can be used to evaluate XFC. More information in Evaluate Professional Edition.

Q: I use the page-number-citation object to print the number of pages in my document, but the displayed value is always 0 when I load the document in MS-Word. How can I get the correct value?

A: Page references are implemented with fields (more information ) The values of these fields are not automatically updated when loading a document in MS-Word. The easiest way to update all field values is to force a repagination of the document, for instance by switching to the Page Layout view. This will work fine for fields in the body of the document, but not for those in the headers/footers. To update fields in the headers or footers of a document, proceed as follows:

1. Switch to the Page Layout view.
2. Double-click on an odd page header/footer outline.
3. Type Ctrl-A (Select all) and F9 (Update fields).
4. Double-click on an even page header/footer outline and repeat step #3.
5. If applicable, double-click on the title page header/footer outline and repeat step #3.

Q: I cannot start XMLmind XSL Utility on my PC running Vista 64-bit. Xslutil.exe pretends that there is no suitable Java^TM runtime installed on my machine, which is simply not true because I have installed the latest 64-bit Java^TM runtime. Is there a workaround for this bug?

A: Upgrade to XMLmind XSL Utility v4.3.2.

Q: Vertical space between blocks (e.g. <xsl:attribute name="space-after.optimum">0.75em</xsl:attribute>) is almost always incorrect. Is there a workaround for this bug?

A: This problem happens only when the XSL-FO file processed by XFC is indented (generally for debugging purposes). The workaround is to instruct the XSLT engine generating the XSL-FO file not to indent it, that is replace something like:

<xsl:output method="xml" encoding="UTF-8" indent="yes"/>

by:

<xsl:output method="xml" encoding="UTF-8" indent="no"/>

This instruction is generally found at the beginning of the main XSLT style sheet.

Q: I have tested XFC using Personal Edition. But now, I need to estimate how long it will take me to integrate XFC in my application. How can I do that?

A: XFC is really easy to integrate in any application. As of XFC v4.3, you can use XFC Personal Edition to test the integration in your application. More information in Evaluate Professional Edition.

Q: This XSL technology seems elegant but also terribly complex. What can you say to convince me to take the time to learn it?

A: This technology is not that complex. And it is certainly less tedious to learn than the following formats: PDF, PostScript®, RTF, WorprocessingML, OpenOffice, etc.

XSL-FO is conceptually simple. Basically Formatting Objects are just nested blocks and text containers with attached style properties. XSL-FO is not harder to learn than HTML+CSS.

XSLT is clearly more challenging to learn than XSL-FO.

Alternatively you can use XML Query (AKA XQuery), which is, in our opinion, easier to learn and to use than XSLT. We recommend using one of these two XML query processors: Qizx/open or Saxon 9+.

Also note that, for some applications, directly generating XSL-FOs is the simplest and most efficient solution.

Q: XFC is an XSL-FO processor written in Java^TM and, by experience, I know that XML processing in Java^TM is slow to the point of being unusable. Is XFC really usable in a production environment?

A: Yes, if you do not implement the XML processing pipeline naively and if you carefully choose your software components:

• Carefully choose your XML parser. For example, use Crimson (included in Java SDK 1.4+) or Xerces 2.x (included in Java SDK 1.5+) instead of Xerces 1.x.
• Use a URI resolver and properly configured XML catalogs to prevent downloading the DTDs from the Web.
• Some XML parsers are validating parsers. Make sure to turn validation off.
• Carefully choose your XSLT processor or your XQuery processor. For example, use Saxon instead of Xalan (included in Java SDK 1.4+).
• Create a compiled representation of the XSLT style sheet (that is, invoke TransformerFactory.newTemplates(stylesheet)) and use it each time you need to transform the XML input to the XSL-FO output.

Java myth #1: Java is slow

All the benchmarks we have done show that Java speed is 2/3 (66%) the speed of optimized C/C++. This relative slowness is, in our opinion, a small price to pay given all the advantages of Java.

Java applications are indeed very slow to start. This is not a problem in a server environment where servlets run for months.

Q: Now that all major office automation formats are publicly available, well-documented, XML-based standards, why would I need a software component such as XFC?

A: Nowadays, all major office automation formats are based on very low-level XML vocabularies expressing in great details how to layout some text on a page.

WorprocessingML example (paragraph containing the following text "Some unnamed character level styles: underline, italic, bold."):

<w:p>
  <w:r>
    <w:t>Some unnamed character level styles: </w:t>
  </w:r>
  <w:r>
    <w:rPr>
      <w:u w:val="single"/>
    </w:rPr>
    <w:t>underline</w:t>
  </w:r>
  <w:r>
    <w:t>, </w:t>
  </w:r>
  <w:r>
    <w:rPr>
      <w:i/>
      <w:i-cs/>
    </w:rPr>
    <w:t>italic</w:t>
  </w:r>
  <w:r>
    <w:t>, </w:t>
  </w:r>
  <w:r>
    <w:rPr>
      <w:b/>
    </w:rPr>
    <w:t>bold</w:t>
  </w:r>
  <w:r>
    <w:t>.</w:t>
  </w:r>
</w:p>

The documentation of these formats is always very large and often obscure. Therefore, learning these formats is uninteresting and takes a long time.

This being said, now let's compare the different methods which may be used to automatically generate documents in office automation formats:

Method	Learning Curve	Easy to Maintain	Speed	Quality of Output	Multiple Output Formats	Notes
Generate the markup using println().	(You need to learn the output format.)			(This method makes it extremely tedious to generate something that looks good.)	No
Generate the markup using an XSLT style sheet.	(You need to learn the output format.)		(No XSL-FO processor.)	(This method makes it tedious to generate something that looks good because office automation formats are very low-level compared to XSL-FO.)	No
Use the word processor to generate a template. Insert variables (e.g. @My_Variable@) in this template using a text editor. The first two steps are done once for all. Generating a document simply means copying the template after substituting the variables with their values.					No	A simple solution for simple problems. Very limited. For example, you cannot add rows to a table contained in the document template.
Use an SDK specialized in generating the office automation format.	(You still need to learn the SDK.)	(You'll have to write a lot of code.)		(This method makes it tedious to generate something that looks good.)	No
Use an XSLT style sheet to generate XSL-FO. Convert the XSL-FO to the office automation format using XMLmind XSL-FO Converter.	(but it's a good investment!)				Yes

Q: XFC in its .NET version has been developed in Visual J#. Does this mean that my application integrating XFC also needs to be developed in Visual J#?

A: No, not at all. You may use any .NET language. Isn't this one of the main selling points of the .NET technology?

Note that nobody actually develops in Visual J#. Not even us, XMLmind. XFC is written in the Java^TM language. The Java^TM source code is then compiled using the Visual J# compiler. But, in order to have an API which feels native to the .NET programmer, we have also written a facade in C# which is specific to the .NET version.

The only drawback of this approach for you the programmer integrating XFC, is that your software will need the Visual J# 2.0 Redistributable in order to run.

Q: Microsoft has retired the Visual J# product. (This is explained in the Visual J# Home Page.) Does this mean that XFC in its .NET version is now obsolete?

A: No. XMLmind XSL-FO Converter is a .NET 2.0 assembly which requires the Visual J# 2.0 Redistributable in order to run. As long as .NET 2.0 assemblies will be compatible with the very latest .NET framework (this is the case for the .NET 3.5 framework: we have tested that), XMLmind XSL-FO Converter in its .NET version will not be obsolete.