You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by fo...@xml.apache.org on 2005/01/31 11:34:56 UTC
[XML Graphics - FOP Wiki] Updated: FOPProjectTasks
Date: 2005-01-31T02:34:56
Editor: 81.221.167.213
Wiki: XML Graphics - FOP Wiki
Page: FOPProjectTasks
URL: http://wiki.apache.org/xmlgraphics-fop/FOPProjectTasks
Updates to project tasks
Change Log:
------------------------------------------------------------------------------
@@ -2,72 +2,54 @@
----
+This page contains high-level tasks for Apache FOP. If you like to help with the development, look here for ideas what to implement and notify ''fop-dev' when you're starting with such a task.
+
+(see also ["FOPWorkEstimates"])
+
= General =
-== Interfaces and frontends ==
- * '''!'''decide on course of action
- * Avalon integration
- * simplified API
+ * /!\ create a release plan once we can see that we can start releasing again.
- * complete renderer plugabillity
+== Testing ==
-== Configuration ==
+ * Create additional layout engine test cases.
+ * Create a test subsystem that allows the generated PDF, PS and Java2D/AWT output to be converted to a bitmap so it can be compared to reference bitmaps.
+== Interfaces and frontends ==
+ * complete renderer plugabillity
== AWT Viewer ==
+
* continue cleanup and improvements
* develop towards design with area tree/caching etc.
== RTF Integration ==
- * jfor... for FOP (see JforIntegrationInFop)
-== Fonts ==
- * use system fonts
- * Central font registry (renderer-independent, so multiple renderers may be used in the same run in the future)
- * clean up
- * Add parser for AFM files (Type 1 support)
- * Extend PFB parser so it can read metric data
-
-(see ["FOPFontSubsystemDesign"])
-
-----
-
-= FO Tree =
+JFOR has been integrated into FOP. Now the whole RTF support needs to be stabilized.
- * Integrate Peter's work from the Alt-Redesign branch with the trunk.
+ * Check text-decoration (it was disabled after a change in property handling for text-decoration)
-(See ["FOPAltDesignIntegration"])
+== Fonts ==
-== Issues in the alt.design code ==
- * Tidying existing structure
- * Add corresponding properties handling
- * Extend the initial handling of markers to all affected FO classes.
- * Cleaning up validation of data types
+ * work with Victor Mote to check feasibility to integrate his font subsystem from [http://foray.sf.net Foray] into FOP.
-== Accessing property values ==
- * No property objects
- * Storage of property values
- * Potential problem with static-content
+(see also ["FOPFontSubsystemDesign"])
-== Redesign of Properties ==
- * PropertiesRedesign Discussion dated 24-Nov-2003
+----
-== Extending current design ==
- * Add support for FOP extensions
+= FO Tree =
- * Tighter Area Tree integration
+ * Rewrite the layout dimension mechanism.
----
= Layout managers =
- * Finding what to layout where.
- * Bpd space hendling
- * Adding areas to area tree.
* Resolution of over-constrained documents (see ["FOPOverConstraintDesign"])
* Detailed documentation of layout system and overconstraint resolution
+(see also ["FOPWorkEstimates"])
== Layout of ==
* tables
@@ -84,14 +66,6 @@
* keeps
* layout issues
- * markers
- * adding markers when adding associated areas
- * retrieving markers from available lists
-
- * lists
- * indent positionings
-
-
* side floats
* layout with nearest reference area
* break/keep implications
@@ -99,15 +73,15 @@
== Inline areas ==
- * underline/strikethrough/overline
+
* baseline alignment
* ipd adjustment after page number resolution
== Adding Areas ==
+
* must be able to adjust spacing.
* add id/markers
- * setup area with traits: borders, background, ipd, bpd etc.
- * clear area info once area added to parent and finished
+ * check that all areas contain the proper traits
* create correct hierarchy of areas, especially for tables, spans and page regions
----
@@ -115,38 +89,38 @@
= Area Tree =
* Is all the area tree information correct.
- * Are { { { BlockViewport } } } and other viewports correct.
- * How can extra things be handled.
- * Optimistaions.
+ * Are {{{BlockViewport}}} and other viewports correct.
* Writing mode, stacking direction and orientation, width/height vs. ipb/bpd. (See ["FOPWritingModesAndBidiDesign"]).
----
= Renderers =
- * The renderer interface is used by the { { { LayoutHandler } } } and { { { AreaTree } } } for setup, page sequences and pages.
+ * The renderer interface is used by the {{{LayoutHandler}}} and {{{AreaTree}}} for setup, page sequences and pages.
* Inline areas render themselves on the Renderer.
* The abstract renderer is meant to completely handle the area tree without doing any rendering. So that renderers that subclass this only need to override those methods that require/support particular areas.
* The super methods can be used for normal area tree handling and renderer positioning.
* Check that the current renderer design is suitable and covers all areas in all situations.
* Especially make sure the clipping can be done in a way that is supported by all renderers
- * Minimal work for subclasses to override { { { AbstractRenderer } } }.
+ * Minimal work for subclasses to override {{{AbstractRenderer}}}.
* Try to port some similarities between PDF and PS renderers to a common base class.
* Avoid type casting where possible.
- * Is the { { { BlockViewport } } } handled appropriately.
- * Can different orientation and stacking directions be handled. Should document extensions have an extension handler so that user defined extension can be handled.
+ * Is the {{{BlockViewport}}} handled appropriately.
+ * Can different orientation and stacking directions be handled. Should document extensions have an extension handler so that user defined extension can be handled.
* Bring back all the other renderers: PCL, AWT, TXT
* Develop new renderers: AFP, maybe EMF
== PDF Renderer ==
- * border/line styles
- * pdf state
- * background pattern with image
+
+ * border/line styles (border painting is bad ATM)
+ * pdf state (still some improvements necessary)
* stacking directions
* Support for SVG fonts to be converted for PDF into Type 3 fonts (?)
=== PDF Library ===
+
+ * separate into a stand-alone library
* documentation
* optimisations
* some additions so it can load and read pdf documents
@@ -154,6 +128,7 @@
* encryption (partly done, needs fixing, add support for PDF 1.4 level encryption)
* Improve building of PDF dictionaries (also needed to properly finish PDF encryption for string and text entries)
* possible addition: Support of one or more of the PDF/X standards. See http://www.pdfx.info. Big question is which one(s)?
+ * possible addition: Support for tagged PDF
=== SVG support for PDF ===
@@ -161,33 +136,29 @@
Also see ["FOPBatikTranscoders"].
-== { { { PostScript } } } renderer ==
+== PostScript renderer ==
- * Resolve problem with encoding mismatch.
- * More complete SVG implementation
+ * Bring up to the same level as the PDF renderer.
* SVG text painter (basics are there)
- * Full SVG transcoder (infrastructure started, See ["FOPBatikTranscoders"])
* Provide level 2 and 3 (make configurable)
- * Add infrastructure for enabling EPS output
== SVG renderer ==
* What's the status?
-== AWT renderer ==
+== Java2D/AWT renderer ==
+ * Bring this one back to life!
* We need that one soon for the validation of the API because of the special output formats (AWT, print)
== XML renderer ==
- * improve and update xml renderer so that it can output SAX
+(no issues ATM)
----
= Miscellaneous =
-== XML Format ==
- * improve and update { { { AreaTreeBuilder } } } so that it takes SAX input
-
== SVG ==
+
* generic converter for svg to image for inserting into output (for renderers without SVG support and as an additional possibility)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-cvs-help@xml.apache.org