You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@xmlgraphics.apache.org by cl...@apache.org on 2012/12/01 07:44:06 UTC
svn commit: r1415927 - in /xmlgraphics/site/trunk/content: commons/ fop/
fop/0.95/ fop/1.0/ fop/1.1/ fop/dev/ fop/trunk/
Author: clay
Date: Sat Dec 1 06:44:04 2012
New Revision: 1415927
URL: http://svn.apache.org/viewvc?rev=1415927&view=rev
Log:
Fixing empty links.
Modified:
xmlgraphics/site/trunk/content/commons/changes.mdtext
xmlgraphics/site/trunk/content/commons/download.mdtext
xmlgraphics/site/trunk/content/commons/index.mdtext
xmlgraphics/site/trunk/content/fop/0.95/changes_0.95.mdtext
xmlgraphics/site/trunk/content/fop/0.95/changes_0.95beta.mdtext
xmlgraphics/site/trunk/content/fop/0.95/intermediate.mdtext
xmlgraphics/site/trunk/content/fop/0.95/upgrading.mdtext
xmlgraphics/site/trunk/content/fop/1.0/changes_1.0.mdtext
xmlgraphics/site/trunk/content/fop/1.0/intermediate.mdtext
xmlgraphics/site/trunk/content/fop/1.0/upgrading.mdtext
xmlgraphics/site/trunk/content/fop/1.1/changes_1.1.mdtext
xmlgraphics/site/trunk/content/fop/1.1/complexscripts.mdtext
xmlgraphics/site/trunk/content/fop/1.1/intermediate.mdtext
xmlgraphics/site/trunk/content/fop/1.1/upgrading.mdtext
xmlgraphics/site/trunk/content/fop/changes.mdtext
xmlgraphics/site/trunk/content/fop/dev/testing.mdtext
xmlgraphics/site/trunk/content/fop/download.mdtext
xmlgraphics/site/trunk/content/fop/trunk/complexscripts.mdtext
xmlgraphics/site/trunk/content/fop/trunk/intermediate.mdtext
xmlgraphics/site/trunk/content/fop/trunk/upgrading.mdtext
Modified: xmlgraphics/site/trunk/content/commons/changes.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/commons/changes.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/commons/changes.mdtext (original)
+++ xmlgraphics/site/trunk/content/commons/changes.mdtext Sat Dec 1 06:44:04 2012
@@ -2,8 +2,7 @@ Title: History of Changes
#History of Changes
-
- [](changes.rss)
+ [changes.rss](changes.rss)
## Introduction and explanation of symbols <a id="introduction"></a>
Modified: xmlgraphics/site/trunk/content/commons/download.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/commons/download.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/commons/download.mdtext (original)
+++ xmlgraphics/site/trunk/content/commons/download.mdtext Sat Dec 1 06:44:04 2012
@@ -13,6 +13,6 @@ The latest source code is available dire
| Trunk |
|-------|
-| Repository URL | [](http://svn.apache.org/repos/asf/xmlgraphics/commons/trunk/) |
-| Web view | [](http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/) |
+| Repository URL | [http://svn.apache.org/repos/asf/xmlgraphics/commons/trunk/](http://svn.apache.org/repos/asf/xmlgraphics/commons/trunk/) |
+| Web view | [http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/](http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/) |
Committers need to replace " `http` " with " `https` " and then log in so they can gain write access!
\ No newline at end of file
Modified: xmlgraphics/site/trunk/content/commons/index.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/commons/index.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/commons/index.mdtext (original)
+++ xmlgraphics/site/trunk/content/commons/index.mdtext Sat Dec 1 06:44:04 2012
@@ -29,7 +29,7 @@ Components which have been ported from [
## News <a id="News"></a>
-RSS Feed: [](subproject-news-feed.rss)
+RSS Feed: [subproject-news-feed.rss](subproject-news-feed.rss)
### 7 Jul 2010: Version 1.4 Released <a id="news-2010-07-07"></a>
<item date="2010-07-07" title="Version 1.4 Released">
Modified: xmlgraphics/site/trunk/content/fop/0.95/changes_0.95.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/0.95/changes_0.95.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/0.95/changes_0.95.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/0.95/changes_0.95.mdtext Sat Dec 1 06:44:04 2012
@@ -3,7 +3,7 @@ Title: History of Changes 0.95
#History of Changes 0.95
- [](changes_0.95.rss)
+ [changes_0.95.rss](changes_0.95.rss)
## Introduction and explanation of symbols <a id="introduction"></a>
Modified: xmlgraphics/site/trunk/content/fop/0.95/changes_0.95beta.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/0.95/changes_0.95beta.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/0.95/changes_0.95beta.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/0.95/changes_0.95beta.mdtext Sat Dec 1 06:44:04 2012
@@ -3,7 +3,7 @@ Title: History of Changes 0.95beta
#History of Changes 0.95beta
- [](changes_0.95beta.rss)
+ [changes_0.95beta.rss](changes_0.95beta.rss)
## Introduction and explanation of symbols <a id="introduction"></a>
Modified: xmlgraphics/site/trunk/content/fop/0.95/intermediate.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/0.95/intermediate.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/0.95/intermediate.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/0.95/intermediate.mdtext Sat Dec 1 06:44:04 2012
@@ -13,7 +13,7 @@ The intermediate format can be used to g
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 f
irst 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/) 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/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 basic pattern to parse the IF format looks like this:
Modified: xmlgraphics/site/trunk/content/fop/0.95/upgrading.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/0.95/upgrading.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/0.95/upgrading.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/0.95/upgrading.mdtext Sat Dec 1 06:44:04 2012
@@ -35,6 +35,6 @@ 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 `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 [Bug 37136](http://issues.apache.org/bugzilla/show_bug.cgi?id=37136) 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) 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 [Bug 37136](http://issues.apache.org/bugzilla/show_bug.cgi?id=37136) 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.
- 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.
Modified: xmlgraphics/site/trunk/content/fop/1.0/changes_1.0.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/1.0/changes_1.0.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/1.0/changes_1.0.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/1.0/changes_1.0.mdtext Sat Dec 1 06:44:04 2012
@@ -3,7 +3,7 @@ Title: History of Changes 1.0
#History of Changes 1.0
- [](changes_1.0.rss)
+ [changes_1.0.rss](changes_1.0.rss)
## Introduction and explanation of symbols <a id="introduction"></a>
Modified: xmlgraphics/site/trunk/content/fop/1.0/intermediate.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/1.0/intermediate.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/1.0/intermediate.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/1.0/intermediate.mdtext Sat Dec 1 06:44:04 2012
@@ -49,7 +49,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/) 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/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the area tree XML format looks like this:
@@ -106,7 +106,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/) 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/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the intermediate format looks like this:
Modified: xmlgraphics/site/trunk/content/fop/1.0/upgrading.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/1.0/upgrading.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/1.0/upgrading.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/1.0/upgrading.mdtext Sat Dec 1 06:44:04 2012
@@ -37,6 +37,6 @@ 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 `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 [Bug 37136](http://issues.apache.org/bugzilla/show_bug.cgi?id=37136) 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) 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 [Bug 37136](http://issues.apache.org/bugzilla/show_bug.cgi?id=37136) 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.
- 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.
Modified: xmlgraphics/site/trunk/content/fop/1.1/changes_1.1.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/1.1/changes_1.1.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/1.1/changes_1.1.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/1.1/changes_1.1.mdtext Sat Dec 1 06:44:04 2012
@@ -3,7 +3,7 @@ Title: History of Changes 1.1
#History of Changes 1.1
- [](changes_1.1.rss)
+ [changes_1.1.rss](changes_1.1.rss)
## Introduction and explanation of symbols <a id="introduction"></a>
Modified: xmlgraphics/site/trunk/content/fop/1.1/complexscripts.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/1.1/complexscripts.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/1.1/complexscripts.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/1.1/complexscripts.mdtext Sat Dec 1 06:44:04 2012
@@ -39,15 +39,15 @@ A document author need not make explicit
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:
-- The [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#script) property.
+- The [http://www.w3.org/TR/2006/REC-xsl11-20061205/#script](http://www.w3.org/TR/2006/REC-xsl11-20061205/#script) property.
-- The [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#language) property.
+- The [http://www.w3.org/TR/2006/REC-xsl11-20061205/#language](http://www.w3.org/TR/2006/REC-xsl11-20061205/#language) property.
-- The [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#writing-mode) property.
+- The [http://www.w3.org/TR/2006/REC-xsl11-20061205/#writing-mode](http://www.w3.org/TR/2006/REC-xsl11-20061205/#writing-mode) property.
-- The number to string conversion properties: [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#format) , [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-separator) , [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-size) , [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#letter-value) , and `fox:number-conversion-features` .
+- The number to string conversion properties: [http://www.w3.org/TR/2006/REC-xsl11-20061205/#format](http://www.w3.org/TR/2006/REC-xsl11-20061205/#format) , [http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-separator](http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-separator) , [http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-size](http://www.w3.org/TR/2006/REC-xsl11-20061205/#grouping-size) , [http://www.w3.org/TR/2006/REC-xsl11-20061205/#letter-value](http://www.w3.org/TR/2006/REC-xsl11-20061205/#letter-value) , and `fox:number-conversion-features` .
-- The [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override) element.
+- The [http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override](http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override) element.
- 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.
@@ -62,7 +62,7 @@ The complex scripts related effects of t
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:
-1. If the FO element that governs the text specifies a [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#script) property and its value is not the empty string or `"auto"` , then that script is used.
+1. If the FO element that governs the text specifies a [http://www.w3.org/TR/2006/REC-xsl11-20061205/#script](http://www.w3.org/TR/2006/REC-xsl11-20061205/#script) property and its value is not the empty string or `"auto"` , then that script is used.
1. Otherwise, the dominant script of the text is determined automatically by finding the script whose constituent characters appear most frequently in the text.
@@ -125,7 +125,7 @@ The following table enumerates a number
<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 `script` property.
## Language Property <a id="language_property"></a>
-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 [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#language) property.
+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 [http://www.w3.org/TR/2006/REC-xsl11-20061205/#language](http://www.w3.org/TR/2006/REC-xsl11-20061205/#language) property.
When specifying the `language` property, the value of the property must be either an [ISO639-2 3-letter code](http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes) or an [ISO639-1 2-letter code](http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) . 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.
@@ -165,7 +165,7 @@ Writing modes that employ a vertical inl
### Bidi Override Element <a id="bidi_override_element"></a>
-The [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override) 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 [Bidi Control Characters](#bidi_controls) , the default behavior prescribed by the [Unicode Bidirectional Algorithm](http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override) applies.
+The [http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override](http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override) 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 [Bidi Control Characters](#bidi_controls) , the default behavior prescribed by the [Unicode Bidirectional Algorithm](http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_bidi-override) applies.
### Bidi Control Characters <a id="bidi_controls"></a>
Modified: xmlgraphics/site/trunk/content/fop/1.1/intermediate.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/1.1/intermediate.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/1.1/intermediate.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/1.1/intermediate.mdtext Sat Dec 1 06:44:04 2012
@@ -49,7 +49,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/) 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/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the area tree XML format looks like this:
@@ -106,7 +106,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/) 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/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the intermediate format looks like this:
Modified: xmlgraphics/site/trunk/content/fop/1.1/upgrading.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/1.1/upgrading.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/1.1/upgrading.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/1.1/upgrading.mdtext Sat Dec 1 06:44:04 2012
@@ -60,6 +60,6 @@ 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 [Bug 37136](http://issues.apache.org/bugzilla/show_bug.cgi?id=37136) 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) 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 [Bug 37136](http://issues.apache.org/bugzilla/show_bug.cgi?id=37136) 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.
- 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.
Modified: xmlgraphics/site/trunk/content/fop/changes.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/changes.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/changes.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/changes.mdtext Sat Dec 1 06:44:04 2012
@@ -3,7 +3,7 @@ Title: History of Changes
#History of Changes
- [](changes.rss)
+ [changes.rss](changes.rss)
## Introduction and explanation of symbols <a id="introduction"></a>
Modified: xmlgraphics/site/trunk/content/fop/dev/testing.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/testing.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/testing.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/testing.mdtext Sat Dec 1 06:44:04 2012
@@ -18,7 +18,7 @@ There is a group of basic API tests that
## Layout Engine Testing <a id="layoutengine"></a>
-The [](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/test/layoutengine/) 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 [Wiki page](http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests) .
+The [http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/test/layoutengine/](http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/test/layoutengine/) 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 [Wiki page](http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests) .
## Functional Testing <a id="functional"></a>
<warning>The "functional" testing section on this page is currently inoperative.</warning>
Modified: xmlgraphics/site/trunk/content/fop/download.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/download.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/download.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/download.mdtext Sat Dec 1 06:44:04 2012
@@ -33,16 +33,16 @@ There are several ways to obtain a sourc
| Latest Stable Release |
|-----------------------|
-| Repository URL | [](http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_0/) |
-| Web view | [](http://svn.apache.org/viewvc/xmlgraphics/fop/tags/fop-1_0/) |
+| Repository URL | [http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_0/](http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_1/) |
+| Web view | [http://svn.apache.org/viewvc/xmlgraphics/fop/tags/fop-1_0/](http://svn.apache.org/viewvc/xmlgraphics/fop/tags/fop-1_1/) |
| Previous Stable Release |
|-------------------------|
-| Repository URL | [](http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_95/) |
-| Web view | [](http://svn.apache.org/viewvc/xmlgraphics/fop/tags/fop-0_95/) |
+| Repository URL | [http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_0/](http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_0/) |
+| Web view | [http://svn.apache.org/viewvc/xmlgraphics/fop/tags/fop-1_0/](http://svn.apache.org/viewvc/xmlgraphics/fop/tags/fop-1_0/) |
| Trunk |
|-------|
-| Repository URL | Main Repository: [](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/) <br></br>European Mirror: [](http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/trunk/) |
-| Web view | Main Repository: [](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/) <br></br>European Mirror: [](http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/) |
+| Repository URL | Main Repository: [http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/](http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/) <br></br>European Mirror: [http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/trunk/](http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/trunk/) |
+| Web view | Main Repository: [http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/) <br></br>European Mirror: [http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/](http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/) |
With any source distribution, you will need to build FOP from the source files. For details please see the "Build" page on the documentation tab for the version you've downloaded.
Modified: xmlgraphics/site/trunk/content/fop/trunk/complexscripts.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/trunk/complexscripts.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/trunk/complexscripts.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/trunk/complexscripts.mdtext Sat Dec 1 06:44:04 2012
@@ -55,7 +55,7 @@ The complex scripts related effects of t
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:
-1. If the FO element that governs the text specifies a [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#script) property and its value is not the empty string or `"auto"` , then that script is used.
+1. If the FO element that governs the text specifies a [http://www.w3.org/TR/2006/REC-xsl11-20061205/#script](http://www.w3.org/TR/2006/REC-xsl11-20061205/#script) property and its value is not the empty string or `"auto"` , then that script is used.
1. Otherwise, the dominant script of the text is determined automatically by finding the script whose constituent characters appear most frequently in the text.
@@ -119,7 +119,7 @@ The following table enumerates a number
<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 `script` property.
### Language Property <a id="language_property"></a>
-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 [](http://www.w3.org/TR/2006/REC-xsl11-20061205/#language) property.
+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 [http://www.w3.org/TR/2006/REC-xsl11-20061205/#language](http://www.w3.org/TR/2006/REC-xsl11-20061205/#language) property.
When specifying the `language` property, the value of the property must be either an [ISO639-2 3-letter code](http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes) or an [ISO639-1 2-letter code](http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) . 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.
Modified: xmlgraphics/site/trunk/content/fop/trunk/intermediate.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/trunk/intermediate.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/trunk/intermediate.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/trunk/intermediate.mdtext Sat Dec 1 06:44:04 2012
@@ -49,7 +49,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/) 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/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the area tree XML format looks like this:
@@ -106,7 +106,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/) 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/examples/embedding/java/embedding/intermediate/](http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/) directory in the FOP distribution.
The basic pattern to parse the intermediate format looks like this:
Modified: xmlgraphics/site/trunk/content/fop/trunk/upgrading.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/trunk/upgrading.mdtext?rev=1415927&r1=1415926&r2=1415927&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/trunk/upgrading.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/trunk/upgrading.mdtext Sat Dec 1 06:44:04 2012
@@ -35,6 +35,6 @@ 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 `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 [Bug 37136](http://issues.apache.org/bugzilla/show_bug.cgi?id=37136) 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) 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 [Bug 37136](http://issues.apache.org/bugzilla/show_bug.cgi?id=37136) 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.
- 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: commits-help@xmlgraphics.apache.org