xmlgraphics-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r840265 - in /websites/staging/xmlgraphics/trunk/content: ./ commons/ fop/ fop/0.95/ fop/1.0/ fop/1.1/ fop/dev/ fop/trunk/
Date Sat, 01 Dec 2012 06:44:29 GMT
Author: buildbot
Date: Sat Dec  1 06:44:27 2012
New Revision: 840265

Log:
Staging update by buildbot for xmlgraphics

Modified:
    websites/staging/xmlgraphics/trunk/content/   (props changed)
    websites/staging/xmlgraphics/trunk/content/commons/changes.html
    websites/staging/xmlgraphics/trunk/content/commons/index.html
    websites/staging/xmlgraphics/trunk/content/fop/0.95/changes_0.95.html
    websites/staging/xmlgraphics/trunk/content/fop/0.95/changes_0.95beta.html
    websites/staging/xmlgraphics/trunk/content/fop/0.95/intermediate.html
    websites/staging/xmlgraphics/trunk/content/fop/0.95/upgrading.html
    websites/staging/xmlgraphics/trunk/content/fop/1.0/changes_1.0.html
    websites/staging/xmlgraphics/trunk/content/fop/1.0/intermediate.html
    websites/staging/xmlgraphics/trunk/content/fop/1.0/upgrading.html
    websites/staging/xmlgraphics/trunk/content/fop/1.1/changes_1.1.html
    websites/staging/xmlgraphics/trunk/content/fop/1.1/complexscripts.html
    websites/staging/xmlgraphics/trunk/content/fop/1.1/intermediate.html
    websites/staging/xmlgraphics/trunk/content/fop/1.1/upgrading.html
    websites/staging/xmlgraphics/trunk/content/fop/changes.html
    websites/staging/xmlgraphics/trunk/content/fop/dev/testing.html
    websites/staging/xmlgraphics/trunk/content/fop/trunk/complexscripts.html
    websites/staging/xmlgraphics/trunk/content/fop/trunk/intermediate.html
    websites/staging/xmlgraphics/trunk/content/fop/trunk/upgrading.html

Propchange: websites/staging/xmlgraphics/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sat Dec  1 06:44:27 2012
@@ -1 +1 @@
-1415921
+1415927

