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 Apache Wiki <wi...@apache.org> on 2005/06/26 17:37:57 UTC

[Xmlgraphics-fop Wiki] Update of "ApiRequirements" by JeremiasMaerki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.

The following page has been changed by JeremiasMaerki:
http://wiki.apache.org/xmlgraphics-fop/ApiRequirements

The comment on the change is:
Updated my view

New page:
This page describes the requirements for FOP's end-user API. The hard requirements listed and agreed to here should be met by the time the first preview release of 1.0 is published.

''Content here has been mostly taken from the older FOPAvalonization page and updated.''

= Hard requirements =

||HR1||consistent, easy to understand, to use, to configure||
||HR2||easy to integrate into other systems (especially Cocoon, using a passive SAX-based approach, see {{getDefaultHandler()}})||
||HR3||appeal to both novice users and expert developers||
||HR4||well documented behaviour||
||HR5||little overhead||
||HR6||thread-safe||
||HR7||logging to any logging mechanism||
||HR8||Programmatically evaluatable feedback from the layout process per processing run (overflows, validation feedback, notifications on page creation, new page-sequences etc.). Note: This is different from the logging aspect which is used for debugging purposes and log output may not be separatable by processing run.||
||HR9||provide for all configuration aspects (fonts, extensions etc)||
||HR10||Support for XML Resolver and special-purpose URI Resolvers||
||HR11||widely acceptable configuration defaults||
||HR12||use well known design and usage patterns (example: reused elements from JAXP wherever possible)||
||HR13||several example classes demonstrating the use of FOPs API||
||HR14||automatic plug-in mechanism for extensions||
||HR15||Reuse configuration and caches for multiple processing runs while supporting different configurations in one VM (differentiate between engine configuration and per-document configuration)||

= Wish list =

||WL1||automatic plug-in mechanism for renderers and FO event handlers (with the ability to override an existing renderer for a given MIME type. No client code changes should be necessary.||
||WL2||At least partial compatibility with FOP 0.20.5 to ease the migration. (Alternative: Support for a general purpose FO processing API which allows easy switching of the implementation)||
||WL3||Serializable, modifyable intermediate format between the layout engine and the renderers (use cases: manual layout tweaking, custom modifications, [http://en.wikipedia.org/wiki/Imposition imposition (n-up)] etc.||
||WL4||Concatenation of multiple input documents to a single output file||

= Applications/wrappers/examples to be included =

 * command line application for all stream output and direct print renderers, including Swing preview
 * reusable AWT/Swing panel
 * Ant task
 * sample servlet
 * to consider: Cocoon serializer
 * to consider: Web Service

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