<section id="overview">
<title>Overview</title>
<p>
- Review <a href="running.html">Running FOP</a> for important information that applies
+ Review <a href="running.html">Running FOP</a> for important information that applies
to embedded applications as well as command-line use, such as options and performance.
</p>
<p>
<section id="basics">
<title>Basic Usage Pattern</title>
<p>
- Apache FOP relies heavily on JAXP. It uses SAX events exclusively to receive the XSL-FO
+ Apache FOP relies heavily on JAXP. It uses SAX events exclusively to receive the XSL-FO
input document. It is therefore a good idea that you know a few things about JAXP (which
is a good skill anyway). Let's look at the basic usage pattern for FOP...
</p>
// Step 4: Setup JAXP using identity transformer
TransformerFactory factory = TransformerFactory.newInstance();
Transformer transformer = factory.newTransformer(); // identity transformer
-
- // Step 5: Setup input and output for XSLT transformation
+
+ // Step 5: Setup input and output for XSLT transformation
// Setup input stream
Source src = new StreamSource(new File("C:/Temp/myfile.fo"));
// Resulting SAX events (the generated FO) must be piped through to FOP
Result res = new SAXResult(fop.getDefaultHandler());
-
+
// Step 6: Start XSLT transformation and FOP processing
transformer.transform(src, res);
</p>
<ul>
<li>
- <strong>Step 1:</strong> You create a new FopFactory instance. The FopFactory instance holds
+ <strong>Step 1:</strong> You create a new FopFactory instance. The FopFactory instance holds
references to configuration information and cached data. It's important to reuse this
instance if you plan to render multiple documents during a JVM's lifetime.
</li>
<li>
<strong>Step 2:</strong> You set up an OutputStream that the generated document
- will be written to. It's a good idea to buffer the OutputStream as demonstrated
+ will be written to. It's a good idea to buffer the OutputStream as demonstrated
to improve performance.
</li>
<li>
OutputStream you've setup up in step 2.
</li>
<li>
- <strong>Step 4</strong> We recommend that you use JAXP Transformers even
- if you don't do XSLT transformations to generate the XSL-FO file. This way
- you can always use the same basic pattern. The example here sets up an
- "identity transformer" which just passes the input (Source) unchanged to the
- output (Result). You don't have to work with a SAXParser if you don't do any
+ <strong>Step 4</strong> We recommend that you use JAXP Transformers even
+ if you don't do XSLT transformations to generate the XSL-FO file. This way
+ you can always use the same basic pattern. The example here sets up an
+ "identity transformer" which just passes the input (Source) unchanged to the
+ output (Result). You don't have to work with a SAXParser if you don't do any
XSLT transformations.
</li>
<li>
- <strong>Step 5:</strong> Here you set up the input and output for the XSLT
- transformation. The Source object is set up to load the "myfile.fo" file.
- The Result is set up so the output of the XSLT transformation is sent to FOP.
- The FO file is sent to FOP in the form of SAX events which is the most efficient
- way. Please always avoid saving intermediate results to a file or a memory buffer
+ <strong>Step 5:</strong> Here you set up the input and output for the XSLT
+ transformation. The Source object is set up to load the "myfile.fo" file.
+ The Result is set up so the output of the XSLT transformation is sent to FOP.
+ The FO file is sent to FOP in the form of SAX events which is the most efficient
+ way. Please always avoid saving intermediate results to a file or a memory buffer
because that affects performance negatively.
</li>
<li>
- <strong>Step 6:</strong> Finally, we start the XSLT transformation by starting
- the JAXP Transformer. As soon as the JAXP Transformer starts to send its output
- to FOP, FOP itself starts its processing in the background. When the
- <code>transform()</code> method returns FOP will also have finished converting
+ <strong>Step 6:</strong> Finally, we start the XSLT transformation by starting
+ the JAXP Transformer. As soon as the JAXP Transformer starts to send its output
+ to FOP, FOP itself starts its processing in the background. When the
+ <code>transform()</code> method returns FOP will also have finished converting
the FO file to a PDF file and you can close the OutputStream.
<note label="Tip!">
It's a good idea to enclose the whole conversion in a try..finally statement. If
</li>
</ul>
<p>
- If you're not totally familiar with JAXP Transformers, please have a look at the
+ If you're not totally familiar with JAXP Transformers, please have a look at the
<a href="#examples">Embedding examples</a> below. The section contains examples
for all sorts of use cases. If you look at all of them in turn you should be able
to see the patterns in use and the flexibility this approach offers without adding
too much complexity.
</p>
<p>
- This may look complicated at first, but it's really just the combination of an
+ This may look complicated at first, but it's really just the combination of an
XSL transformation and a FOP run. It's also easy to comment out the FOP part
- for debugging purposes, for example when you're tracking down a bug in your
+ for debugging purposes, for example when you're tracking down a bug in your
stylesheet. You can easily write the XSL-FO output from the XSL transformation
to a file to check if that part generates the expected output. An example for that
can be found in the <a href="#examples">Embedding examples</a> (See "ExampleXML2FO").
While with Avalon Logging the loggers were directly given to FOP, FOP now retrieves
its logger(s) through a statically available LogFactory. This is similar to the
general pattern that you use when you work with Apache Log4J directly, for example.
- We call this "static logging" (Commons Logging, Log4J) as opposed to "instance logging"
+ We call this "static logging" (Commons Logging, Log4J) as opposed to "instance logging"
(Avalon Logging). This has a consequence: You can't give FOP a logger for each
processing run anymore. The log output of multiple, simultaneously running FOP instances
is sent to the same logger.
the <a href="events.html">Events subsystem</a> is the right approach.
</p>
</section>
-
+
<section id="render">
<title>Processing XSL-FO</title>
<p>
- Once the Fop instance is set up, call <code>getDefaultHandler()</code> to obtain a SAX
- DefaultHandler instance to which you can send the SAX events making up the XSL-FO
+ Once the Fop instance is set up, call <code>getDefaultHandler()</code> to obtain a SAX
+ DefaultHandler instance to which you can send the SAX events making up the XSL-FO
document you'd like to render. FOP processing starts as soon as the DefaultHandler's
<code>startDocument()</code> method is called. Processing stops again when the
DefaultHandler's <code>endDocument()</code> method is called. Please refer to the basic
<section id="render-with-xslt">
<title>Processing XSL-FO generated from XML+XSLT</title>
<p>
- If you want to process XSL-FO generated from XML using XSLT we recommend
- again using standard JAXP to do the XSLT part and piping the generated SAX
- events directly through to FOP. The only thing you'd change to do that
+ If you want to process XSL-FO generated from XML using XSLT we recommend
+ again using standard JAXP to do the XSLT part and piping the generated SAX
+ events directly through to FOP. The only thing you'd change to do that
on the basic usage pattern above is to set up the Transformer differently:
</p>
<source><![CDATA[
//without XSLT:
//Transformer transformer = factory.newTransformer(); // identity transformer
-
+
//with XSLT:
Source xslt = new StreamSource(new File("mystylesheet.xsl"));
Transformer transformer = factory.newTransformer(xslt);]]></source>
<section id="input">
<title>Input Sources</title>
<p>
- The input XSL-FO document is always received by FOP as a SAX stream (see the
+ The input XSL-FO document is always received by FOP as a SAX stream (see the
<a href="../dev/design/parsing.html">Parsing Design Document</a> for the rationale).
</p>
<p>
- However, you may not always have your input document available as a SAX stream.
+ However, you may not always have your input document available as a SAX stream.
But with JAXP it's easy to convert different input sources to a SAX stream so you
can pipe it into FOP. That sounds more difficult than it is. You simply have
- to set up the right Source instance as input for the JAXP transformation.
+ to set up the right Source instance as input for the JAXP transformation.
A few examples:
</p>
<ul>
<p>
There are a variety of upstream data manipulations possible.
For example, you may have a DOM and an XSL stylesheet; or you may want to
- set variables in the stylesheet. Interface documentation and some cookbook
- solutions to these situations are provided in
+ set variables in the stylesheet. Interface documentation and some cookbook
+ solutions to these situations are provided in
<a href="http://xml.apache.org/xalan-j/usagepatterns.html">Xalan Basic Usage Patterns</a>.
</p>
</section>
<title>Customizing the FopFactory</title>
<p>
The FopFactory holds configuration data and references to objects which are reusable over
- multiple rendering runs. It's important to instantiate it only once (except in special
+ multiple rendering runs. It's important to instantiate it only once (except in special
environments) and reuse it every time to create new FOUserAgent and Fop instances.
</p>
<p>
<p>
The <strong>font base URL</strong> to use when resolving relative URLs for fonts. Example:
</p>
- <source>fopFactory.setFontBaseURL("file:///C:/Temp/fonts");</source>
+ <source>fopFactory.getFontManager().setFontBaseURL("file:///C:/Temp/fonts");</source>
</li>
<li>
<p>
- The <strong>hyphenation base URL</strong> to use when resolving relative URLs for
+ The <strong>hyphenation base URL</strong> to use when resolving relative URLs for
hyphenation patterns. Example:
</p>
<source>fopFactory.setHyphenBaseURL("file:///C:/Temp/hyph");</source>
</li>
<li>
<p>
- Disable <strong>strict validation</strong>. When disabled FOP is less strict about the rules
+ Disable <strong>strict validation</strong>. When disabled FOP is less strict about the rules
established by the XSL-FO specification. Example:
</p>
<source>fopFactory.setStrictValidation(false);</source>
</li>
<li>
<p>
- Enable an <strong>alternative set of rules for text indents</strong> that tries to mimic the behaviour of many commercial
- FO implementations, that chose to break the specification in this respect. The default of this option is
- 'false', which causes Apache FOP to behave exactly as described in the specification. To enable the
+ Enable an <strong>alternative set of rules for text indents</strong> that tries to mimic the behaviour of many commercial
+ FO implementations, that chose to break the specification in this respect. The default of this option is
+ 'false', which causes Apache FOP to behave exactly as described in the specification. To enable the
alternative behaviour, call:
</p>
<source>fopFactory.setBreakIndentInheritanceOnReferenceAreaBoundary(true);</source>
</li>
<li>
<p>
- Set the <strong>source resolution</strong> for the document. This is used internally to determine the pixel
+ Set the <strong>source resolution</strong> for the document. This is used internally to determine the pixel
size for SVG images and bitmap images without resolution information. Default: 72 dpi. Example:
</p>
<source>fopFactory.setSourceResolution(96); // =96dpi (dots/pixels per Inch)</source>
<li>
<p>
Manually add an <strong>ElementMapping instance</strong>. If you want to supply a special FOP extension
- you can give the instance to the FOUserAgent. Normally, the FOP extensions can be automatically detected
+ you can give the instance to the FOUserAgent. Normally, the FOP extensions can be automatically detected
(see the documentation on extension for more info). Example:
</p>
<source>fopFactory.addElementMapping(myElementMapping); // myElementMapping is a org.apache.fop.fo.ElementMapping</source>
<li>
<p>
Set a <strong>URIResolver</strong> for custom URI resolution. By supplying a JAXP URIResolver you can add
- custom URI resolution functionality to FOP. For example, you can use
+ custom URI resolution functionality to FOP. For example, you can use
<a href="ext:xml.apache.org/commons/resolver">Apache XML Commons Resolver</a> to make use of XCatalogs. Example:
</p>
<source>fopFactory.setURIResolver(myResolver); // myResolver is a javax.xml.transform.URIResolver</source>
<note>
Both the FopFactory and the FOUserAgent have a method to set a URIResolver. The URIResolver on the FopFactory
- is primarily used to resolve URIs on factory-level (hyphenation patterns, for example) and it is always used
+ is primarily used to resolve URIs on factory-level (hyphenation patterns, for example) and it is always used
if no other URIResolver (for example on the FOUserAgent) resolved the URI first.
</note>
</li>
<section id="user-agent">
<title>Customizing the User Agent</title>
<p>
- The user agent is the entity that allows you to interact with a single rendering run, i.e. the processing of a single
+ The user agent is the entity that allows you to interact with a single rendering run, i.e. the processing of a single
document. If you wish to customize the user agent's behaviour, the first step is to create your own instance
- of FOUserAgent using the appropriate factory method on FopFactory and pass that
+ of FOUserAgent using the appropriate factory method on FopFactory and pass that
to the factory method that will create a new Fop instance:
</p>
<source><
projects / xmlgraphics-fop.git / commitdiff