svn commit: r1750324 [2/2] - in /xmlgraphics/site/trunk/content/fop: 0.95/ 1.0/ 1.1/ 2.0/ 2.1/ trunk/

[ss...@apache.org]

Modified: xmlgraphics/site/trunk/content/fop/trunk/events.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/trunk/events.mdtext?rev=1750324&r1=1750323&r2=1750324&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/trunk/events.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/trunk/events.mdtext Mon Jun 27 12:01:39 2016
@@ -26,7 +26,7 @@ The event subsystem is located in the `o
 
 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}
 

Modified: xmlgraphics/site/trunk/content/fop/trunk/intermediate.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/trunk/intermediate.mdtext?rev=1750324&r1=1750323&r2=1750324&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/trunk/intermediate.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/trunk/intermediate.mdtext Mon Jun 27 12:01:39 2016
@@ -50,7 +50,7 @@ As already mentioned, the area tree XML
 
 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 @@ The area tree XML format can also be use
 
 ### 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 @@ The IFSerializer is an implementation of
 
 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 @@ This example simply reads an intermediat
 
 ### 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}
 

Modified: xmlgraphics/site/trunk/content/fop/trunk/upgrading.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/trunk/upgrading.mdtext?rev=1750324&r1=1750323&r2=1750324&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/trunk/upgrading.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/trunk/upgrading.mdtext Mon Jun 27 12:01:39 2016
@@ -104,7 +104,7 @@ When you use your existing FO files or X
 
 - 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.
 



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: commits-help@xmlgraphics.apache.org