Modified: websites/staging/xmlgraphics/trunk/content/commons/changes.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/commons/changes.html (original)
+++ websites/staging/xmlgraphics/trunk/content/commons/changes.html Sat Dec  1 06:44:27 2012
@@ -136,7 +136,7 @@ $(document).ready(function () {
         </div>
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/commons/">Commons</a></div> -->
       	<div class="section-content"><h1 id="history-of-changes">History of Changes</h1>
-<p><a href="changes.rss"></a> </p>
+<p><a href="changes.rss">changes.rss</a> </p>
 <h2 id="introduction-and-explanation-of-symbols-wzxhzdk0wzxhzdk1">Introduction and explanation of symbols <a id="introduction"></a></h2>
 <p>Changes are sorted by "type" and then chronologically with the most recent at the top. These symbols denote the various action types:<icon alt="add" src="images/add.jpg"></icon>=add,<icon alt="fix" src="images/fix.jpg"></icon>=fix,<icon alt="remove" src="images/remove.jpg"></icon>=remove,<icon alt="update" src="images/update.jpg"></icon>=update</p>
 <h2 id="version-trunk-na-wzxhzdk10wzxhzdk11">Version Trunk (n/a) <a id="version_Trunk"></a></h2>

Modified: websites/staging/xmlgraphics/trunk/content/commons/index.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/commons/index.html (original)
+++ websites/staging/xmlgraphics/trunk/content/commons/index.html Sat Dec  1 06:44:27 2012
@@ -199,7 +199,7 @@ $(document).ready(function () {
 </tbody>
 </table>
 <h2 id="news-wzxhzdk8wzxhzdk9">News <a id="News"></a></h2>
-<p>RSS Feed: <a href="subproject-news-feed.rss"></a> </p>
+<p>RSS Feed: <a href="subproject-news-feed.rss">subproject-news-feed.rss</a> </p>
 <h3 id="7-jul-2010-version-14-released-wzxhzdk10wzxhzdk11">7 Jul 2010: Version 1.4 Released <a id="news-2010-07-07"></a></h3>
 <p><item date="2010-07-07" title="Version 1.4 Released">
 This release adds the option to generate smaller PostScript files, support for the AdobeStandardCyrillic encoding, RefinedImageFlavor, TexturePaint support for PSGraphics2D (PostScript tiling patterns), improvements to the XMP framework, optimization for PostScript state handling in (E)PSDocumentGraphics2D, and more. In addition it contains a number of bug fixes. For details, please see the <a href="changes.html#version_1.4">Changes</a> page.</p>

Modified: websites/staging/xmlgraphics/trunk/content/fop/0.95/changes_0.95.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/0.95/changes_0.95.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/0.95/changes_0.95.html Sat Dec  1 06:44:27 2012
@@ -342,7 +342,7 @@ $(document).ready(function () {
         </div>
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/0.95/">0.95</a></div> -->
       	<div class="section-content"><h1 id="history-of-changes-095">History of Changes 0.95</h1>
-<p><a href="changes_0.95.rss"></a> </p>
+<p><a href="changes_0.95.rss">changes_0.95.rss</a> </p>
 <h2 id="introduction-and-explanation-of-symbols-wzxhzdk0wzxhzdk1">Introduction and explanation of symbols <a id="introduction"></a></h2>
 <p>Changes are sorted by "type" and then chronologically with the most recent at the top. These symbols denote the various action types:<icon alt="add" src="../images/add.jpg"></icon>=add,<icon alt="fix" src="../images/fix.jpg"></icon>=fix,<icon alt="remove" src="../images/remove.jpg"></icon>=remove,<icon alt="update" src="../images/update.jpg"></icon>=update</p>
 <h2 id="version-095-05-august-2008-wzxhzdk10wzxhzdk11">Version 0.95 (05 August 2008) <a id="version_0.95"></a></h2>

Modified: websites/staging/xmlgraphics/trunk/content/fop/0.95/changes_0.95beta.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/0.95/changes_0.95beta.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/0.95/changes_0.95beta.html Sat Dec  1 06:44:27 2012
@@ -342,7 +342,7 @@ $(document).ready(function () {
         </div>
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/0.95/">0.95</a></div> -->
       	<div class="section-content"><h1 id="history-of-changes-095beta">History of Changes 0.95beta</h1>
-<p><a href="changes_0.95beta.rss"></a> </p>
+<p><a href="changes_0.95beta.rss">changes_0.95beta.rss</a> </p>
 <h2 id="introduction-and-explanation-of-symbols-wzxhzdk0wzxhzdk1">Introduction and explanation of symbols <a id="introduction"></a></h2>
 <p>Changes are sorted by "type" and then chronologically with the most recent at the top. These symbols denote the various action types:<icon alt="add" src="../images/add.jpg"></icon>=add,<icon alt="fix" src="../images/fix.jpg"></icon>=fix,<icon alt="remove" src="../images/remove.jpg"></icon>=remove,<icon alt="update" src="../images/update.jpg"></icon>=update</p>
 <h2 id="version-095beta-26-march-2008-wzxhzdk10wzxhzdk11">Version 0.95beta (26 March 2008) <a id="version_0.95beta"></a></h2>

Modified: websites/staging/xmlgraphics/trunk/content/fop/0.95/intermediate.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/0.95/intermediate.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/0.95/intermediate.html Sat Dec  1 06:44:27 2012
@@ -349,7 +349,7 @@ Please note that the intermediate format
 <p>The intermediate format can be used to generate intermediate documents that are modified before they are finally rendered to their ultimate output format. Modifications include adjusting and changing trait values, adding or modifying area objects, inserting prefabricated pages, overlays, imposition (n-up, rotation, scaling etc.). Multiple IF files can be combined to a single output file.</p>
 <h2 id="usage-of-the-intermediate-format-wzxhzdk7wzxhzdk8">Usage of the Intermediate Format <a id="usage"></a></h2>
 <p>As already mentioned, the IF is generated by using the <strong>XMLRenderer</strong> (MIME type: <strong>application/X-fop-areatree</strong> ). 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 inte
 rmediate format file is the first step.</p>
-<p>The second step is to reparse the IF file using the <strong>AreaTreeParser</strong> 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 <a href="http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/"></a> directory in the FOP distribution</p>
+<p>The second step is to reparse the IF file using the <strong>AreaTreeParser</strong> 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 <a href="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/</a> directory in the FOP distribution</p>
 <p>The basic pattern to parse the IF format looks like this:</p>
 <p>FopFactory fopFactory = FopFactory.newInstance();    <br />
 </p>

Modified: websites/staging/xmlgraphics/trunk/content/fop/0.95/upgrading.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/0.95/upgrading.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/0.95/upgrading.html Sat Dec  1 06:44:27 2012
@@ -382,7 +382,7 @@ While FOP 0.20.5 allowed you to have emp
 <p>As stated above empty table cells <code>&lt;fo:table-cell&gt;&lt;/fo:table-cell&gt;</code> are not allowed by the specification. The same applies to empty <code>static-content</code> and <code>block-container</code> elements, for example.</p>
 </li>
 <li>
-<p>0.20.5 is not XSL-FO compliant with respect to sizing images ( <code>external-graphic</code> ) or <code>instream-foreign-object</code> objects. If images or SVGs are sized differently in your outputs with the new FOP version check <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=37136">Bug 37136</a> as it contains some hints on what to do. The file <a href="http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup"></a> has a number of good examples that show the new, more correct behaviour.</p>
+<p>0.20.5 is not XSL-FO compliant with respect to sizing images ( <code>external-graphic</code> ) or <code>instream-foreign-object</code> objects. If images or SVGs are sized differently in your outputs with the new FOP version check <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=37136">Bug 37136</a> as it contains some hints on what to do. The file <a href="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</a> has a number of good examples that show the new, more correct behaviour.</p>
 </li>
 <li>
 <p>The <code>fox:outline</code> 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.</p>

Modified: websites/staging/xmlgraphics/trunk/content/fop/1.0/changes_1.0.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/1.0/changes_1.0.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/1.0/changes_1.0.html Sat Dec  1 06:44:27 2012
@@ -342,7 +342,7 @@ $(document).ready(function () {
         </div>
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/1.0/">1.0</a></div> -->
       	<div class="section-content"><h1 id="history-of-changes-10">History of Changes 1.0</h1>
-<p><a href="changes_1.0.rss"></a> </p>
+<p><a href="changes_1.0.rss">changes_1.0.rss</a> </p>
 <h2 id="introduction-and-explanation-of-symbols-wzxhzdk0wzxhzdk1">Introduction and explanation of symbols <a id="introduction"></a></h2>
 <p>Changes are sorted by "type" and then chronologically with the most recent at the top. These symbols denote the various action types:<icon alt="add" src="../images/add.jpg"></icon>=add,<icon alt="fix" src="../images/fix.jpg"></icon>=fix,<icon alt="remove" src="../images/remove.jpg"></icon>=remove,<icon alt="update" src="../images/update.jpg"></icon>=update</p>
 <h2 id="version-10-21-july-2010-wzxhzdk10wzxhzdk11">Version 1.0 (21 July 2010) <a id="version_1.0"></a></h2>

Modified: websites/staging/xmlgraphics/trunk/content/fop/1.0/intermediate.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/1.0/intermediate.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/1.0/intermediate.html Sat Dec  1 06:44:27 2012
@@ -386,7 +386,7 @@ Please note that the intermediate format
 <h1 id="usage-of-the-area-tree-xml-format-at-xml-wzxhzdk16wzxhzdk17">Usage of the Area Tree XML format (AT XML) <a id="usage"></a></h1>
 <p>As already mentioned, the area tree XML format is generated by using the <strong>XMLRenderer</strong> (MIME type: <strong>application/X-fop-areatree</strong> ). 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.</p>
 <p>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.</p>
-<p>The second step is to reparse the file using the <strong>AreaTreeParser</strong> 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 <a href="http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/"></a> directory in the FOP distribution.</p>
+<p>The second step is to reparse the file using the <strong>AreaTreeParser</strong> 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 <a href="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/</a> directory in the FOP distribution.</p>
 <p>The basic pattern to parse the area tree XML format looks like this:</p>
 <p>FopFactory fopFactory = FopFactory.newInstance();    <br />
 </p>
@@ -435,7 +435,7 @@ The area tree XML format is sensitive to
 </li>
 </ul>
 <p>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.</p>
-<p>The second step is to reparse the file using the <strong>IFParser</strong> 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 <a href="http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/"></a> directory in the FOP distribution.</p>
+<p>The second step is to reparse the file using the <strong>IFParser</strong> 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 <a href="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/</a> directory in the FOP distribution.</p>
 <p>The basic pattern to parse the intermediate format looks like this:</p>
 <p>FopFactory fopFactory = FopFactory.newInstance();</p>
 <p>// Setup output

Modified: websites/staging/xmlgraphics/trunk/content/fop/1.0/upgrading.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/1.0/upgrading.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/1.0/upgrading.html Sat Dec  1 06:44:27 2012
@@ -385,7 +385,7 @@ While FOP 0.20.5 allowed you to have emp
 <p>As stated above empty table cells <code>&lt;fo:table-cell&gt;&lt;/fo:table-cell&gt;</code> are not allowed by the specification. The same applies to empty <code>static-content</code> and <code>block-container</code> elements, for example.</p>
 </li>
 <li>
-<p>0.20.5 is not XSL-FO compliant with respect to sizing images ( <code>external-graphic</code> ) or <code>instream-foreign-object</code> objects. If images or SVGs are sized differently in your outputs with the new FOP version check <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=37136">Bug 37136</a> as it contains some hints on what to do. The file <a href="http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup"></a> has a number of good examples that show the new, more correct behaviour.</p>
+<p>0.20.5 is not XSL-FO compliant with respect to sizing images ( <code>external-graphic</code> ) or <code>instream-foreign-object</code> objects. If images or SVGs are sized differently in your outputs with the new FOP version check <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=37136">Bug 37136</a> as it contains some hints on what to do. The file <a href="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</a> has a number of good examples that show the new, more correct behaviour.</p>
 </li>
 <li>
 <p>The <code>fox:outline</code> extension is not implemented in this version anymore. It has been superseded by the new bookmark elements from XSL-FO 1.1.</p>

Modified: websites/staging/xmlgraphics/trunk/content/fop/1.1/changes_1.1.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/1.1/changes_1.1.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/1.1/changes_1.1.html Sat Dec  1 06:44:27 2012
@@ -342,7 +342,7 @@ $(document).ready(function () {
         </div>
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a>&nbsp;&raquo&nbsp;<a href="/fop/1.1/">1.1</a></div> -->
       	<div class="section-content"><h1 id="history-of-changes-11">History of Changes 1.1</h1>
-<p><a href="changes_1.1.rss"></a> </p>
+<p><a href="changes_1.1.rss">changes_1.1.rss</a> </p>
 <h2 id="introduction-and-explanation-of-symbols-wzxhzdk0wzxhzdk1">Introduction and explanation of symbols <a id="introduction"></a></h2>
 <p>Changes are sorted by "type" and then chronologically with the most recent at the top. These symbols denote the various action types:<icon alt="add" src="../images/add.jpg"></icon>=add,<icon alt="fix" src="../images/fix.jpg"></icon>=fix,<icon alt="remove" src="../images/remove.jpg"></icon>=remove,<icon alt="update" src="../images/update.jpg"></icon>=update</p>
 <h2 id="version-11-20-october-2012-wzxhzdk10wzxhzdk11">Version 1.1 (20 October 2012) <a id="version_1.1"></a></h2>

Modified: websites/staging/xmlgraphics/trunk/content/fop/1.1/complexscripts.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/1.1/complexscripts.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/1.1/complexscripts.html Sat Dec  1 06:44:27 2012
@@ -380,19 +380,19 @@ A document author need not make explicit
 <p>In most circumstances, XSL-FO content does not need to change in order to make use of complex scripts features; however, in certain contexts, fully automatic processing is not sufficient. In these cases, an author may make use of the following XSL-FO constructs:</p>
 <ul>
 <li>
-<p>The <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#script"></a> property.</p>
+<p>The <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#script">http://www.w3.org/TR/2006/REC-xsl11-20061205/#script</a> property.</p>
 </li>
 <li>
-<p>The <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#language"></a> property.</p>
+<p>The <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#language">http://www.w3.org/TR/2006/REC-xsl11-20061205/#language</a> property.</p>
 </li>
 <li>
-<p>The <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#writing-mode"></a> property.</p>
+<p>The <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#writing-mode">http://www.w3.org/TR/2006/REC-xsl11-20061205/#writing-mode</a> property.</p>
 </li>
 <li>
-<p>The number to string conversion properties: <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#format"></a> , <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-separator"></a> , <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-size"></a> , <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#letter-value"></a> , and <code>fox:number-conversion-features</code> .</p>
+<p>The number to string conversion properties: <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#format">http://www.w3.org/TR/2006/REC-xsl11-20061205/#format</a> , <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-separator">http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-separator</a> , <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-size">http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-size</a> , <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#letter-value">http://www.w3.org/TR/2006/REC-xsl11-20061205/#letter-value</a> , and <code>fox:number-conversion-features</code> .</p>
 </li>
 <li>
-<p>The <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override"></a> element.</p>
+<p>The <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override">http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override</a> element.</p>
 </li>
 <li>
 <p>Explicit bidirectional control characters: U+200E LRM, U+200F RLM, U+202A LRE, U+202B RLE, U+202C PDF, U+202D LRO, U+202E RLO.</p>
@@ -407,7 +407,7 @@ A document author need not make explicit
 <p>In order to apply font specific complex script features, it is necessary to know the script that applies to the text undergoing layout processing. This script is determined using the following algorithm:</p>
 <ol>
 <li>
-<p>If the FO element that governs the text specifies a <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#script"></a> property and its value is not the empty string or <code>"auto"</code> , then that script is used.</p>
+<p>If the FO element that governs the text specifies a <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#script">http://www.w3.org/TR/2006/REC-xsl11-20061205/#script</a> property and its value is not the empty string or <code>"auto"</code> , then that script is used.</p>
 </li>
 <li>
 <p>Otherwise, the dominant script of the text is determined automatically by finding the script whose constituent characters appear most frequently in the text.</p>
@@ -646,7 +646,7 @@ A document author need not make explicit
 </tr>
 </tbody>
 </table>
-<p>Certain fonts that support complex script features can make use of language information in order for language specific processing rules to be applied. For example, a font designed for the Arabic script may support typographic variations according to whether the written language is Arabic, Farsi (Persian), Sindhi, Urdu, or another language written with the Arabic script. In order to apply these language specific features, the author may explicitly mark the text with a <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#language"></a> property.</p>
+<p>Certain fonts that support complex script features can make use of language information in order for language specific processing rules to be applied. For example, a font designed for the Arabic script may support typographic variations according to whether the written language is Arabic, Farsi (Persian), Sindhi, Urdu, or another language written with the Arabic script. In order to apply these language specific features, the author may explicitly mark the text with a <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#language">http://www.w3.org/TR/2006/REC-xsl11-20061205/#language</a> property.</p>
 <p>When specifying the <code>language</code> property, the value of the property must be either an <a href="http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes">ISO639-2 3-letter code</a> or an <a href="http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes">ISO639-1 2-letter code</a> . Comparison of language codes is performed in a case-insensitive manner, so it does not matter what case is used when specifying these codes in an XSL-FO document.</p>
 <h3 id="writing-mode-property-wzxhzdk16wzxhzdk17">Writing Mode Property <a id="writing_mode_property"></a></h3>
 <p>The <code>writing-mode</code> property is used to determine the axes and direction of the inline progression direction, the block progression direction, the column progression direction (in tables and flows), the shift direction, region placement, the resolution of writing-mode relative property values (such as start, end, before, after), and the default block (paragraph) bidirectionality level.</p>
@@ -689,7 +689,7 @@ A document author need not make explicit
 </ul>
 <p>Writing modes that employ a vertical inline progression direction are not yet supported.</p>
 <h3 id="bidi-override-element-wzxhzdk18wzxhzdk19">Bidi Override Element <a id="bidi_override_element"></a></h3>
-<p>The <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override"></a> element may be used to override default bidirectional processing behavior, including default embedding levels and default character directionality. In the absence of either this element or use of explicit <a href="#bidi_controls">Bidi Control Characters</a> , the default behavior prescribed by the <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override">Unicode Bidirectional Algorithm</a> applies.</p>
+<p>The <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override">http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override</a> element may be used to override default bidirectional processing behavior, including default embedding levels and default character directionality. In the absence of either this element or use of explicit <a href="#bidi_controls">Bidi Control Characters</a> , the default behavior prescribed by the <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override">Unicode Bidirectional Algorithm</a> applies.</p>
 <h3 id="bidi-control-characters-wzxhzdk20wzxhzdk21">Bidi Control Characters <a id="bidi_controls"></a></h3>
 <p>In addition to the use of the <a href="#bidi_override_element">Bidi Override Element</a> , an author may make use of the following explicit Unicode Bidi Control Characters:</p>
 <ul>

Modified: websites/staging/xmlgraphics/trunk/content/fop/1.1/intermediate.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/1.1/intermediate.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/1.1/intermediate.html Sat Dec  1 06:44:27 2012
@@ -386,7 +386,7 @@ Please note that the intermediate format
 <h1 id="usage-of-the-area-tree-xml-format-at-xml-wzxhzdk16wzxhzdk17">Usage of the Area Tree XML format (AT XML) <a id="usage"></a></h1>
 <p>As already mentioned, the area tree XML format is generated by using the <strong>XMLRenderer</strong> (MIME type: <strong>application/X-fop-areatree</strong> ). 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.</p>
 <p>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.</p>
-<p>The second step is to reparse the file using the <strong>AreaTreeParser</strong> 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 <a href="http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/"></a> directory in the FOP distribution.</p>
+<p>The second step is to reparse the file using the <strong>AreaTreeParser</strong> 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 <a href="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/</a> directory in the FOP distribution.</p>
 <p>The basic pattern to parse the area tree XML format looks like this:</p>
 <p>FopFactory fopFactory = FopFactory.newInstance();    <br />
 </p>
@@ -435,7 +435,7 @@ The area tree XML format is sensitive to
 </li>
 </ul>
 <p>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.</p>
-<p>The second step is to reparse the file using the <strong>IFParser</strong> 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 <a href="http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/"></a> directory in the FOP distribution.</p>
+<p>The second step is to reparse the file using the <strong>IFParser</strong> 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 <a href="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/</a> directory in the FOP distribution.</p>
 <p>The basic pattern to parse the intermediate format looks like this:</p>
 <p>FopFactory fopFactory = FopFactory.newInstance();</p>
 <p>// Setup output

Modified: websites/staging/xmlgraphics/trunk/content/fop/1.1/upgrading.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/1.1/upgrading.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/1.1/upgrading.html Sat Dec  1 06:44:27 2012
@@ -419,7 +419,7 @@ While FOP 0.20.5 allowed you to have emp
 <p>As stated above, empty table cells <code>&lt;fo:table-cell&gt;&lt;/fo:table-cell&gt;</code> are not allowed by the specification. The same applies to empty <code>fo:static-content</code> and <code>fo:block-container</code> elements, for example.</p>
 </li>
 <li>
-<p>Version 0.20.5 is not XSL-FO compliant with respect to sizing images ( <code>external-graphic</code> ) or <code>instream-foreign-object</code> objects. If images or SVGs are sized differently in your outputs with the new FOP version check <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=37136">Bug 37136</a> as it contains some hints on what to do. The file <a href="http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup"></a> has a number of good examples that show the correct behaviour.</p>
+<p>Version 0.20.5 is not XSL-FO compliant with respect to sizing images ( <code>external-graphic</code> ) or <code>instream-foreign-object</code> objects. If images or SVGs are sized differently in your outputs with the new FOP version check <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=37136">Bug 37136</a> as it contains some hints on what to do. The file <a href="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</a> has a number of good examples that show the correct behaviour.</p>
 </li>
 <li>
 <p>The <code>fox:outline</code> extension is not implemented in the current version: it has been superseded by the new bookmark elements from XSL-FO 1.1.</p>

Modified: websites/staging/xmlgraphics/trunk/content/fop/changes.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/changes.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/changes.html Sat Dec  1 06:44:27 2012
@@ -342,7 +342,7 @@ $(document).ready(function () {
         </div>
       	<!-- <div id="breadcrumb"><a href="/">Home</a>&nbsp;&raquo&nbsp;<a href="/fop/">Fop</a></div> -->
       	<div class="section-content"><h1 id="history-of-changes">History of Changes</h1>
-<p><a href="changes.rss"></a> </p>
+<p><a href="changes.rss">changes.rss</a> </p>
 <h2 id="introduction-and-explanation-of-symbols-wzxhzdk0wzxhzdk1">Introduction and explanation of symbols <a id="introduction"></a></h2>
 <p>Changes are sorted by "type" and then chronologically with the most recent at the top. These symbols denote the various action types:<icon alt="add" src="images/add.jpg"></icon>=add,<icon alt="fix" src="images/fix.jpg"></icon>=fix,<icon alt="remove" src="images/remove.jpg"></icon>=remove,<icon alt="update" src="images/update.jpg"></icon>=update</p>
 <h2 id="version-fop-trunk-tbd-wzxhzdk10wzxhzdk11">Version FOP Trunk (TBD) <a id="version_FOP Trunk"></a></h2>

Modified: websites/staging/xmlgraphics/trunk/content/fop/dev/testing.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/dev/testing.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/dev/testing.html Sat Dec  1 06:44:27 2012
@@ -356,7 +356,7 @@ $(document).ready(function () {
 <h2 id="basicapi-testing-wzxhzdk6wzxhzdk7">Basic/API Testing <a id="basic"></a></h2>
 <p>There is a group of basic API tests that are included in the build process. For these tests to occur, JUnit must be available to Ant (simply copy junit.jar into Ant's lib directory). The build will then report error(s) if the high-level APIs for Driver and the Transcoders fail. The tests do not check the output, but only ensure that something is generated and without exceptions.</p>
 <h2 id="layout-engine-testing-wzxhzdk8wzxhzdk9">Layout Engine Testing <a id="layoutengine"></a></h2>
-<p>The <a href="http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/test/layoutengine/"></a> directory in the repository contains a test suite for checking the functionality of Apache� FOP's layout engine. For information on how to create test cases for the layout engine, please visit the <a href="http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests">Wiki page</a> .</p>
+<p>The <a href="http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/test/layoutengine/">http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/test/layoutengine/</a> directory in the repository contains a test suite for checking the functionality of Apache� FOP's layout engine. For information on how to create test cases for the layout engine, please visit the <a href="http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests">Wiki page</a> .</p>
 <h2 id="functional-testing-wzxhzdk10wzxhzdk11">Functional Testing <a id="functional"></a></h2>
 <p><warning>The "functional" testing section on this page is currently inoperative.</warning></p>
 <h2 id="running-and-using-tests-wzxhzdk14wzxhzdk15">Running and Using Tests <a id="Running+and+Using+Tests"></a></h2>

Modified: websites/staging/xmlgraphics/trunk/content/fop/trunk/complexscripts.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/trunk/complexscripts.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/trunk/complexscripts.html Sat Dec  1 06:44:27 2012
@@ -398,7 +398,7 @@ A document author need not make explicit
 <p>In order to apply font specific complex script features, it is necessary to know the script that applies to the text undergoing layout processing. This script is determined using the following algorithm:</p>
 <ol>
 <li>
-<p>If the FO element that governs the text specifies a <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#script"></a> property and its value is not the empty string or <code>"auto"</code> , then that script is used.</p>
+<p>If the FO element that governs the text specifies a <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#script">http://www.w3.org/TR/2006/REC-xsl11-20061205/#script</a> property and its value is not the empty string or <code>"auto"</code> , then that script is used.</p>
 </li>
 <li>
 <p>Otherwise, the dominant script of the text is determined automatically by finding the script whose constituent characters appear most frequently in the text.</p>
@@ -605,7 +605,7 @@ A document author need not make explicit
 </table>
 <p><warning>Explicit use of one of the above extended script codes is not portable, and should be limited to use with FOP only.</warning>When performing automatic script determination, FOP selects the OpenType Indic Version 2 script codes by default. If the author requires Version 1 behavior, then an explicit, non-extension script code should be specified in a governing <code>script</code> property.</p>
 <h3 id="language-property-wzxhzdk18wzxhzdk19">Language Property <a id="language_property"></a></h3>
-<p>Certain fonts that support complex script features can make use of language information in order for language specific processing rules to be applied. For example, a font designed for the Arabic script may support typographic variations according to whether the written language is Arabic, Farsi (Persian), Sindhi, Urdu, or another language written with the Arabic script. In order to apply these language specific features, the author may explicitly mark the text with a <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#language"></a> property.</p>
+<p>Certain fonts that support complex script features can make use of language information in order for language specific processing rules to be applied. For example, a font designed for the Arabic script may support typographic variations according to whether the written language is Arabic, Farsi (Persian), Sindhi, Urdu, or another language written with the Arabic script. In order to apply these language specific features, the author may explicitly mark the text with a <a href="http://www.w3.org/TR/2006/REC-xsl11-20061205/#language">http://www.w3.org/TR/2006/REC-xsl11-20061205/#language</a> property.</p>
 <p>When specifying the <code>language</code> property, the value of the property must be either an <a href="http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes">ISO639-2 3-letter code</a> or an <a href="http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes">ISO639-1 2-letter code</a> . Comparison of language codes is performed in a case-insensitive manner, so it does not matter what case is used when specifying these codes in an XSL-FO document.</p>
 <h4 id="writing-mode-property-wzxhzdk20wzxhzdk21">Writing Mode Property <a id="writing_mode_property"></a></h4>
 <h4 id="number-conversion-properties-wzxhzdk22wzxhzdk23">Number Conversion Properties <a id="number_conversion_properties"></a></h4>

Modified: websites/staging/xmlgraphics/trunk/content/fop/trunk/intermediate.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/trunk/intermediate.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/trunk/intermediate.html Sat Dec  1 06:44:27 2012
@@ -386,7 +386,7 @@ Please note that the intermediate format
 <h1 id="usage-of-the-area-tree-xml-format-at-xml-wzxhzdk16wzxhzdk17">Usage of the Area Tree XML format (AT XML) <a id="usage"></a></h1>
 <p>As already mentioned, the area tree XML format is generated by using the <strong>XMLRenderer</strong> (MIME type: <strong>application/X-fop-areatree</strong> ). 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.</p>
 <p>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.</p>
-<p>The second step is to reparse the file using the <strong>AreaTreeParser</strong> 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 <a href="http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/"></a> directory in the FOP distribution.</p>
+<p>The second step is to reparse the file using the <strong>AreaTreeParser</strong> 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 <a href="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/</a> directory in the FOP distribution.</p>
 <p>The basic pattern to parse the area tree XML format looks like this:</p>
 <p>FopFactory fopFactory = FopFactory.newInstance();    <br />
 </p>
@@ -435,7 +435,7 @@ The area tree XML format is sensitive to
 </li>
 </ul>
 <p>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.</p>
-<p>The second step is to reparse the file using the <strong>IFParser</strong> 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 <a href="http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/"></a> directory in the FOP distribution.</p>
+<p>The second step is to reparse the file using the <strong>IFParser</strong> 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 <a href="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/</a> directory in the FOP distribution.</p>
 <p>The basic pattern to parse the intermediate format looks like this:</p>
 <p>FopFactory fopFactory = FopFactory.newInstance();</p>
 <p>// Setup output

Modified: websites/staging/xmlgraphics/trunk/content/fop/trunk/upgrading.html
==============================================================================
--- websites/staging/xmlgraphics/trunk/content/fop/trunk/upgrading.html (original)
+++ websites/staging/xmlgraphics/trunk/content/fop/trunk/upgrading.html Sat Dec  1 06:44:27 2012
@@ -382,7 +382,7 @@ While FOP 0.20.5 allowed you to have emp
 <p>As stated above empty table cells <code>&lt;fo:table-cell&gt;&lt;/fo:table-cell&gt;</code> are not allowed by the specification. The same applies to empty <code>static-content</code> and <code>block-container</code> elements, for example.</p>
 </li>
 <li>
-<p>0.20.5 is not XSL-FO compliant with respect to sizing images ( <code>external-graphic</code> ) or <code>instream-foreign-object</code> objects. If images or SVGs are sized differently in your outputs with the new FOP version check <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=37136">Bug 37136</a> as it contains some hints on what to do. The file <a href="http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/examples/fo/basic/images.fo?view=markup"></a> has a number of good examples that show the new, more correct behaviour.</p>
+<p>0.20.5 is not XSL-FO compliant with respect to sizing images ( <code>external-graphic</code> ) or <code>instream-foreign-object</code> objects. If images or SVGs are sized differently in your outputs with the new FOP version check <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=37136">Bug 37136</a> as it contains some hints on what to do. The file <a href="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</a> has a number of good examples that show the new, more correct behaviour.</p>
 </li>
 <li>
 <p>The <code>fox:outline</code> extension is not implemented in this version anymore. It has been superseded by the new bookmark elements from XSL-FO 1.1.</p>



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


Mime
View raw message