You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@xmlgraphics.apache.org by vh...@apache.org on 2014/07/24 18:21:24 UTC
svn commit: r1613173 [11/15] - in /xmlgraphics/site/trunk/content: ./ batik/
batik/dev/ batik/tools/ batik/using/ batik/using/scripting/ commons/ fop/
fop/0.95/ fop/1.0/ fop/1.1/ fop/dev/ fop/dev/design/ fop/trunk/
Modified: xmlgraphics/site/trunk/content/fop/dev/conventions.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/conventions.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/conventions.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/conventions.mdtext Thu Jul 24 16:21:20 2014
@@ -5,7 +5,7 @@ Title: Apache(tm) FOP Development: Codin
Acknowledgement: Some content in this guide was adapted from other Apache™ projects such as Avalon, Cactus, Turbine and Velocity.
-## Subversion Repository {#svn}
+## Subversion Repository { #svn}
Conventions in this section apply to Repository content, regardless of type:
@@ -16,9 +16,9 @@ Conventions in this section apply to Rep
- In order to be able to discern commits from a committer from those where a committer applied a patch from a contributor, the commit message must contain a separate line following this pattern: **"Submitted by: [contributor's name] <[contributor's obfuscated e-mail address]>"**. This also helps doing audits on the repository.
-## Java {#java}
+## Java { #java}
-### Java Style {#java-style}
+### Java Style { #java-style}
In order to facilitate the human reading of FOP source code, reduce churning in code, and prevent disputes, the FOP developers have agreed on a set of coding conventions. The basis of these coding conventions is documented in the [Apache XML Project Guidelines](http://xml.apache.org/source.html), which requires that **all Java Language source code in the repository must be written in conformance to Sun's** [Code Conventions for the Java Programming Language](http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html). In addition, the FOP developers have agreed to other conventions, which are summarized in the following table:
@@ -37,7 +37,7 @@ In order to facilitate the human reading
For developers that dislike these conventions, one workaround is to develop using their own style, then use a formatting tool like [astyle](http://astyle.sourceforge.net/) (Artistic Style) before committing.
-### Checkstyle {#java-checkstyle}
+### Checkstyle { #java-checkstyle}
The java syntax checker " [Checkstyle](http://checkstyle.sourceforge.net) " is used to enforce many of the FOP coding standards. The standards enforced through Checkstyle are documented in its configuration file (xml-fop/checkstyle.cfg). The conventions defined in the configuration file are an integral part of FOP's coding conventions, and should not be changed without common consent. In other words, the configuration file contains additional conventions that are not documented on this page, but are generally accepted as good style within the java community (i.e. they are the default behavior of checkstyle, which the FOP developers have decided to adopt *de facto*). Any apparent contradiction between the configuration file and this document should be raised on the fop-dev mailing list so that it can be clarified.
@@ -45,7 +45,7 @@ To use the "checkstyle" target in FOP's
Checkstyle is probably most useful when integrated into your IDE. See the Checkstyle web site for more information about IDE plugins.
-### Java Best Practices {#java-best-practices}
+### Java Best Practices { #java-best-practices}
The following general principles are a distillation of best practice expectations on the FOP project.
@@ -70,21 +70,21 @@ The following general principles are a d
- Try to avoid catching Throwable or Exception and catch specific exceptions instead.
-### Resources {#java-resources}
+### Resources { #java-resources}
- [book on code style] Code Complete by Steve McConnell.
- [code formatting software] [JRefactory](http://jrefactory.sourceforge.net).
-### Related Links {#java-links}
+### Related Links { #java-links}
- [Apache XML Graphics Code Repositories](http://xmlgraphics.apache.org/repo.html)
- [Jakarta Code Conventions and Standards](http://jakarta.apache.org/site/faqs.html#Coding%20Conventions%20and%20Standards) (see Coding Conventions and Standards section)
-## XML {#xml}
+## XML { #xml}
| Convention | Rationale | Enforced By |
|------------|-----------|-------------|
Modified: xmlgraphics/site/trunk/content/fop/dev/design/areas.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/areas.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/areas.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/areas.mdtext Thu Jul 24 16:21:20 2014
@@ -3,7 +3,7 @@ Title: Apache(tm) FOP Design: Area Tree
#Apache™ FOP Design: Area Tree
<authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors>
-## Introduction {#intro}
+## Introduction { #intro}
The Area Tree is an internal representation of the result document, representing pages and their contents. To make the concepts clearer and easier to understand, the code to implement the area tree matches the areas defined in the XSL-FO specification.
@@ -11,11 +11,11 @@ The area tree is created by the layout m
The Area Tree consists of a set of pages, which the actual implemenation places in a set of page sequences.
-## Structure {#structure}
+## Structure { #structure}
The area tree is a root element that has a list of page-viewport-areas. Each page viewport has a page-reference-area which holds the contents of the page. To handle the processing better FOP does not maintain a list at the root level but lets the area tree model handle each page as it is added.
-## Page {#page}
+## Page { #page}
A page consists of a page+viewport pair.
@@ -29,7 +29,7 @@ For the body area there are more subdivi
Since the layout is done inside a page, the page is created from the pagemaster with all the appropriate areas. The layout manager then uses the page to add areas into the normal flow reference areas and floats and footnotes. After adding the areas for the body region then the other regions can be done layed out and added.
-## Block Areas {#block}
+## Block Areas { #block}
Block level areas contain either other blocks or line areas (which is a special block area).
@@ -37,13 +37,13 @@ A block is either positoned or stacked w
Block areas are created and/or returned by all top level elements in the flow. The spacing between block areas is handled by an empty block area. A block area is stacked with other block areas in a particular direction, it has a size and it contains line areas made from a group of inline areas and/or block areas.
-## Line Areas {#line-area}
+## Line Areas { #line-area}
A line areas is simply a collection of inline areas that are stacked in the inline progression direction. A line area has a height and a start position. The line area is rendered by handling each inline area.
A line area gets a set of inline areas added until complete then it is justified and vertically alignedi when adding the areas. If the line area contains unresolved areas then there will be a line resolver that retains the justification information until all areas in the line are resolved.
-## Inline Areas {#inline}
+## Inline Areas { #inline}
There are a few different types of inline areas. All inline areas have a height and width.
@@ -55,11 +55,11 @@ The image and instream foreign object ar
Once a LineArea is filled with inline areas then the inline areas need to be aligned and adjusted to fill the line properly.
-## Repeated Areas {#repeated-area}
+## Repeated Areas { #repeated-area}
There are cases where the same subtree could be repeated in the area tree. These areas will be returned by the same layout managers. So it is possible to put a flag on the created areas so that the subtree data can be cached in the output. Examples of this are: static areas, table header/footer, svg.
-## Traits {#traits}
+## Traits { #traits}
A trait is information associated with an area. This could be information such as text colour or is-first.
@@ -67,25 +67,25 @@ Traits provide information about an area
A dominant trait on a block area is set, for example font colour, so that every line area with the same dominant value can derive it. The text inline areas then get the font colour set on the inline area or from the line area or from the block area.
-## Classes {#classes}
+## Classes { #classes}
The following class structure will be used to represent the area tree.
-### Page Area Classes {#classes-page}
+### Page Area Classes { #classes-page}
The page area classes hold the top level layout of a page. The areas are created by the page master and should be ready to have flow areas added.
-### Block Area Classes {#classes-block}
+### Block Area Classes { #classes-block}
The block areas hold other block areas and/or line areas. The child areas are stacked in a particular direction.
Areas for tables, lists and block container have their child block areas stacked in different ways. These areas a placed with an absolute positioning. The absolute positioning is where the blocks are placed with an offset from the parent reference area.
-### Inline Area Classes {#classes-inline}
+### Inline Area Classes { #classes-inline}
The inline areas are used to make up a line area. An inline area typically has a height, width and some content. The inline area is offset from the baseline of the current line area. The content of the inline area can be other inline areas or a simple atomic object.
-## Forward References {#forward-references}
+## Forward References { #forward-references}
The Area Tree maintains a set of mappings from the reference to pages.
@@ -93,7 +93,7 @@ The PageViewPort holds the list of forwa
To layout a page any areas that cannot be resolved need to reserve space. Once the inline area is resolved then the complete line should be adjusted to accomodate any change in space used by the area.
-## Caching {#caching}
+## Caching { #caching}
We may need to cache pages due to forward references or when keeping all pages.
@@ -101,13 +101,13 @@ This is done by serializing the Page. Th
The PageViewport retains information about id areas for easy access.
-## Extensions {#extensions}
+## Extensions { #extensions}
The Area Tree holds the Output Document extensions. This is information such as pdf bookmarks or other output document specific information that is not handled by XSL:FO.
It is also possible to create custom areas that extend a normal area. The actual data that is rendered could be set in a different way or depend on resolving a forward reference.
-## Area Tree Handlers {#handlers}
+## Area Tree Handlers { #handlers}
To handle different situations the handler for the Area Tree handles each page as it is added.
@@ -115,13 +115,13 @@ The RenderPagesModel sends the page dire
The Area Tree retains the concept of page sequences (this is not in the area tree in the spec) so that this information can be passed to the renderer. This is useful for setting the title and organising the groups of page sequences.
-## Status {#status}
+## Status { #status}
-### To Do {#status-todo}
+### To Do { #status-todo}
-### Work in Progress {#status-wip}
+### Work in Progress { #status-wip}
-### Completed {#status-complete}
+### Completed { #status-complete}
- new area tree model
Modified: xmlgraphics/site/trunk/content/fop/dev/design/breakpos.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/breakpos.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/breakpos.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/breakpos.mdtext Thu Jul 24 16:21:20 2014
@@ -3,21 +3,21 @@ Title: Apache(tm) FOP Design: Layout Man
#Apache™ FOP Design: Layout Managers
<subtitle>Break Possibility Proposal</subtitle><authors><person email="klease@club-internet.fr" name="Karen Lease"></person></authors>
-## Introduction {#intro}
+## Introduction { #intro}
As explained in [Layout](layout.html), the hierarchy of Layout Managers is responsible for building and placing areas. Each Layout Manager is responsible for creating and filling areas of a particular type, either inline or block. This document explains one potential algorithm for this process. It is based on the the generation of *break possibilities* (BP for short). The Layout Managers (LM for short), will generate one or more BP and choose the best one. The BP is then used to generate the corresponding areas.
-## Anatomy of a Break Possibility {#Anatomy-of-a-Break-Possibility}
+## Anatomy of a Break Possibility { #Anatomy-of-a-Break-Possibility}
A break possibility is represented by the BreakPoss class. A BreakPoss contains size information in the stacking direction and in the non-stacking direction (at least for inline areas, it must have both). Flags indicating various conditions (ISFIRST, ISLAST, CAN_BREAK_AFTER, FORCE_BREAK_AFTER, ANCHORS etc). A BreakPoss contains a reference to the top-level LayoutManager which generated it.
A BreakPoss contains an object implementing the BreakPoss.Position interface. This object is specific to the layout manager which created the BreakPoss. It should indicate where the break occurs and allow the LM to create an area corresponding to the BP. A higher level LM Position must somehow reference or wrap the Position returned by its child LM in its BreakPoss object. The layout manager modifies the flags and dimension information in the BP to reflect its own requirements. For example an inline FO layout manager might add space-start, space-end, border and padding values to the stacking or non-stacking dimensions. It might also modify the flags based its on keep properties.
-## Turning Break Possibilities into Areas {#Turning-Break-Possibilities-into-Areas}
+## Turning Break Possibilities into Areas { #Turning-Break-Possibilities-into-Areas}
Once break possibilities have been generated, the galley-level layout manager selects the best one and passes it back to the LayoutManager which generated it to create the area. A LayoutManager is responsible for storing enough information in its Position objects to be able to create the corresponding areas.
-## A walk-through {#A-walk-through}
+## A walk-through { #A-walk-through}
Layout Managers are created from the top down. First the page sequence creates a PageLM and a FlowLM. The PageLM will manage finding the right page model (with help from the PageSequenceMaster) and managing the balancing act between before-floats, footnotes and the normal text flow. The FlowLM will manage the normal content in the main flow. We can think of it as a *galley* manager.
@@ -51,15 +51,15 @@ The FlowLM sees if the returned stacking
If the returned BP has any new before-float or footnote anchors in it (ANCHOR flag in the BP), the FlowLM will also return to the PageLM. The PageLM must then try to find space to place the floats, possibly asking the FlowLM for help if the body contains multiple columns.
-## Some issues {#Some-issues}
+## Some issues { #Some-issues}
Following are a few remarks on specific issues.
-### Where Line Layout Managers are created {#Where-Line-Layout-Managers-are-created}
+### Where Line Layout Managers are created { #Where-Line-Layout-Managers-are-created}
If the first child FO in a block FO is an inline-level FO such as text, the block LM creates an intermediate level LineLM to layout the sequence of inline content into Lines. Note that the whole sequence of inline FOs is managed by a single instance of LineLM. The LineLM becomes the parent to the various inline-level LM created by each individual inline FO. Since an fo:block can have both block and inline content, its LM may create a sequence of intermixed BlockLM and LineLM.
-### Getting the reference IPD {#getRefIPD}
+### Getting the reference IPD { #getRefIPD}
When the layout process starts, with the FlowLM asking its first child LM for a break possibility, the IPD isn't known, since we don't know whether the first FO might be spanning, or on which page it might start. (Of course, if all page masters in the sequence have the same region-body IPD and all have only a single column, the IPD will never change and could already be calculated before starting layout.) The FlowLM gets its first child LM and calls its getNextBreakPoss method. That is a child LM for some block-level FO. For now, suppose it's an fo:block. The BlockLM will create its first child LM, which may be another block-level LM in the case of nested blocks or a LineLM as explained above. (Question: do we need a START flag for layout status?)
@@ -67,11 +67,11 @@ We keep calling getNextBreakPoss on lowe
Using this information, the BlockLM parent can now calculate the available IPD for its LineLM child, based on its indents. (If there are any side-floats information about the intrusion must be passed down by the FlowLM to lower level managers.) The LineLM can now generate a series of BreakPoss objects, which it passes back to its parent LM.
-### Hyphenation {#Hyphenation}
+### Hyphenation { #Hyphenation}
The LineLM is responsible for initiating hyphenation if it is allowed by the properties and if no satisfactory BP can be found without hyphenating. The hyphenation manager is passed two break possibilities, one whose IPD is less than the desired line area IPD and one whose IPD is greater. These break possibilities might have been generated by different inline-level layout managers (text + a wrapper with a color change for example), though frequently they represent two positions in a single text run. If hyphenation is successful, a new BP is returned. The LineLM may look for several intermediate BP based on the "cost" of the returned possibilities. If no intermediate BP is found, the line will be "short", the white-space stretch will be exceeded, or perhaps the content will be overflowed or clipped, depending on various property settings.
-### Optimizing {#Optimizing}
+### Optimizing { #Optimizing}
It obviously seems inefficient to go down to the lowest level LM and back up to the FlowLM for every possible line-break decision. It seems like it would be possible to optimize by letting the lower level layout managers run until they had exceeded the current limit in the stacking direction. They would then return control to the "galley" level (LineLM or FlowLM) which would fine-tune the break decision by asking the lower level LM to find a previous BP which would fit. At the inline level, this means hyphenation as described above.
Modified: xmlgraphics/site/trunk/content/fop/dev/design/embedding.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/embedding.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/embedding.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/embedding.mdtext Thu Jul 24 16:21:20 2014
@@ -4,15 +4,15 @@ Title: Apache(tm) FOP Design: Embedding
<authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors>
-## Introduction {#intro}
+## Introduction { #intro}
This is the design for the external interface when Apache™ FOP is to be embedded inside another java application.
Common places where FOP is embedded is in a report production application of a server side application such as [Cocoon](http://xml.apache.org/cocoon/index.html).
-## Settings {#Settings}
+## Settings { #Settings}
-### User Agent {#User-Agent}
+### User Agent { #User-Agent}
Possible meanings for a user agent:
@@ -25,7 +25,7 @@ Possible meanings for a user agent:
The user agent is responsible for supplying user or context specific information. The list of user agent values can be found on the [User Agent](useragent.html) page.
-### Logging {#Logging}
+### Logging { #Logging}
- logging level
@@ -36,14 +36,14 @@ The user agent is responsible for supply
- Logging setup (LogKit, Log4J, JDK14Logging)
-### XML input {#XML-input}
+### XML input { #XML-input}
- various ways to supply FOP with the xsl:fo file, fo, xml+xsl
- sax handler
-### general options {#general-options}
+### general options { #general-options}
- base url
@@ -52,7 +52,7 @@ The user agent is responsible for supply
- which implementation of a particular LayoutManager to use
-### Rendering Options {#Rendering-Options}
+### Rendering Options { #Rendering-Options}
- embedding fonts
@@ -70,7 +70,7 @@ for the PS renderer (eventually):
- binary/ascii switch
-### Render Results {#Render-Results}
+### Render Results { #Render-Results}
Generate Output statistics from FOP:
@@ -83,11 +83,11 @@ Generate Output statistics from FOP:
- recoverable errors such as overflow
-### Setting Up {#Setting-Up}
+### Setting Up { #Setting-Up}
The Driver handles the XML input. The user agent information is through the FOUserAgent. Handle logging through the user agent. Options could also be handled through the user agent, using mime type selection for renderer options.
-### Others {#Others}
+### Others { #Others}
Render to more than one renderer at once (maybe not from the command line). For example you could generate a PDF for the archive and the PS for the printer in one run. It would probably be faster than converting the PDF to PostScript afterwards. Make the fo tree reuseable. If the fonts are the same then use the same area tree to output to different renderers.
Modified: xmlgraphics/site/trunk/content/fop/dev/design/extending.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/extending.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/extending.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/extending.mdtext Thu Jul 24 16:21:20 2014
@@ -3,11 +3,11 @@ Title: Apache(tm) FOP Design: Extensions
#Apache™ FOP Design: Extensions
<authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors>
-## Introduction {#intro}
+## Introduction { #intro}
Apache™ FOP provides an extension mechanism to add extra functionality. There are a number of different types of extensions that apply to different steps when converting FO into the rendered output.
-## Extensions {#Extensions}
+## Extensions { #Extensions}
SVG Graphic - This applies to svg and any other xml document that can be converted into svg in the output. All that is required is the element mapping for the xml and a converter that changes the document into svg. This conversion is done in the FO Tree. The conversion is done by the top level element of the namespace or in the case of an external image a Converter.
@@ -24,7 +24,7 @@ Resolveable - In some cases it may requi
- Separate page number display for a subsection. ie. - master document is page 4 of 7, but subsection is page 2 of 3.
-## Examples {#Examples}
+## Examples { #Examples}
Plan - The plan extension is a simple SVG graphic extension. Given a plan document either inside an InstreamForeignObject or as an external graphic, it converts the plan document into an svg graphic. The svg graphic is then passed through the Area Tree to the Renderer. The Renderer then renders the svg graphic as normal.
@@ -46,11 +46,11 @@ to result in a text box referencing the
/JS (app.execMenuItem("AcroSrch:Query");)
>>
-## Status {#status}
+## Status { #status}
-### To Do {#status-todo}
+### To Do { #status-todo}
-### Work In Progress {#status-wip}
+### Work In Progress { #status-wip}
- mathml extension
@@ -59,7 +59,7 @@ to result in a text box referencing the
- svg text normal text if that can be handled otherwise stroked this is done automatically
-### Completed {#status-complete}
+### Completed { #status-complete}
- svg now in an xml handler, FOP can be used without batik
Modified: xmlgraphics/site/trunk/content/fop/dev/design/fotree.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/fotree.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/fotree.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/fotree.mdtext Thu Jul 24 16:21:20 2014
@@ -3,11 +3,11 @@ Title: Apache(tm) FOP Design: FO Tree
#Apache™ FOP Design: FO Tree
<authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors>
-## Introduction {#intro}
+## Introduction { #intro}
The FO Tree is an internal hierarchical representation (java objects and properties) of the input XSL-FO document, and is created from the [parsing](parsing.html) of that XSL-FO document. The process of building the FO Tree corresponds to the **Objectify** step in the XSL-FO spec. The FO Tree is an intermediate structure which will later be [converted into the area tree](layout.html).
-## Processing {#process}
+## Processing { #process}
The SAX Events that are fired by the parsing process are caught by the FO Tree system. Events for starting an element, ending an element, and text data are assembled by the FO Tree system into a set of objects that represent the input FO document. A class exists for each element in the XSL-FO set, and an object in the appropriate class is created for each element in the input XSL-FO.
@@ -26,7 +26,7 @@ For unrecognized namespaces, a dummy obj
While the tree building is mainly about creating the FO Tree, some FO Tree events trigger processes in other parts of FOP. The end of a page-sequence element triggers the layout process for that page-sequence (see discussion of [Recycling](#recycle)). Also, the end of the XML document tells the renderer that it can finalize the output document.
-## Recycling FO Tree Memory {#recycle}
+## Recycling FO Tree Memory { #recycle}
To minimize the amount of memory used by FOP, we wish to recycle FO Tree memory as much as possible. There are at least three possible places that FO Tree fragments could be passed to the Layout process, so that their memory can be reused:
@@ -37,27 +37,27 @@ To minimize the amount of memory used by
- **fo:page-sequence** The page-sequence object provides a nice clean break in the document. Content from one page-sequence will never interfere with nor affect the placement of the content of another. FOP uses this option as the optimum way to maintain compliance with the standard and to minimize memory consumption.
-## FO Tree Serialization {#serialize}
+## FO Tree Serialization { #serialize}
This issue is implied by the requirement to process documents of arbitrary size. Unless some arbitrary limit is placed on the size of page-sequence objects, FOP must be able to serialize FO tree fragments as necessary.
-## Notes About Specific Elements {#specific-elements}
+## Notes About Specific Elements { #specific-elements}
-### page-master {#page-master}
+### page-master { #page-master}
The first elements in a document are the elements for the page master setup. This is usually only a small number and will be used throughout the document to create new pages. The root element keeps these objects as a factory to create the page and appropriate regions whenever a new page is requested by the layout. The objects in the FO Tree that represent these elements are themselves the factory.
-### flow {#flow}
+### flow { #flow}
The elements within the flow of a page-sequence are those that are needed for the layout process. These element will later be used to create areas in the layout process.
-### Other Elements {#other-elements}
+### Other Elements { #other-elements}
The remaining FO Objects are things like page-sequence, title and color-profile. Each is handled by its parent element. The root handles declarations, and declarations maintains a list of colour profiles. The page-sequences are direct descendants of root.
-## Implementation Notes {#implement}
+## Implementation Notes { #implement}
-### FONode {#fonode}
+### FONode { #fonode}
The base class for all objects in the tree is FONode. The base class for all FO Objects is FObj (which is a subclass of FONode). Other FONode subclasses are for foreign and unknown XML.
@@ -74,7 +74,7 @@ Each xml element is represented by a jav
- other: `org.apache.fop.fo.*.`
-### Creating FO Objects {#create-fo}
+### Creating FO Objects { #create-fo}
The process of creating an FO Object is as follows (see `FOTreeBuilder.startElement()` for details):
@@ -89,7 +89,7 @@ The process of creating an FO Object is
- Child elements are then processed. This is an iterative process: the child elements go through the same process here documented for their parent.
-### Foreign XML {#foreign}
+### Foreign XML { #foreign}
For SVG, the DOM needs to be created with Batik, so an element mapping is used to read all elements in the SVG namespace and pass them into the Batik DOM.
@@ -101,6 +101,6 @@ Foreign XML will usually be in an fo:ins
See [Input Parsing Namespaces](parsing.html#namespaces) for more discussion and links to information about using foreign XML in FOP.
-### Unknown Elements {#unknown}
+### Unknown Elements { #unknown}
If an element is in a known namespace but the element is unknown within that namespace, then an Unknown object is created. This generally indicates an input error: perhaps an element from an older version of the XSL-FO standard, or a misspelling. The Unknown object is mainly used to provide information to the user.
Modified: xmlgraphics/site/trunk/content/fop/dev/design/images.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/images.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/images.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/images.mdtext Thu Jul 24 16:21:20 2014
@@ -3,7 +3,7 @@ Title: Apache(tm) FOP Design: Images
#Apache™ FOP Design: Images
-## Introduction {#intro}
+## Introduction { #intro}
Images may only be needed to be loaded when the image is rendered to the output or to find the dimensions.
@@ -13,19 +13,19 @@ We have a number of different caching sc
All images are referred to using the url given in the XSL:FO after removing "url('')" wrapping. This does not include any sort of resolving such as relative -> absolute. The external graphic in the FO Tree and the image area in the Area Tree only have the url as a reference. The images are handled through a static interface in ImageFactory.
-## Threading {#Threading}
+## Threading { #Threading}
In a single threaded case with one document the image should be released as soon as the renderer caches it. If there are multiple documents then the images could be held in a weak cache in case another document needs to load the same image.
In a multi threaded case many threads could be attempting to get the same image. We need to make sure an image will only be loaded once at a particular time. Once a particular document is finished then we can move all the images to a common weak cache.
-## Caches {#Caches}
+## Caches { #Caches}
-### LRU {#LRU}
+### LRU { #LRU}
All images are in a common cache regardless of context. To limit the size of the cache the LRU image is removed to keep the amount of memory used low. Each image can supply the amount of data held in memory.
-### Context {#Context}
+### Context { #Context}
Images are cached according to the context, using the FOUserAgent as a key. Once the context is finished the images are added to a common weak hashmap so that other contexts can load these images or the data will be garbage collected if required.
@@ -33,25 +33,25 @@ If images are to be used commonly then w
The cache uses an image loader so that it can synchronize the image loading on an image by image basis. Finding and adding an image loader to the cache is also synchronized to prevent thread problems.
-## Invalid Images {#Invalid-Images}
+## Invalid Images { #Invalid-Images}
If an image cannot be loaded for some reason, for example the url is invalid or the image data is corrupt or an unknown type. Then it should only attempt to load the image once. All other attempts to get the image should return null so that it can be easily handled.
This will prevent any extra processing or waiting.
-## Reading {#Reading}
+## Reading { #Reading}
Once a stream is opened for the image url then a set of image readers is used to determine what type of image it is. The reader can peek at the image header or if necessary load the image. The reader can also get the image size at this stage. The reader then can provide the mime type to create the image object to load the rest of the information.
-## Data {#Data}
+## Data { #Data}
The data usually need for an image is the size and either a bitmap or the original data. Images such as jpeg and eps can be embedded into the document with the original data. SVG images are converted into a DOM which needs to be rendered to the PDF. Other images such as gif, tiff etc. are converted into a bitmap. Data is loaded by the FopImage by calling load(type) where type is the type of data to load.
-## Rendering {#Rendering}
+## Rendering { #Rendering}
Different renderers need to have the information in different forms.
-### PDF {#PDF}
+### PDF { #PDF}
original data
: JPG, EPS
@@ -62,7 +62,7 @@ bitmap
other
: SVG
-### PS {#PS}
+### PS { #PS}
bitmap
: JPG, gif, tiff, bmp, png
@@ -70,7 +70,7 @@ bitmap
other
: SVG
-### awt {#awt}
+### awt { #awt}
bitmap
: JPG, gif, tiff, bmp, png
Modified: xmlgraphics/site/trunk/content/fop/dev/design/index.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/index.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/index.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/index.mdtext Thu Jul 24 16:21:20 2014
@@ -4,7 +4,7 @@ Title: Apache(tm) FOP Design: Introducti
<note>The articles in this section pertain mainly to the *redesign* or *trunk* line of development. The redesign is mainly focusing on parts of the layout process (converting the FO tree into the Area Tree). Therefore other (non-layout) sections in this document are probably largely accurate for the maintenance branch, but should be used with care in that context.</note>
-## The Black Box View {#black-box}
+## The Black Box View { #black-box}
From a user's standpoint, Apache™ FOP is a black box that an xml file as input, performs some magic, then creates the desired output:
@@ -15,25 +15,25 @@ From a user's standpoint, Apache™
Although this is simple, it is useful in defining the outer limits of FOP's core processing. There may be other things going on under FOP's control that are not really part of FOP. For example, FOP provides a convenience mechanism that takes semantic XML + an XSLT transformation as input, instead of XSL-FO. This is done outside of FOP's core processing (by Xalan), and it is therefore outside the scope of FOP's design, and outside the scope of the FOP design documents.
-## Primary Design Goals {#primary-goals}
+## Primary Design Goals { #primary-goals}
A discussion of project design properly begins with a list of the goals of the project. Out of these goals will flow the design issues and details, and eventually, the implementation.
-### Conformance to the XSL-FO Specification {#pri-goal-conformance}
+### Conformance to the XSL-FO Specification { #pri-goal-conformance}
The current design goal is to reach the "basic" level of conformance, and to have enough flexibility in the design to reach "complete" conformance without major rewriting. After "basic" conformance is achieved, it is probable that higher levels of conformance will be sought.
-### Process Files of Arbitrary Size {#pri-goal-unlimited-size}
+### Process Files of Arbitrary Size { #pri-goal-unlimited-size}
Except for user storage limitations, the design goal is to be able to process files of any size. In a separate but related issue, the design goal is to be able to process page-sequence elements of any size. (See [Recycling FO Tree Memory](fotree.html#recycle) for a discussion of the use of page-sequence as a logical subdivided "chunk" on an FO document).
-## Secondary Design Goals {#secondary-goals}
+## Secondary Design Goals { #secondary-goals}
-### Minimize Memory Use {#sec-goal-memory}
+### Minimize Memory Use { #sec-goal-memory}
Many FOP design decisions revolve around trying to minimize the use of memory. The primary purpose here is to reduce the amount of data that must be serialized to storage during processing. Since our primary design goals include the ability to process files of arbitrary size, there is no way to avoid the need to serialize. However, many FOP users provide web access to documents that are created in real time. Performance is therefore an important issue in these real-world applications. To the extent that it can be done so without jeopardizing the primary design goals, FOP developers have identified keeping a small memory footprint as being an important secondary goal.
-## The Big Picture View {#big-picture}
+## The Big Picture View { #big-picture}
With our design goals outlined, we'll now open the Black Box and look at the major processes inside. FOP has adopted the basic structure of the XSL-FO standard itself as a convenient model for the major processes in FOP. The Result in each row is the input for the next.
@@ -49,7 +49,7 @@ In general, each piece of data will be p
For a detailed discussion of the design of any component, follow its link in the table above. Each component outlines the design issues which have already been addressed. These resolution of these design issues is in support of the primary and secondary goals, so they are not necessarily written in stone. However, most of them have been discussed at length among the developers, and are reasonably well settled.
-## Vocabulary {#vocabulary}
+## Vocabulary { #vocabulary}
This section will attempt to provide information about any jargon used in the design documentation.
Modified: xmlgraphics/site/trunk/content/fop/dev/design/layout.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/layout.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/layout.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/layout.mdtext Thu Jul 24 16:21:20 2014
@@ -3,7 +3,7 @@ Title: Apache(tm) FOP Design: Layout
#Apache™ FOP Design: Layout
<authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors>
-## Introduction {#into}
+## Introduction { #into}
The role of the layout managers is to build the Area Tree by using the information from the FO Tree. The layout managers decide where information is placed in the area tree.
@@ -21,21 +21,21 @@ The layout process is handled by a set o
The traversal is done by the layout or structure process only in the flow elements.
-## Design Issues {#issues}
+## Design Issues { #issues}
-### Keep Layouts Simple {#issue-simple-layout}
+### Keep Layouts Simple { #issue-simple-layout}
Layout should handle floats, footnotes and keeps in a simple, straightforward way.
-### Keep ID References Simple {#issue-simple-id-refs}
+### Keep ID References Simple { #issue-simple-id-refs}
-### Render Pages ASAP {#issue-area-recycle}
+### Render Pages ASAP { #issue-area-recycle}
The issue here is that we wish to recycle the Area Tree memory as much as possible. The problem is that forward references prevent pages from being resolved until the forward references are resolved. If memory is insufficient to store unresolved pages, Area Tree fragments must be serialized until resolved.
FOP developers have discussed adding the capability of using an Area Tree to render to more than one output target in the same run, which would be a complicating factor in disposal of pages as they are rendered.
-## Layout Managers {#lm}
+## Layout Managers { #lm}
The layout managers are set up from the hierarchy of the formatting object tree. A manager represents a hierachy of area producing objects. A manager is able to handle the block area(s) that it creates and organise or split areas for page breaks.
@@ -47,7 +47,7 @@ A layout manager is essentially a bridge
The objects in the area tree that are organised by the manager will mostly contain the information about there layout such as spacing and keeps, this information will be thrown away once the layout for a page is finalised.
-## Creating Managers {#creating}
+## Creating Managers { #creating}
The managers are created by the page sequence. The top level manager is the Page manager. This asks the flow to add all managers in this page sequence.
@@ -55,13 +55,13 @@ For block level objects they have a layo
Any nested block areas or inline areas may be handled by the layout manager at a later stage.
-## Using Managers {#using}
+## Using Managers { #using}
Block area layout managers are used to create a block area, other block level managers may ask their child layout managers to create block areas which are then added to the area tree(subset).
A manager is used to add areas to a page until the page is full, then the manages contain all the information necessary to make the decision about page break and spacing. A manager can split an area that it has created will keep a status about what has been added to the current area tree.
-## Page Layout {#page}
+## Page Layout { #page}
Once the Page layout manager, belonging to the page sequence, is ready then we can start laying out each page. The page sequence will create the current page to put the page data, the next page and if it exists a last page.
@@ -75,11 +75,11 @@ This should handle the situation where t
The spacing and keep information is stored so that the area positions and sizes can be adjusted.
-## Balancing Page {#page-balance}
+## Balancing Page { #page-balance}
The page is vertically justified so that it distributes the areas on the page for the best result when considering keeps and spacing.
-## Finding Break {#finding-break}
+## Finding Break { #finding-break}
First the keeps are checked. The available space on the page may have changed due to the presence of before floats or footnotes. The page break will need to be at a height <= the available space on the page.
@@ -91,11 +91,11 @@ If the page contains before floats or fo
The before float and footnote regions are managed so that the separator regions will be present if it contains at least one area.
-## Optimising {#optimize}
+## Optimising { #optimize}
Once the areas for the page are finalised then the spacing will need to be adjusted. The available height on the page is compared with the min and max spacing. All of the spacing in all the areas on the page is then adjusted by the appropriate percentage value.
-## Multi-Column Pages {#multi-column}
+## Multi-Column Pages { #multi-column}
In the case of multi-column pages the column breaks and eventually the page break must be found in a slightly different way.
@@ -103,7 +103,7 @@ The columns need to be layed out complet
So first the complete page is layed out with all columns filled with areas and the spacing at a minimum. Then if there are any before floats or footnotes then the availabe space is adjusted. Then each the best break is found for each column starting from the first column. If any before floats or footnotes are removed as a result of the new breaks and optimised spacing then all the columns should still be layed out for the same column height.
-## Completing Page {#page-complete}
+## Completing Page { #page-complete}
After the region body has been finished the static areas can be layed out. The width of the static area is set and the height is inifinite, that is all block areas should be placed in the area and their visibility is controlled be other factors.
@@ -111,7 +111,7 @@ The area tree for the region body will c
The ordering of the area tree must be adjusted so that the areas are before, start, body, end and after in that order. The body region should be in the order before float, main then footnote.
-## Line Areas {#line-area}
+## Line Areas { #line-area}
Creating a line areas uses a similair concept. Each inline area is placed across the available space until there is no room left. The line is then split by considering all keeps and spacing.
@@ -119,7 +119,7 @@ Each word (group of adjacent character i
Once a line has been layed out for a particular width then that line is fixed for the page (except for unresolved page references).
-## Before Floats and Footnotes {#before-float-footnote}
+## Before Floats and Footnotes { #before-float-footnote}
The before float region and footnote region are handled by the page layoutmanger. These regions will handle the addition and removal of the separator regions when before floats/footnotes area added and removed.
@@ -127,7 +127,7 @@ Footnotes and Before Floats are placed i
A layout manager handles the adding and removing of footnotes/floats, this in turn effects the available space in the main reference area.
-## Side Floats {#side-float}
+## Side Floats { #side-float}
If a float anchor is present in a particular line area then the available space for that line (and other in the block) will be reduced. The side float adds to the height of the block area and this height also depends on the clear value of subsequent blocks. The keep status of the block is also effected as there must be enough space on the page to fit the side float.
@@ -135,7 +135,7 @@ Side floats alter the length of the inli
This means that the float needs to be handled by the block layout manager so that it can adjust the available inline progression dimension for the relevant line areas.
-## Unresolved Areas {#unresolved-area}
+## Unresolved Areas { #unresolved-area}
Once the layout of the page is complete there may be unresolved areas.
@@ -147,47 +147,47 @@ Each page contains a map of all unresolv
In the case of page number citations, the areas reserves the equivalent of 3 number nines in the current font. When the area is resolved then the area is adjusted to its proper size and the line area is re-aligned to accomodate the change.
-## ID and Link Areas {#id-link-area}
+## ID and Link Areas { #id-link-area}
Any formatting object that has an ID or any inline link defines an area that will be required when rendering and resolving id references.
This area is stored in the parent area and may be a shape that exists in more than one page, for example over a page break. This shape consists of the boundary of all inline (or block) areas that the shape is defined for.
-## Inline Areas {#inline-area}
+## Inline Areas { #inline-area}
This is the definition of all inline areas that will exist in the area.
-## Fixed Areas {#fixed-area}
+## Fixed Areas { #fixed-area}
instream-foreign-object, external-graphic, inline-container
These areas have a fixed width and height. They also have a viewport.
-## Stretch Areas {#stretch-area}
+## Stretch Areas { #stretch-area}
leader, inline space
These areas have a fixed height but the width may vary.
-## Character Areas {#character-area}
+## Character Areas { #character-area}
character
This is an simple character that has fixed properties according to the current font. There are implicit keeps with adjacent characters.
-## Anchor Areas {#anchor-area}
+## Anchor Areas { #anchor-area}
float anchor, footnote anchor
This area has no size. It keeps the position for footnotes and floats and has a keep with the associated inline area.
-## Unresolved Page Numbers {#unresolved-page-num}
+## Unresolved Page Numbers { #unresolved-page-num}
page-number-citation
A page number area that needs resolving, behaves as a character and has the space of 3 normal characters reserved. The size will adjust when the value is resolved.
-## Block Areas {#block-area}
+## Block Areas { #block-area}
When a block creating element is complete then it is possible to build the block area and add it to the paprent.
@@ -214,35 +214,35 @@ The block area has info about the follow
Once the layout has been finalised then this information can be discarded.
-## Page Areas {#page-area}
+## Page Areas { #page-area}
Contains inforamtion about all the block areas in the body, before area and footer area.
Has a list of the unresolved page references and a list of id refences that can be used to obtain the area associated with that id.
-## Test Cases {#test-cases}
+## Test Cases { #test-cases}
Here a few layout possibilities areas explored to determine how the layout process will handle these situations.
-### Simple Pages {#test-simple}
+### Simple Pages { #test-simple}
All blocks (including nested) are placed on the page with minimum spacing and the last block has the minimum number of lines past the page end. The lowest keep value is then found within the body area limits. Then the next equally low keep is found to determine if the spacing will be closer to the optimum values.
-### Before Floats/Footnotes {#test-before-float-footnote}
+### Before Floats/Footnotes { #test-before-float-footnote}
After filling the page with the block areas then the new body height is used to find the best position to break. Before each line area or block area is remove any associated before floats and footnotes are removed. This will then adjust the available space on the page and may allow for a different breaking point. Areas are removed towards the new breaking point until the areas fit on the page. When finding the optimum spacing the removal of before floats and footnotes must also be onsidered.
-### Multicolumn {#test-multi-column}
+### Multicolumn { #test-multi-column}
First the page is filled with all columns for the intial page area. Then each column is adjusted for the new height starting from the first column. The best break for the column is found then the next column is considered, any left over areas a pre-pended to the next column. Once all the columns are finished then all the columns are adjusted to fit in the same height columns. This handles the situation where before floats or footnotes may have been removed.
-### Last Page {#test-last-page}
+### Last Page { #test-last-page}
If in the process of adding areas to a page it is found that there are no more areas in the flow then this page will need to be changed to the last page (if applicable). The areas are then placed on a last page.
-## Status {#status}
+## Status { #status}
-### To Do {#status-todo}
+### To Do { #status-todo}
| Task | Priority | Notes |
|------|----------|-------|
@@ -264,6 +264,6 @@ If in the process of adding areas to a p
| Fine-tuning all other borders | Low | Not sure what Joerg means by this, border collapse priorties? Dashed and dotted borders have been implemented in PDF |
| BIDI support | Low | |
-### Work in Progress {#status-wip}
+### Work in Progress { #status-wip}
-### Completed {#status-complete}
+### Completed { #status-complete}
Modified: xmlgraphics/site/trunk/content/fop/dev/design/optimise.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/optimise.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/optimise.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/optimise.mdtext Thu Jul 24 16:21:20 2014
@@ -3,7 +3,7 @@ Title: Apache(tm) FOP Design: Optimisati
#Apache™ FOP Design: Optimisations
<authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors>
-## Introduction {#intro}
+## Introduction { #intro}
Apache™ FOP should be able to handle very large documents. A document can be supplied using SAX and the information should be passed entirely through the system, from fo elements to rendered output as soon as possible.
Modified: xmlgraphics/site/trunk/content/fop/dev/design/parsing.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/parsing.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/parsing.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/parsing.mdtext Thu Jul 24 16:21:20 2014
@@ -3,11 +3,11 @@ Title: Apache(tm) FOP Design: Input Pars
#Apache™ FOP Design: Input Parsing
-## Introduction {#intro}
+## Introduction { #intro}
Parsing is the process of reading the XSL-FO input and making the information in it available to Apache™ FOP.
-## SAX for Input {#input}
+## SAX for Input { #input}
The two standard ways of dealing with XML input are SAX and DOM. SAX basically creates events as it parses an XML document in a serial fashion; a program using SAX (and not storing anything internally) will only see a small window of the document at any point in time, and can never look forward in the document. DOM creates and stores a tree representation of the document, allowing a view of the entire document as an integrated whole. One issue that may seem counter-intuitive to some new FOP developers, and which has from time to time been contentious, is that FOP uses SAX for input. (DOM can be used as input as well, but it is converted into SAX events before entering FOP, effectively negating its advantages).
@@ -22,7 +22,7 @@ See the [Input Section of the User Embed
FOP's [FO Tree Mechanism](fotree.html) is responsible for catching the SAX events and processing them.
-## Validation {#validation}
+## Validation { #validation}
If the input XML is not well-formed, that will be reported.
@@ -30,7 +30,7 @@ There is no DTD for XSL-FO, so no formal
The SAX handler will report an error for unrecognized [namespaces](#namespaces).
-## Namespaces {#namespaces}
+## Namespaces { #namespaces}
To allow for extensions to the XSL-FO language, FOP provides a mechanism for handling foreign namespaces.
@@ -38,13 +38,13 @@ See [User Extensions](../../trunk/extens
See [Developer Extensions](../extensions.html) for a discussion of the mechanisms in place to allow developers to add their own extensions, including how to tell FOP about the foreign namespace.
-## Status {#status}
+## Status { #status}
-### To Do {#status-todo}
+### To Do { #status-todo}
-### Work In Progress {#status-wip}
+### Work In Progress { #status-wip}
-### Completed {#status-complete}
+### Completed { #status-complete}
- better handling of unknown xml and xml from an unknown namespace
Modified: xmlgraphics/site/trunk/content/fop/dev/design/pdf-library.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/pdf-library.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/pdf-library.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/pdf-library.mdtext Thu Jul 24 16:21:20 2014
@@ -3,17 +3,17 @@ Title: Apache(tm) FOP Design: PDF Librar
#Apache™ FOP Design: PDF Library
-## Introduction {#intro}
+## Introduction { #intro}
The PDF Library is an independant package of classes in Apache™ FOP. These class provide a simple way to construct documents and add the contents. The classes are found in `org.apache.fop.pdf.*`.
-## PDF Document {#PDF-Document}
+## PDF Document { #PDF-Document}
This is where most of the document is created and put together.
It sets up the header, trailer and resources. Each page is made and added to the document. There are a number of methods that can be used to create/add certain PDF objects to the document.
-## Building PDF {#Building-PDF}
+## Building PDF { #Building-PDF}
The PDF Document is built by creating a page for each page in the Area Tree.
@@ -27,25 +27,25 @@ It has a separate object for the image d
The java objects that represent a pdf object implement a method that returns the markup for inserting into a stream. The method is: byte[] toPDF().
-## Features {#Features}
+## Features { #Features}
-### Fonts {#Fonts}
+### Fonts { #Fonts}
Support for embedding fonts and using the default Acrobat fonts.
-### Images {#Images}
+### Images { #Images}
Images can be inserted into a page. The image can either be inserted as a pixel map or directly insert a jpeg image.
-### Stream Filters {#Stream-Filters}
+### Stream Filters { #Stream-Filters}
A number of filters are available to encode the pdf streams. These filters can compress the data or change it such as converting to hex.
-### Links {#Links}
+### Links { #Links}
A pdf link can be added for an area on the page. This link can then point to an external destination or a position on any page in the document.
-### Patterns {#Patterns}
+### Patterns { #Patterns}
The fill and stroke of graphical objects can be set with a colour, pattern or gradient.
Modified: xmlgraphics/site/trunk/content/fop/dev/design/properties.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/properties.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/properties.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/properties.mdtext Thu Jul 24 16:21:20 2014
@@ -3,11 +3,11 @@ Title: Apache(tm) FOP Design: Properties
#Apache™ FOP Design: Properties
<authors><person email="" name="Karen Lease"></person></authors>
-## Introduction {#intro}
+## Introduction { #intro}
As the input XSL-FO is being parsed and the FO Tree is being built, the attributes of the FO elements are passed by the parser to the related FO object. The java object that represent the FO object then converts the attributes into properties that are stored in the FO Tree.
-## Issues {#issues}
+## Issues { #issues}
The following are some issues when dealing with properties:
@@ -22,7 +22,7 @@ The following are some issues when deali
- Expressions: XSL-FO expressions can be included in properties.
-## Overview of Processing {#process-overview}
+## Overview of Processing { #process-overview}
The general flow of property processing is as follows:
@@ -33,13 +33,13 @@ The general flow of property processing
- FObj.handleAttrs then cross-references the returned PropertyList with the FObj, creates a PropertyManager to facilitate downstream processing of the PropertyList, and handles the special case of the writing-mode property.
-## PropertyListBuilder {#plb}
+## PropertyListBuilder { #plb}
Each plb object contains a hash of property names and *their* respective Makers. It may also contain element-specific property maker hashes; these are based on the *local name* of the flow object, ie. *table-row*, not *fo:table-row*. If an element-specific property mapping exists, it is preferred to the generic mapping.
The PLB loops through each attribute in the list, finds an appropriate "Maker" for it, then calls the Maker to convert the attribute value into a Property object of the correct type, and stores that Property in the PropertyList.
-## Property datatypes {#datatypes}
+## Property datatypes { #datatypes}
The property datatypes are defined in the org.apache.fop.datatypes package, except Number and String which are java primitives. The FOP datatypes are:
@@ -66,7 +66,7 @@ The Property class provides a "wrapper"
The base Property class defines accessor methods for all FO property datatypes, such as getNumber(), getColorType(), getSpace(), getEnum(), etc. It doesn't define accessors for SVG types, since these are handled separately (at least for now.) In the base Property class, all of these methods return null, except getEnum which returns 0. Individual subclasses return a value of the appropriate type, such as Length or ColorType. A subclass may also choose to return a reasonable value for other accessor types. For example, a SpaceProperty will return the optimum value if asked for a Length.
-## Property Makers {#makers}
+## Property Makers { #makers}
The Property class contains a nested class called *Maker*. This is the base class for all other property Makers. It provides basic framework functionality which is overridden by the code generated by properties.xsl from the *properties.xml files. In particular it provides basic expression evaluation, using PropertyParser class in the org.apache.fop.fo.expr package.
@@ -76,11 +76,11 @@ For each generic or specific property de
The PLB finds a "Maker" for the property based on the attribute name and the element name. Most Makers are generic and handle the attribute on any element, but it's possible to set up an element-specific property Maker. The attribute name to Maker mappings are automatically created during the code generation phase by processing the XML property description files.
-## Processing the attribute list {#attribute-list}
+## Processing the attribute list { #attribute-list}
The PLB first looks to see if the font-size property is specified, since it sets up relative units which can be used in other property specifications. Each attribute is then handled in turn. If the attribute specifies part of a compound property such as space-before.optimum, the PLB looks to see if the attribute list also contains the "base" property (space-before in this case) and processes that first.
-## How the Property Maker works {#maker-design}
+## How the Property Maker works { #maker-design}
There is a family of Maker objects for each of the property datatypes, such as Length, Number, Enumerated, Space, etc. But since each Property has specific aspects such as whether it's inherited, its default value, its corresponding properties, etc. there is usually a specific Maker for each Property. All these Maker classes are created during the code generation phase by processing (using XSLT) the XML property description files to create Java classes.
@@ -94,7 +94,7 @@ If the returned Property value is of the
Some kinds of property values can't be fully resolved during FO tree building because they depend on layout information. This is the case of length values specified as percentages and of the special proportional-column-width(x) specification for table-column widths. These are stored as special kinds of Length objects which are evaluated during layout. Expressions involving "em" units which are relative to font-size _are_ resolved during the FO tree building however.
-## Structure of the PropertyList {#property-list-struct}
+## Structure of the PropertyList { #property-list-struct}
The PropertyList extends HashMap and its basic function is to associate Property value objects with Property names. The Property objects are all subclasses of the base Property class. Each one simply contains a reference to one of the property datatype objects. Property provides accessors for all known datatypes and various subclasses override the accessor(s) which are reasonable for the datatype they store.
@@ -105,11 +105,11 @@ If the property is a writing-mode relati
Otherwise, the writing-mode relative value is returned if it's explicitly set. If the property is inherited, the process repeats using the PropertyList of the FO's parent object. (This is easy because each PropertyList points to the PropertyList of the nearest ancestor FO.) If the property isn't inherited or no value is found at any level, the initial value is returned.
-## Implementing Standard Properties {#property-spec}
+## Implementing Standard Properties { #property-spec}
Because the properties defined in the standard are basically static, FOP currently builds the source code for the related Property classes from an XML data file. All properties are specified in src/codegen/foproperties.xml. The related classes are created automatically during the build process by applying an XSLT stylesheet to the foproperties.xml file.
-### Generic properties {#generic}
+### Generic properties { #generic}
In the properties xml files, one can define generic property definitions which can serve as a basis for individual property definitions. There are currently several generic properties defined in foproperties.xml. An example is GenericColor, which defines basic properties for all ColorType properties. Since the generic specification doesn't include the inherited or default elements, these should be set in each property which is based on GenericColor. Here is an example:
@@ -133,17 +133,17 @@ A generic class may also be hand-coded,
This is illustrated by the SVG properties, most of which use one of the Property subclasses defined in the *org.apache.fop.svg* package. Although all of these properties are now declared in svgproperties.xml, no specific classes are generated. Classes are only generated for those SVG properties which are not based on generic classes defined in svg.
-### Element-specific properties {#element-specific}
+### Element-specific properties { #element-specific}
Properties may be defined for all flow objects or only for particular flow objects. A PropertyListBuilder object will always look first for a Property.Maker for the flow object before looking in the general list. These are specified in the `element-property-list` section of the properties.xml files. The `localname` element children of this element specify for which flow-object elements the property should be registered.
*NOTE*: All the properties for an object or set of objects must be specified in a single element-property-list element. If the same localname appears in several element lists, the later set of properties will hide the earlier ones! Use the *ref* functionality if the same property is to be used in different sets of element-specific mappings.
-### Reference properties {#reference}
+### Reference properties { #reference}
A property element may have a type attribute with the value `ref`. The content of the *name* child element is the name of the referenced property (not its class-name!). This indicates that the property specification has already been given, either in this same specification file or in a different one (indicated by the `family` attribute). The value of the family attribute is *XX* where the file *XXproperties.xml* defines the referenced property. For example, some SVG objects may have properties defined for FO. Rather than defining them again with a new name, the SVG properties simply reference the defined FO properties. The generating mapping for the SVG properties will use the FO Maker classes.
-### Corresponding properties {#corresponding}
+### Corresponding properties { #corresponding}
Some properties have both *absolute* and *writing-mode-relative* forms. In general, the absolute forms are equivalent to CSS properties, and the writing-mode-relative forms are based on DSSSL. FO files may use either or both forms. In FOP code, a request for an absolute form will retrieve that value if it was specified on the FO; otherwise the corresponding relative property will be used if it was specified. However, a request for a relative form will only use the specified relative value if the corresponding absolute value was *not* specified for that FO.
@@ -151,7 +151,7 @@ Corresponding properties are specified i
*NOTE*: most current FOP code accesses the absolute variants of these properties, notably for padding, border, height and width attributes. However it does use start-indent and end-indent, rather than the "absolute" margin properties.
-## Mapping {#mapping}
+## Mapping { #mapping}
The XSL script `propmap.xsl` is used to generate property mappings based on both foproperties.xml and svgproperties.xml. The mapping classes in the main fop packages simply load these automatically generated mappings. The mapping code still uses the static "maker" function of the generated object to obtain a Maker object. However, for all generated classes, this method returns an instance of the class itself (which is a subclass of Property.Maker) and not an instance of a separate nested Maker class.
@@ -159,13 +159,13 @@ For most SVG properties which use the SV
The property generation also handles element-specific property mappings as specified in the properties XML files.
-## Enumerated values {#enumerated}
+## Enumerated values { #enumerated}
For any property whose datatype is `Enum` or which contains possible enumerated values, FOP code may need to access enumeration constants. These are defined in the interfaces whose name is the same as the generated class name for the property, for example `BorderBeforeStyle.NONE`. These interface classes are generated by the XSL script `enumgen.xsl`. A separate interface defining the enumeration constants is always generated for every property which uses the constants, even if the constants themselves are defined in a generic class, as in BorderStyle.
If a subproperty or component of a compound property has enumerated values, the constants are defined in a nested interface whose name is the name of the subproperty (using appropriate capitalization rules). For example, the keep properties may have values of AUTO or FORCE or an integer value. These are defined for each kind of keep property. For example, the keep-together property is a compound property with the components within-line, within-column and within-page. Since each component may have the values AUTO or FORCE, the KeepTogether interface defines three nested interfaces, one for each component, and each defines these two constants. An example of a reference in code to the constant is `KeepTogether.WithinPage.AUTO`.
-## Compound property types {#compound}
+## Compound property types { #compound}
Some XSL FO properties are specified by compound datatypes. In the FO file, these are defined by a group of attributes, each having a name of the form `property.component`, for example `space-before.minimum`. These are several compound datatypes:
@@ -182,10 +182,10 @@ These are described in the properties.xm
Specific datatype classes exist for each compound property. Each component of a compound datatype is itself stored as a Property object. Individual components may be accessed either by directly performing a get operation on the name, using the "dot" notation, eg. `get("space-before.optimum")` ; or by using an accessor on the compound property, eg. `get("space-before").getOptimum()`. In either case, the result is a Property object, and the actual value may be accessed (in this example) by using the "getLength()" accessor.
-## Refinement {#refine}
+## Refinement { #refine}
The **Refinement** step is part of reading and using the properties which may happen immediately or during the layout process. FOP does not currently use a separate Refinement process, but tends to handle refining steps as the FO Tree is built.
-## Refined FO Tree {#refined-fo-tree}
+## Refined FO Tree { #refined-fo-tree}
The Refined FO Tree is the result of the Refinement process.
Modified: xmlgraphics/site/trunk/content/fop/dev/design/renderers.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/renderers.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/renderers.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/renderers.mdtext Thu Jul 24 16:21:20 2014
@@ -3,7 +3,7 @@ Title: Apache(tm) FOP Design: Renderers
#Apache™ FOP Design: Renderers
<authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors>
-## Introduction {#intro}
+## Introduction { #intro}
A renderer is primarily designed to convert a given area tree into the output document format. It should be able to produce pages and fill the pages with the text and graphical content. Usually the output is sent to an output stream.
@@ -13,33 +13,33 @@ Each renderer is given an area tree to r
The renderer will be given each page as it is ready and an output stream to write the data out. All pages are supplied in the order they appear in the document. In order to save memory it is possble to render the pages out of order. Any page that is not ready to be rendered is setup by the renderer first so that it can reserve a space or reference for when the page is ready to be rendered.The renderer is responsible for managing the output format and associated data and flow.
-## Design Issues {#issues}
+## Design Issues { #issues}
-### Renderers are Responsible {#issue-renderers-responsible}
+### Renderers are Responsible { #issue-renderers-responsible}
Each renderer is totally responsible for its output format.
-### Send Output to a Stream {#issue-output-stream}
+### Send Output to a Stream { #issue-output-stream}
-## Fonts {#fonts}
+## Fonts { #fonts}
Because font metrics (and therefore layout) are obtained in two different ways depending on the renderer, the renderer actually sets up the fonts being used. The font metrics are used during the layout process to determine the size of characters.
-## Render Context {#context}
+## Render Context { #context}
The render context is used by handlers. It contains information about the current state of the renderer, such as the page, the position, and any other miscellanous objects that are required to draw into the page.
-## XML Handling {#XML-Handling}
+## XML Handling { #XML-Handling}
A document may contain information in the form of XML for an image or instream foreign object. This XML is handled through the user agent. A standard extension for PDF is the SVG handler.
If there is XML in the SVG namespace it is given to the handler which renders the SVG into the pdf document at the given location. This separation means that other XML handlers can easily be added.
-## Extensions {#Extensions}
+## Extensions { #Extensions}
Document level extensions are handled with an extension handler. This handles the information from the AreaTree and adds renders it to the document. An example is the pdf bookmarks. This information first needs to have all references resolved. Then the extension handler is ready to put the information into the pdf document.
-## Renderer Implementations {#implement}
+## Renderer Implementations { #implement}
| Name | Type | Font Source | Font Embedding? | Out of Order Rendering? | Notes |
|------|------|-------------|-----------------|-------------------------|-------|
@@ -54,7 +54,7 @@ Document level extensions are handled wi
| RTF | Structural | N/A | N/A | No | Structural format uses a different rendering mechanism. |
| MIF | Structural | N/A | N/A | No | Structural format uses a different rendering mechanism. |
-## Adding a Renderer {#add}
+## Adding a Renderer { #add}
You can add other renderers by implementing the Renderer interface. However, the AbstractRenderer does most of what is needed, including iterating through the tree parts, so it is probably better to extend this. This means that you only need to implement the basic functionality such as text, images, and lines. AbstractRenderer's methods can easily be overridden to handle things in a different way or do some extra processing.
@@ -86,17 +86,17 @@ A renderer implementation does the follo
- draw various lines and rectangles
-## Multiple Renderers {#multiple}
+## Multiple Renderers { #multiple}
The layout of the document depends mainly on the font being used. If two renderers have the same font metrics then it is possible to use the same Area Tree to render both. This can be handled by the AreaTree Handler.
-## Status {#status}
+## Status { #status}
-### To Do {#status-todo}
+### To Do { #status-todo}
-### Work In Progress {#status-wip}
+### Work In Progress { #status-wip}
-### Completed {#status-complete}
+### Completed { #status-complete}
- new renderer model
Modified: xmlgraphics/site/trunk/content/fop/dev/design/startup.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/startup.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/startup.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/startup.mdtext Thu Jul 24 16:21:20 2014
@@ -3,13 +3,13 @@ Title: Apache(tm) FOP Design: Startup, E
#Apache™ FOP Design: Startup, Environment, Control
-## Introduction {#intro}
+## Introduction { #intro}
Startup is the process of getting Apache™ FOP bootstrapped and creating basic objects. Environment includes acquiring user options, instantiating any frameworks, setting up logging, etc. Control includes the basic logic for tieing the various subsystems together properly.
-## Status {#status}
+## Status { #status}
-### To Do {#status-todo}
+### To Do { #status-todo}
- avalon integration - logging, configuration, component management, caching, uri resolver
@@ -23,9 +23,9 @@ Startup is the process of getting Apache
- better commandline handling
-### Work In Progress {#status-wip}
+### Work In Progress { #status-wip}
-### Completed {#status-complete}
+### Completed { #status-complete}
- **better image handling** - redone so it can use a cache and synchronizes properly only on the current image while loading
Modified: xmlgraphics/site/trunk/content/fop/dev/design/svg.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/svg.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/svg.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/svg.mdtext Thu Jul 24 16:21:20 2014
@@ -3,7 +3,7 @@ Title: Apache(tm) FOP Design: SVG
#Apache™ FOP Design: SVG
-## Introduction {#intro}
+## Introduction { #intro}
SVG is rendered through Apache™ Batik.
@@ -17,7 +17,7 @@ This creates the necessary PDF informati
Most of the work is done in the PDFGraphics2D class. There are also a few bridges that are plugged into batik to provide different behaviour for some SVG elements.
-## Text Drawing {#Text-Drawing}
+## Text Drawing { #Text-Drawing}
Normally batik converts text into a set of curved shapes.
@@ -27,23 +27,23 @@ To handle this there is a PDFTextElement
Text is considered simple if the font is available, the font size is useable and there are no tspans or other complications. This can make the resulting PDF significantly smaller.
-## PDF Links {#PDF-Links}
+## PDF Links { #PDF-Links}
To support links in PDF another batik element bridge is used. The PDFAElementBridge creates a PDFANode which inserts a link into the PDF document via the PDFGraphics2D.
Since links are positioned on the page without any transforms then we need to transform the coordinates of the link area so that they match the current position of the a element area. This transform may also need to account for the svg being positioned on the page.
-## Images {#Images}
+## Images { #Images}
Images are normally drawn into the PDFGraphics2D. This then creates a bitmap of the image data that can be inserted into the PDF document.
As PDF can support jpeg images then another element bridge is used so that the jpeg can be directly inserted into the PDF.
-## PDF Transcoder {#PDF-Transcoder}
+## PDF Transcoder { #PDF-Transcoder}
Batik provides a mechanism to convert SVG into various formats. Through FOP we can convert an SVG document into a single paged PDF document. The page contains the SVG drawn as best as possible on the page. There is a PDFDocumentGraphics2D that creates a standalone PDF document with a single page. This is then drawn into by batik in the same way as with the PDFGraphics2D.
-## Other Outputs {#Other-Outputs}
+## Other Outputs { #Other-Outputs}
When rendering to AWT the SVG is simply drawn onto the awt canvas using batik.
Modified: xmlgraphics/site/trunk/content/fop/dev/design/useragent.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/design/useragent.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/design/useragent.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/design/useragent.mdtext Thu Jul 24 16:21:20 2014
@@ -3,7 +3,7 @@ Title: Apache(tm) FOP Design: User Agent
#Apache™ FOP Design: User Agent
<authors><person email="keiron@aftexsw.com" name="Keiron Liddle"></person></authors>
-## Introduction {#intro}
+## Introduction { #intro}
Technically the user agent is Apache™ FOP in the role of determining the output format and when resolving various attributes. The user agent is represented by a class that is available to others to specify how FOP should behave.
Modified: xmlgraphics/site/trunk/content/fop/dev/doc.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/doc.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/doc.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/doc.mdtext Thu Jul 24 16:21:20 2014
@@ -4,7 +4,7 @@ Title: Apache(tm) FOP Development: Manag
<warning>This page is obsolete. Do not follow this to make FOP documentation.</warning>
-## General Information {#general}
+## General Information { #general}
All raw documentation content is managed in the Apache™ FOP SVN repository. Updates should be committed to the repository, then the repository files are used to generate usable output. The remaining discussions on this page assume that the SVN repository is the starting place for processing. The path to the documentation is src/documentation/content/xdocs.
@@ -12,26 +12,26 @@ All raw documentation content is managed
Basic documents are stored in XML files, and use DTDs provided by Apache Forrest.
-## Design Principles {#design}
+## Design Principles { #design}
These principles are not written in stone, but reflect the current philosophy, and are documented here primarily to help achieve consistency. These principles should be changed if better or more practical ones are found, but they should probably be discussed and changed by common consent.
-### Where {#where}
+### Where { #where}
- To the extent possible, keep user content separate from developer content, primarily so the user doesn't have to filter out technical information.
- To the extent possible, try to document a topic exactly once, in the place the user is most likely to look for it, then link to that from other locations as appropriate. This is somewhat contrary to the principle above, which should be applied as a higher priority.
-### When {#design-when}
+### When { #design-when}
The documentation and the product are in a constant state of change, and there is some difficulty in deciding what product state the website content should reflect. The current thinking is that the website should reflect the current state of the repository code branch from which releases are made. Features or other documentation that applies to unreleased code should be marked in such a way within the content that the user can determine whether and how it applies to the version they are using. For example, "Feature xyz is first available in Release n.nn.n".
Other approaches were considered, but all seemed to have significantly higher costs both to the users and the developers. From the user's standpoint, the choice is either that they potentially have to look multiple places to get the information they need (which was rejected), or they have to filter out an occasional feature that is in code available subsequent to their release (which was accepted).
-## Website {#web}
+## Website { #web}
-### Background {#web-background}
+### Background { #web-background}
The FOP web site and documentation are generated using [Apache Forrest](http://forrest.apache.org).
@@ -45,7 +45,7 @@ The following table summarizes the flow
<note>Server-side ForrestBot is currently not available for website publishing. We use it locally and with manual invocation.</note>
-### ForrestBot "publish" Step-by-Step {#web-forrestbot-publish}
+### ForrestBot "publish" Step-by-Step { #web-forrestbot-publish}
We're using ForrestBot for build and deploy the FOP website. ForrestBot comes with Apache Forrest 0.8. The root directory of your FOP checkout contains the file "publish.xml" which is an Ant build file that manages the build and the deployment of the FOP website. Please look into this file for further instructions to set up ForrestBot on your machine. Basically, we're simply running ForrestBot manually by typing "ant -f publish.xml" once we're happy with our changes to the site. Step-by-step instructions for the deployment process again:
@@ -61,7 +61,7 @@ We're using ForrestBot for build and dep
The reason for putting the generated website in the SVN repository: The infrastructure people want to be able to restore the websites themselves in case of a crash.
-### Using a Local Forrest {#web-local-forrest}
+### Using a Local Forrest { #web-local-forrest}
To use a local Forrest (during website development, not for deployment):
@@ -79,13 +79,13 @@ To use a local Forrest (during website d
<note>You can use "forrest run" to start a local web server. That improves development speed as you can simply refresh in the browser after a change.</note>
-### Updating Distribution Files {#distribution}
+### Updating Distribution Files { #distribution}
The Apache distribution system mirrors distributions around the world. Since it uses [Apache httpd](http://httpd.apache.org/) Module [mod_autoindex](http://httpd.apache.org/docs/2.2/mod/mod_autoindex.html#headername) you also need to manually update the HEADER.html & READER.html files on `people.apache.org` in `/www/www.apache.org/dist/xmlgraphics/fop/`.
Please be careful when doing stuff like that.
-### Deleting Documentation Files {#delete}
+### Deleting Documentation Files { #delete}
ForrestBot simply uploads the whole generated site. It doesn't delete obsolete files. You can do that manually in the /www/xmlgraphics.apache.org/fop folder on cvs.apache.org. Be careful when doing stuff like that.
Modified: xmlgraphics/site/trunk/content/fop/dev/extensions.mdtext
URL: http://svn.apache.org/viewvc/xmlgraphics/site/trunk/content/fop/dev/extensions.mdtext?rev=1613173&r1=1613172&r2=1613173&view=diff
==============================================================================
--- xmlgraphics/site/trunk/content/fop/dev/extensions.mdtext (original)
+++ xmlgraphics/site/trunk/content/fop/dev/extensions.mdtext Thu Jul 24 16:21:20 2014
@@ -3,7 +3,7 @@ Title: Apache(tm) FOP Development: Addin
#Apache™ FOP Development: Adding an Extension
-## Overview {#overview}
+## Overview { #overview}
For documentation of standard Apache™ FOP extensions, see the [User FOP Extensions](../trunk/extensions.html) document.
@@ -18,7 +18,7 @@ There are three types of extensions poss
- an fo extension that creates an area in the area tree where normal xsl:fo is not possible
-## Adding Your Own {#adding}
+## Adding Your Own { #adding}
To add your own extension you need to do the following things.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: commits-help@xmlgraphics.apache.org