Correct url
git-svn-id: http://svn.apache.org/repos/asf/xmlgraphics/site/trunk@1750324 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/content/fop/0.95/embedding.mdtext b/content/fop/0.95/embedding.mdtext
index da1cccb..da1bd19 100644
--- a/content/fop/0.95/embedding.mdtext
+++ b/content/fop/0.95/embedding.mdtext
@@ -301,19 +301,19 @@
### ExampleFO2PDF.java { #ExampleFO2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
### ExampleXML2FO.java { #ExampleXML2FO}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
### ExampleXML2PDF.java { #ExampleXML2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
@@ -321,7 +321,7 @@
### ExampleObj2XML.java { #ExampleObj2XML}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
@@ -333,17 +333,17 @@
### ExampleObj2PDF.java { #ExampleObj2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
### ExampleDOM2PDF.java { #ExampleDOM2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
### ExampleSVG2PDF.java (PDF Transcoder example) { #ExampleSVG2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
### Final notes { #example-notes}
diff --git a/content/fop/0.95/intermediate.mdtext b/content/fop/0.95/intermediate.mdtext
index 3f31b19..2d50a4d 100644
--- a/content/fop/0.95/intermediate.mdtext
+++ b/content/fop/0.95/intermediate.mdtext
@@ -13,7 +13,7 @@
As already mentioned, the IF is generated by using the **XMLRenderer** (MIME type: **application/X-fop-areatree**). So, you basically set the right MIME type for the output format and process your FO files as if you would create a PDF file. However, there is an important detail to consider: The various Renderers don't all use the same font sources. To be able to create the right area tree for the ultimate output file, you need to create the IF file using the right font setup. This is achieved by telling the XMLRenderer to mimic another renderer. This is done by calling the XMLRenderer's mimicRenderer() method with an instance of the ultimate target renderer as the single parameter. This has a consequence: An IF file rendered with the Java2DRenderer may not look as expected when it was actually generated for the PDF renderer. For renderers that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the intermediate format file is the first step.
-The second step is to reparse the IF file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the IF file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the IF processing in the [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution
+The second step is to reparse the IF file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the IF file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the IF processing in the [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution
The basic pattern to parse the IF format looks like this:
@@ -49,7 +49,7 @@
### Concatenating Documents { #concat}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple IF files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple IF files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
### Modifying Documents { #modifying}
diff --git a/content/fop/0.95/upgrading.mdtext b/content/fop/0.95/upgrading.mdtext
index 34ea2bc..47b6318 100644
--- a/content/fop/0.95/upgrading.mdtext
+++ b/content/fop/0.95/upgrading.mdtext
@@ -35,6 +35,6 @@
- As stated above empty table cells `<fo:table-cell></fo:table-cell>` are not allowed by the specification. The same applies to empty `static-content` and `block-container` elements, for example.
-- 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic`) or `instream-foreign-object` objects. If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the new, more correct behaviour.
+- 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic`) or `instream-foreign-object` objects. If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the new, more correct behaviour.
- The `fox:outline` extension is not implemented in this version anymore. It has been superseded by the new bookmark elements from XSL-FO 1.1. So please update your stylesheets accordingly.
diff --git a/content/fop/1.0/embedding.mdtext b/content/fop/1.0/embedding.mdtext
index bf3929c..d0c8617 100644
--- a/content/fop/1.0/embedding.mdtext
+++ b/content/fop/1.0/embedding.mdtext
@@ -338,19 +338,19 @@
### ExampleFO2PDF.java { #ExampleFO2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
### ExampleXML2FO.java { #ExampleXML2FO}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
### ExampleXML2PDF.java { #ExampleXML2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
@@ -358,7 +358,7 @@
### ExampleObj2XML.java { #ExampleObj2XML}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
@@ -370,17 +370,17 @@
### ExampleObj2PDF.java { #ExampleObj2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
### ExampleDOM2PDF.java { #ExampleDOM2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
### ExampleSVG2PDF.java (PDF Transcoder example) { #ExampleSVG2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
### Final notes { #example-notes}
diff --git a/content/fop/1.0/events.mdtext b/content/fop/1.0/events.mdtext
index 32cbabb..1c94f64 100644
--- a/content/fop/1.0/events.mdtext
+++ b/content/fop/1.0/events.mdtext
@@ -26,7 +26,7 @@
The `EventFormatter` class can be used to translate the events into human-readable, localized messages.
-A full example of what is shown here can be found in the `examples/embedding/java/embedding/events` directory in the FOP distribution. The example can also be accessed [via the web](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/events/).
+A full example of what is shown here can be found in the `examples/embedding/java/embedding/events` directory in the FOP distribution. The example can also be accessed [via the web](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/events/).
### Writing an EventListener { #write-listener}
diff --git a/content/fop/1.0/intermediate.mdtext b/content/fop/1.0/intermediate.mdtext
index 59867d5..40e6cb7 100644
--- a/content/fop/1.0/intermediate.mdtext
+++ b/content/fop/1.0/intermediate.mdtext
@@ -50,7 +50,7 @@
However, there is an important detail to consider: The various Renderers don't all use the same font sources. To be able to create the right area tree for the ultimate output format, you need to create the area tree XML file using the right font setup. This is achieved by telling the XMLRenderer to mimic another renderer. This is done by calling the XMLRenderer's mimicRenderer() method with an instance of the ultimate target renderer as the single parameter. This has a consequence: An area tree XML file rendered with the Java2DRenderer may not look as expected when it was actually generated for the PDF renderer. For renderers that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the area tree XML format file is the first step.
-The second step is to reparse the file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the area tree XML file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the area tree XML processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
+The second step is to reparse the file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the area tree XML file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the area tree XML processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the area tree XML format looks like this:
@@ -86,7 +86,7 @@
### Concatenating Documents { #concat}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/atxml/ExampleConcat.java) example shows you can easily parse multiple area tree files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/atxml/ExampleConcat.java) example shows you can easily parse multiple area tree files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
### Modifying Documents { #modifying}
@@ -111,7 +111,7 @@
As with the AT XML, there is an important detail to consider: The various output implementations don't all use the same font sources. To be able to create the right IF for the ultimate output file, you need to create the IF file using the right font setup. This is achieved by telling the IFRenderer (responsible for converting the area tree into calls to the IFDocumentHandler and IFPainter interfaces) to mimic another renderer. This is done by calling the IFSerializer's mimicDocumentHandler() method with an instance of the ultimate target document handler as the single parameter. This has a consequence: An IF file rendered with the Java2DDocumentHandler may not look as expected when it was actually generated for the PDF implementation. For implementations that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the Intermediate Format file is the first step.
-The second step is to reparse the file using the **IFParser** which is found in the org.apache.fop.render.intermediate package. The IFParser simply takes an IFDocumentHandler instance against which it generates the appropriate calls. The IFParser is implemented as a SAX ContentHandler so you're free to choose the method for post-processing the IF file(s). You can use XSLT or write SAX- or DOM-based code to manipulate the contents. You can find examples for the Intermediate Format processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
+The second step is to reparse the file using the **IFParser** which is found in the org.apache.fop.render.intermediate package. The IFParser simply takes an IFDocumentHandler instance against which it generates the appropriate calls. The IFParser is implemented as a SAX ContentHandler so you're free to choose the method for post-processing the IF file(s). You can use XSLT or write SAX- or DOM-based code to manipulate the contents. You can find examples for the Intermediate Format processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the intermediate format looks like this:
@@ -150,7 +150,7 @@
### Concatenating Documents { #concat-if}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly (without the intermediate step). As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple intermediate files in a row and use the IFConcatenator class to concatenate page sequences from multiple source files to a single output file. This particular example does the concatenation on the level of the IFDocumentHandler interface. You could also do this in XSLT or using SAX on the XML level. Whatever suits your process best.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly (without the intermediate step). As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple intermediate files in a row and use the IFConcatenator class to concatenate page sequences from multiple source files to a single output file. This particular example does the concatenation on the level of the IFDocumentHandler interface. You could also do this in XSLT or using SAX on the XML level. Whatever suits your process best.
### Modifying Documents { #modifying-if}
diff --git a/content/fop/1.0/upgrading.mdtext b/content/fop/1.0/upgrading.mdtext
index 05a23a1..cbf2040 100644
--- a/content/fop/1.0/upgrading.mdtext
+++ b/content/fop/1.0/upgrading.mdtext
@@ -37,6 +37,6 @@
- As stated above empty table cells `<fo:table-cell></fo:table-cell>` are not allowed by the specification. The same applies to empty `static-content` and `block-container` elements, for example.
-- 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic` or `instream-foreign-object` objects). If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the new, more correct behaviour.
+- 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic` or `instream-foreign-object` objects). If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the new, more correct behaviour.
- The `fox:outline` extension is not implemented in this version anymore. It has been superseded by the new bookmark elements from XSL-FO 1.1.
diff --git a/content/fop/1.1/embedding.mdtext b/content/fop/1.1/embedding.mdtext
index 3c48095..c1e4f7b 100644
--- a/content/fop/1.1/embedding.mdtext
+++ b/content/fop/1.1/embedding.mdtext
@@ -372,19 +372,19 @@
### ExampleFO2PDF.java { #ExampleFO2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
### ExampleXML2FO.java { #ExampleXML2FO}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
### ExampleXML2PDF.java { #ExampleXML2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
@@ -392,7 +392,7 @@
### ExampleObj2XML.java { #ExampleObj2XML}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
@@ -404,17 +404,17 @@
### ExampleObj2PDF.java { #ExampleObj2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
### ExampleDOM2PDF.java { #ExampleDOM2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
### ExampleSVG2PDF.java (PDF Transcoder example) { #ExampleSVG2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
### ExampleConcat.java (IF Concatenation example) { #ExampleConcat}
diff --git a/content/fop/1.1/events.mdtext b/content/fop/1.1/events.mdtext
index 32cbabb..1c94f64 100644
--- a/content/fop/1.1/events.mdtext
+++ b/content/fop/1.1/events.mdtext
@@ -26,7 +26,7 @@
The `EventFormatter` class can be used to translate the events into human-readable, localized messages.
-A full example of what is shown here can be found in the `examples/embedding/java/embedding/events` directory in the FOP distribution. The example can also be accessed [via the web](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/events/).
+A full example of what is shown here can be found in the `examples/embedding/java/embedding/events` directory in the FOP distribution. The example can also be accessed [via the web](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/events/).
### Writing an EventListener { #write-listener}
diff --git a/content/fop/1.1/intermediate.mdtext b/content/fop/1.1/intermediate.mdtext
index 59867d5..40e6cb7 100644
--- a/content/fop/1.1/intermediate.mdtext
+++ b/content/fop/1.1/intermediate.mdtext
@@ -50,7 +50,7 @@
However, there is an important detail to consider: The various Renderers don't all use the same font sources. To be able to create the right area tree for the ultimate output format, you need to create the area tree XML file using the right font setup. This is achieved by telling the XMLRenderer to mimic another renderer. This is done by calling the XMLRenderer's mimicRenderer() method with an instance of the ultimate target renderer as the single parameter. This has a consequence: An area tree XML file rendered with the Java2DRenderer may not look as expected when it was actually generated for the PDF renderer. For renderers that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the area tree XML format file is the first step.
-The second step is to reparse the file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the area tree XML file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the area tree XML processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
+The second step is to reparse the file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the area tree XML file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the area tree XML processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the area tree XML format looks like this:
@@ -86,7 +86,7 @@
### Concatenating Documents { #concat}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/atxml/ExampleConcat.java) example shows you can easily parse multiple area tree files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/atxml/ExampleConcat.java) example shows you can easily parse multiple area tree files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
### Modifying Documents { #modifying}
@@ -111,7 +111,7 @@
As with the AT XML, there is an important detail to consider: The various output implementations don't all use the same font sources. To be able to create the right IF for the ultimate output file, you need to create the IF file using the right font setup. This is achieved by telling the IFRenderer (responsible for converting the area tree into calls to the IFDocumentHandler and IFPainter interfaces) to mimic another renderer. This is done by calling the IFSerializer's mimicDocumentHandler() method with an instance of the ultimate target document handler as the single parameter. This has a consequence: An IF file rendered with the Java2DDocumentHandler may not look as expected when it was actually generated for the PDF implementation. For implementations that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the Intermediate Format file is the first step.
-The second step is to reparse the file using the **IFParser** which is found in the org.apache.fop.render.intermediate package. The IFParser simply takes an IFDocumentHandler instance against which it generates the appropriate calls. The IFParser is implemented as a SAX ContentHandler so you're free to choose the method for post-processing the IF file(s). You can use XSLT or write SAX- or DOM-based code to manipulate the contents. You can find examples for the Intermediate Format processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
+The second step is to reparse the file using the **IFParser** which is found in the org.apache.fop.render.intermediate package. The IFParser simply takes an IFDocumentHandler instance against which it generates the appropriate calls. The IFParser is implemented as a SAX ContentHandler so you're free to choose the method for post-processing the IF file(s). You can use XSLT or write SAX- or DOM-based code to manipulate the contents. You can find examples for the Intermediate Format processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the intermediate format looks like this:
@@ -150,7 +150,7 @@
### Concatenating Documents { #concat-if}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly (without the intermediate step). As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple intermediate files in a row and use the IFConcatenator class to concatenate page sequences from multiple source files to a single output file. This particular example does the concatenation on the level of the IFDocumentHandler interface. You could also do this in XSLT or using SAX on the XML level. Whatever suits your process best.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly (without the intermediate step). As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple intermediate files in a row and use the IFConcatenator class to concatenate page sequences from multiple source files to a single output file. This particular example does the concatenation on the level of the IFDocumentHandler interface. You could also do this in XSLT or using SAX on the XML level. Whatever suits your process best.
### Modifying Documents { #modifying-if}
diff --git a/content/fop/1.1/upgrading.mdtext b/content/fop/1.1/upgrading.mdtext
index 6adf30d..5bf5a08 100644
--- a/content/fop/1.1/upgrading.mdtext
+++ b/content/fop/1.1/upgrading.mdtext
@@ -55,6 +55,6 @@
- As stated above, empty table cells `<fo:table-cell></fo:table-cell>` are not allowed by the specification. The same applies to empty `fo:static-content` and `fo:block-container` elements, for example.
-- Version 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic`) or `instream-foreign-object` objects. If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the correct behaviour.
+- Version 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic`) or `instream-foreign-object` objects. If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the correct behaviour.
- The `fox:outline` extension is not implemented in the current version: it has been superseded by the new bookmark elements from XSL-FO 1.1.
diff --git a/content/fop/2.0/embedding.mdtext b/content/fop/2.0/embedding.mdtext
index fe7ff4e..1047ca5 100644
--- a/content/fop/2.0/embedding.mdtext
+++ b/content/fop/2.0/embedding.mdtext
@@ -354,19 +354,19 @@
### ExampleFO2PDF.java { #ExampleFO2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
### ExampleXML2FO.java { #ExampleXML2FO}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
### ExampleXML2PDF.java { #ExampleXML2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
@@ -374,7 +374,7 @@
### ExampleObj2XML.java { #ExampleObj2XML}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
@@ -386,17 +386,17 @@
### ExampleObj2PDF.java { #ExampleObj2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
### ExampleDOM2PDF.java { #ExampleDOM2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
### ExampleSVG2PDF.java (PDF Transcoder example) { #ExampleSVG2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
### ExampleConcat.java (IF Concatenation example) { #ExampleConcat}
diff --git a/content/fop/2.0/events.mdtext b/content/fop/2.0/events.mdtext
index 32cbabb..1c94f64 100644
--- a/content/fop/2.0/events.mdtext
+++ b/content/fop/2.0/events.mdtext
@@ -26,7 +26,7 @@
The `EventFormatter` class can be used to translate the events into human-readable, localized messages.
-A full example of what is shown here can be found in the `examples/embedding/java/embedding/events` directory in the FOP distribution. The example can also be accessed [via the web](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/events/).
+A full example of what is shown here can be found in the `examples/embedding/java/embedding/events` directory in the FOP distribution. The example can also be accessed [via the web](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/events/).
### Writing an EventListener { #write-listener}
diff --git a/content/fop/2.0/intermediate.mdtext b/content/fop/2.0/intermediate.mdtext
index ec65dd0..0c9befd 100644
--- a/content/fop/2.0/intermediate.mdtext
+++ b/content/fop/2.0/intermediate.mdtext
@@ -50,7 +50,7 @@
However, there is an important detail to consider: The various Renderers don't all use the same font sources. To be able to create the right area tree for the ultimate output format, you need to create the area tree XML file using the right font setup. This is achieved by telling the XMLRenderer to mimic another renderer. This is done by calling the XMLRenderer's mimicRenderer() method with an instance of the ultimate target renderer as the single parameter. This has a consequence: An area tree XML file rendered with the Java2DRenderer may not look as expected when it was actually generated for the PDF renderer. For renderers that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the area tree XML format file is the first step.
-The second step is to reparse the file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the area tree XML file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the area tree XML processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
+The second step is to reparse the file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the area tree XML file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the area tree XML processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the area tree XML format looks like this:
@@ -86,7 +86,7 @@
### Concatenating Documents { #concat}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/atxml/ExampleConcat.java) example shows you can easily parse multiple area tree files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/atxml/ExampleConcat.java) example shows you can easily parse multiple area tree files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
### Modifying Documents { #modifying}
@@ -111,7 +111,7 @@
As with the AT XML, there is an important detail to consider: The various output implementations don't all use the same font sources. To be able to create the right IF for the ultimate output file, you need to create the IF file using the right font setup. This is achieved by telling the IFRenderer (responsible for converting the area tree into calls to the IFDocumentHandler and IFPainter interfaces) to mimic another renderer. This is done by calling the IFSerializer's mimicDocumentHandler() method with an instance of the ultimate target document handler as the single parameter. This has a consequence: An IF file rendered with the Java2DDocumentHandler may not look as expected when it was actually generated for the PDF implementation. For implementations that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the Intermediate Format file is the first step.
-The second step is to reparse the file using the **IFParser** which is found in the org.apache.fop.render.intermediate package. The IFParser simply takes an IFDocumentHandler instance against which it generates the appropriate calls. The IFParser is implemented as a SAX ContentHandler so you're free to choose the method for post-processing the IF file(s). You can use XSLT or write SAX- or DOM-based code to manipulate the contents. You can find examples for the Intermediate Format processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
+The second step is to reparse the file using the **IFParser** which is found in the org.apache.fop.render.intermediate package. The IFParser simply takes an IFDocumentHandler instance against which it generates the appropriate calls. The IFParser is implemented as a SAX ContentHandler so you're free to choose the method for post-processing the IF file(s). You can use XSLT or write SAX- or DOM-based code to manipulate the contents. You can find examples for the Intermediate Format processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the intermediate format looks like this:
@@ -150,7 +150,7 @@
### Concatenating Documents { #concat-if}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly (without the intermediate step). As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple intermediate files in a row and use the IFConcatenator class to concatenate page sequences from multiple source files to a single output file. This particular example does the concatenation on the level of the IFDocumentHandler interface. You could also do this in XSLT or using SAX on the XML level. Whatever suits your process best.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly (without the intermediate step). As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple intermediate files in a row and use the IFConcatenator class to concatenate page sequences from multiple source files to a single output file. This particular example does the concatenation on the level of the IFDocumentHandler interface. You could also do this in XSLT or using SAX on the XML level. Whatever suits your process best.
### Modifying Documents { #modifying-if}
diff --git a/content/fop/2.0/upgrading.mdtext b/content/fop/2.0/upgrading.mdtext
index 6178809..1c92cb3 100644
--- a/content/fop/2.0/upgrading.mdtext
+++ b/content/fop/2.0/upgrading.mdtext
@@ -104,7 +104,7 @@
- As stated above, empty table cells `<fo:table-cell></fo:table-cell>` are not allowed by the specification. The same applies to empty `fo:static-content` and `fo:block-container` elements, for example.
-- Version 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic`) or `instream-foreign-object` objects. If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the correct behaviour.
+- Version 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic`) or `instream-foreign-object` objects. If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the correct behaviour.
- The `fox:outline` extension is not implemented in the current version: it has been superseded by the bookmark elements from XSL-FO 1.1.
diff --git a/content/fop/2.1/embedding.mdtext b/content/fop/2.1/embedding.mdtext
index fe7ff4e..1047ca5 100644
--- a/content/fop/2.1/embedding.mdtext
+++ b/content/fop/2.1/embedding.mdtext
@@ -354,19 +354,19 @@
### ExampleFO2PDF.java { #ExampleFO2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
### ExampleXML2FO.java { #ExampleXML2FO}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
### ExampleXML2PDF.java { #ExampleXML2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
@@ -374,7 +374,7 @@
### ExampleObj2XML.java { #ExampleObj2XML}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
@@ -386,17 +386,17 @@
### ExampleObj2PDF.java { #ExampleObj2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
### ExampleDOM2PDF.java { #ExampleDOM2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
### ExampleSVG2PDF.java (PDF Transcoder example) { #ExampleSVG2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
### ExampleConcat.java (IF Concatenation example) { #ExampleConcat}
diff --git a/content/fop/2.1/events.mdtext b/content/fop/2.1/events.mdtext
index 32cbabb..1c94f64 100644
--- a/content/fop/2.1/events.mdtext
+++ b/content/fop/2.1/events.mdtext
@@ -26,7 +26,7 @@
The `EventFormatter` class can be used to translate the events into human-readable, localized messages.
-A full example of what is shown here can be found in the `examples/embedding/java/embedding/events` directory in the FOP distribution. The example can also be accessed [via the web](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/events/).
+A full example of what is shown here can be found in the `examples/embedding/java/embedding/events` directory in the FOP distribution. The example can also be accessed [via the web](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/events/).
### Writing an EventListener { #write-listener}
diff --git a/content/fop/2.1/intermediate.mdtext b/content/fop/2.1/intermediate.mdtext
index ec65dd0..0c9befd 100644
--- a/content/fop/2.1/intermediate.mdtext
+++ b/content/fop/2.1/intermediate.mdtext
@@ -50,7 +50,7 @@
However, there is an important detail to consider: The various Renderers don't all use the same font sources. To be able to create the right area tree for the ultimate output format, you need to create the area tree XML file using the right font setup. This is achieved by telling the XMLRenderer to mimic another renderer. This is done by calling the XMLRenderer's mimicRenderer() method with an instance of the ultimate target renderer as the single parameter. This has a consequence: An area tree XML file rendered with the Java2DRenderer may not look as expected when it was actually generated for the PDF renderer. For renderers that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the area tree XML format file is the first step.
-The second step is to reparse the file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the area tree XML file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the area tree XML processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
+The second step is to reparse the file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the area tree XML file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the area tree XML processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the area tree XML format looks like this:
@@ -86,7 +86,7 @@
### Concatenating Documents { #concat}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/atxml/ExampleConcat.java) example shows you can easily parse multiple area tree files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/atxml/ExampleConcat.java) example shows you can easily parse multiple area tree files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
### Modifying Documents { #modifying}
@@ -111,7 +111,7 @@
As with the AT XML, there is an important detail to consider: The various output implementations don't all use the same font sources. To be able to create the right IF for the ultimate output file, you need to create the IF file using the right font setup. This is achieved by telling the IFRenderer (responsible for converting the area tree into calls to the IFDocumentHandler and IFPainter interfaces) to mimic another renderer. This is done by calling the IFSerializer's mimicDocumentHandler() method with an instance of the ultimate target document handler as the single parameter. This has a consequence: An IF file rendered with the Java2DDocumentHandler may not look as expected when it was actually generated for the PDF implementation. For implementations that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the Intermediate Format file is the first step.
-The second step is to reparse the file using the **IFParser** which is found in the org.apache.fop.render.intermediate package. The IFParser simply takes an IFDocumentHandler instance against which it generates the appropriate calls. The IFParser is implemented as a SAX ContentHandler so you're free to choose the method for post-processing the IF file(s). You can use XSLT or write SAX- or DOM-based code to manipulate the contents. You can find examples for the Intermediate Format processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
+The second step is to reparse the file using the **IFParser** which is found in the org.apache.fop.render.intermediate package. The IFParser simply takes an IFDocumentHandler instance against which it generates the appropriate calls. The IFParser is implemented as a SAX ContentHandler so you're free to choose the method for post-processing the IF file(s). You can use XSLT or write SAX- or DOM-based code to manipulate the contents. You can find examples for the Intermediate Format processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the intermediate format looks like this:
@@ -150,7 +150,7 @@
### Concatenating Documents { #concat-if}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly (without the intermediate step). As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple intermediate files in a row and use the IFConcatenator class to concatenate page sequences from multiple source files to a single output file. This particular example does the concatenation on the level of the IFDocumentHandler interface. You could also do this in XSLT or using SAX on the XML level. Whatever suits your process best.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly (without the intermediate step). As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple intermediate files in a row and use the IFConcatenator class to concatenate page sequences from multiple source files to a single output file. This particular example does the concatenation on the level of the IFDocumentHandler interface. You could also do this in XSLT or using SAX on the XML level. Whatever suits your process best.
### Modifying Documents { #modifying-if}
diff --git a/content/fop/2.1/upgrading.mdtext b/content/fop/2.1/upgrading.mdtext
index 5adcc5e..f646fbe 100644
--- a/content/fop/2.1/upgrading.mdtext
+++ b/content/fop/2.1/upgrading.mdtext
@@ -104,7 +104,7 @@
- As stated above, empty table cells `<fo:table-cell></fo:table-cell>` are not allowed by the specification. The same applies to empty `fo:static-content` and `fo:block-container` elements, for example.
-- Version 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic`) or `instream-foreign-object` objects. If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the correct behaviour.
+- Version 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic`) or `instream-foreign-object` objects. If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the correct behaviour.
- The `fox:outline` extension is not implemented in the current version: it has been superseded by the bookmark elements from XSL-FO 1.1.
diff --git a/content/fop/trunk/embedding.mdtext b/content/fop/trunk/embedding.mdtext
index fe7ff4e..1047ca5 100644
--- a/content/fop/trunk/embedding.mdtext
+++ b/content/fop/trunk/embedding.mdtext
@@ -354,19 +354,19 @@
### ExampleFO2PDF.java { #ExampleFO2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleFO2PDF.java?view=markup) demonstrates the basic usage pattern to transform an XSL-FO file to PDF using FOP.
### ExampleXML2FO.java { #ExampleXML2FO}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2FO.java?view=markup) has nothing to do with FOP. It is there to show you how an XML file can be converted to XSL-FO using XSLT. The JAXP API is used to do the transformation. Make sure you've got a JAXP-compliant XSLT processor in your classpath (ex. [Xalan](http://xml.apache.org/xalan-j)).
### ExampleXML2PDF.java { #ExampleXML2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleXML2PDF.java?view=markup) demonstrates how you can convert an arbitrary XML file to PDF using XSLT and XSL-FO/FOP. It is a combination of the first two examples above. The example uses JAXP to transform the XML file to XSL-FO and FOP to transform the XSL-FO to PDF.
@@ -374,7 +374,7 @@
### ExampleObj2XML.java { #ExampleObj2XML}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2XML.java?view=markup) is a preparatory example for the next one. It's an example that shows how an arbitrary Java object can be converted to XML. It's an often needed task to do this. Often people create a DOM tree from a Java object and use that. This is pretty straightforward. The example here, however, shows how to do this using SAX, which will probably be faster and not even more complicated once you know how this works.
@@ -386,17 +386,17 @@
### ExampleObj2PDF.java { #ExampleObj2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleObj2PDF.java?view=markup) combines the previous and the third to demonstrate how you can transform a Java object to a PDF directly in one smooth run by generating SAX events from the Java object that get fed to an XSL transformation. The result of the transformation is then converted to PDF using FOP as before.
### ExampleDOM2PDF.java { #ExampleDOM2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleDOM2PDF.java?view=markup) has FOP use a DOMSource instead of a StreamSource in order to use a DOM tree as input for an XSL transformation.
### ExampleSVG2PDF.java (PDF Transcoder example) { #ExampleSVG2PDF}
-This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
+This [example](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/ExampleSVG2PDF.java?view=markup) shows the usage of the PDF Transcoder, a sub-application within FOP. It is used to generate a PDF document from an SVG file.
### ExampleConcat.java (IF Concatenation example) { #ExampleConcat}
diff --git a/content/fop/trunk/events.mdtext b/content/fop/trunk/events.mdtext
index 32cbabb..1c94f64 100644
--- a/content/fop/trunk/events.mdtext
+++ b/content/fop/trunk/events.mdtext
@@ -26,7 +26,7 @@
The `EventFormatter` class can be used to translate the events into human-readable, localized messages.
-A full example of what is shown here can be found in the `examples/embedding/java/embedding/events` directory in the FOP distribution. The example can also be accessed [via the web](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/events/).
+A full example of what is shown here can be found in the `examples/embedding/java/embedding/events` directory in the FOP distribution. The example can also be accessed [via the web](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/events/).
### Writing an EventListener { #write-listener}
diff --git a/content/fop/trunk/intermediate.mdtext b/content/fop/trunk/intermediate.mdtext
index ec65dd0..0c9befd 100644
--- a/content/fop/trunk/intermediate.mdtext
+++ b/content/fop/trunk/intermediate.mdtext
@@ -50,7 +50,7 @@
However, there is an important detail to consider: The various Renderers don't all use the same font sources. To be able to create the right area tree for the ultimate output format, you need to create the area tree XML file using the right font setup. This is achieved by telling the XMLRenderer to mimic another renderer. This is done by calling the XMLRenderer's mimicRenderer() method with an instance of the ultimate target renderer as the single parameter. This has a consequence: An area tree XML file rendered with the Java2DRenderer may not look as expected when it was actually generated for the PDF renderer. For renderers that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the area tree XML format file is the first step.
-The second step is to reparse the file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the area tree XML file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the area tree XML processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
+The second step is to reparse the file using the **AreaTreeParser** which is found in the org.apache.fop.area package. The pages retrieved from the area tree XML file are added to an AreaTreeModel instance from where they are normally rendered using one of the available Renderer implementations. You can find examples for the area tree XML processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the area tree XML format looks like this:
@@ -86,7 +86,7 @@
### Concatenating Documents { #concat}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/atxml/ExampleConcat.java) example shows you can easily parse multiple area tree files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly. As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/atxml/ExampleConcat.java) example shows you can easily parse multiple area tree files in a row and add the parsed pages to the same AreaTreeModel instance which essentially concatenates all the input document to one single output document.
### Modifying Documents { #modifying}
@@ -111,7 +111,7 @@
As with the AT XML, there is an important detail to consider: The various output implementations don't all use the same font sources. To be able to create the right IF for the ultimate output file, you need to create the IF file using the right font setup. This is achieved by telling the IFRenderer (responsible for converting the area tree into calls to the IFDocumentHandler and IFPainter interfaces) to mimic another renderer. This is done by calling the IFSerializer's mimicDocumentHandler() method with an instance of the ultimate target document handler as the single parameter. This has a consequence: An IF file rendered with the Java2DDocumentHandler may not look as expected when it was actually generated for the PDF implementation. For implementations that use the same font setup, this restriction does not apply (PDF and PS, for example). Generating the Intermediate Format file is the first step.
-The second step is to reparse the file using the **IFParser** which is found in the org.apache.fop.render.intermediate package. The IFParser simply takes an IFDocumentHandler instance against which it generates the appropriate calls. The IFParser is implemented as a SAX ContentHandler so you're free to choose the method for post-processing the IF file(s). You can use XSLT or write SAX- or DOM-based code to manipulate the contents. You can find examples for the Intermediate Format processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
+The second step is to reparse the file using the **IFParser** which is found in the org.apache.fop.render.intermediate package. The IFParser simply takes an IFDocumentHandler instance against which it generates the appropriate calls. The IFParser is implemented as a SAX ContentHandler so you're free to choose the method for post-processing the IF file(s). You can use XSLT or write SAX- or DOM-based code to manipulate the contents. You can find examples for the Intermediate Format processing in the [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the intermediate format looks like this:
@@ -150,7 +150,7 @@
### Concatenating Documents { #concat-if}
-This initial example is obviously not very useful. It would be faster to create the PDF file directly (without the intermediate step). As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple intermediate files in a row and use the IFConcatenator class to concatenate page sequences from multiple source files to a single output file. This particular example does the concatenation on the level of the IFDocumentHandler interface. You could also do this in XSLT or using SAX on the XML level. Whatever suits your process best.
+This initial example is obviously not very useful. It would be faster to create the PDF file directly (without the intermediate step). As the [ExampleConcat.java](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/intermediate/ExampleConcat.java) example shows you can easily parse multiple intermediate files in a row and use the IFConcatenator class to concatenate page sequences from multiple source files to a single output file. This particular example does the concatenation on the level of the IFDocumentHandler interface. You could also do this in XSLT or using SAX on the XML level. Whatever suits your process best.
### Modifying Documents { #modifying-if}
diff --git a/content/fop/trunk/upgrading.mdtext b/content/fop/trunk/upgrading.mdtext
index 5adcc5e..f646fbe 100644
--- a/content/fop/trunk/upgrading.mdtext
+++ b/content/fop/trunk/upgrading.mdtext
@@ -104,7 +104,7 @@
- As stated above, empty table cells `<fo:table-cell></fo:table-cell>` are not allowed by the specification. The same applies to empty `fo:static-content` and `fo:block-container` elements, for example.
-- Version 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic`) or `instream-foreign-object` objects. If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the correct behaviour.
+- Version 0.20.5 is not XSL-FO compliant with respect to sizing images (`external-graphic`) or `instream-foreign-object` objects. If images or SVGs are sized differently in your outputs with the new FOP version check [FOP-1073](https://issues.apache.org/jira/browse/FOP-1073) as it contains some hints on what to do. The file [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/fop/examples/fo/basic/images.fo?view=markup) has a number of good examples that show the correct behaviour.
- The `fox:outline` extension is not implemented in the current version: it has been superseded by the bookmark elements from XSL-FO 1.1.
