xmlgraphics-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c...@apache.org
Subject svn commit: r1415927 - in /xmlgraphics/site/trunk/content: commons/ fop/ fop/0.95/ fop/1.0/ fop/1.1/ fop/dev/ fop/trunk/
Date Sat, 01 Dec 2012 06:44:06 GMT
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


Mime
View raw message