xmlgraphics-fop-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Xmlgraphics-fop Wiki] Update of "ImageSupport/Status" by JeremiasMaerki
Date Fri, 02 Nov 2007 21:21:08 GMT
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/ImageSupport/Status

The comment on the change is:
Recording the current progress

New page:
This page is used to track the progress of the image package rewrite.

= TO DO =

||done||Create the basic interfaces and classes: ImageManager, ImageImplRegistry, Image, ImageSource,
ImagePreloader, ImageLoader, ImageConverter and ImageConverterPipeline.||
||done||Implement Dijkstra's shortest path algorithm to construct ImageConverterPipelines.
This will automatically select the best way to acquire an image for a certain rendering situation.||
||done||Verify that the image conversion pipeline approach works.||
||done||Dynamic registration of all service provider interfaces (ImagePreloader, ImageLoader
& ImageConverter)||
||done||Select a suitable way to represent the original image source (URI & data source).
Decision: Use JAXP Source as base. ImageSource (extends Source) contains an ImageInputStream
(from ImageIO). ImageInputStream provides the "push back" functionality I mentioned in the
requirements, or rather it allows to seek back indefinitely caching the byte stream either
in memory or in a temp file.||
||done||Distinguish between local file URLs and other URLs. File URLs are converted to File
objects so ImageInputStreams can be created that operate directly on the file which makes
caching unnecessary.||
||IN PROGRESS||Reimplement Readers as ImagePreloaders for all supported formats. done: SVG,
PNG, GIF, TIFF, WMF.||
||done||Fully implement intrinsic size determination (size plus resolution) in ImagePreloaders
for PNG and TIFF. PNG using ImageIO which is now always available after switching to Java
1.4. TIFF using XML Graphics Commons' TIFF codec.||
||IN PROGRESS||Reimplement the image loading code of the old Image implementations as ImageLoaders.
done: ImageIO, Batik(SVG&WMF).||
||IN PROGRESS||Implement all necessary ImageConverters. done: SVG->G2D, WMF->G2D, G2D->BufferedImage/RenderedImage.||
||IN PROGRESS||Write unit test for as much of the functionality as possible/reasonable.||
||IN PROGRESS||Write Javadocs||
||OPEN||Verify that undecoded images (TIFF with CCITT G4, JPEG or PNG) are properly supported
by the architecture in order to have minimal memory usage and maximum performance (no more
passing around byte arrays).||
||OPEN||Implement transparent support for GZIP encoded streams.||
||OPEN||Allow SAXSource and DOMSource for XML-based images. Not implemented but generally
supported by the architecture (JAXP Source)||
||OPEN||Reimplement caching. Cache the various image flavors separately of each other. Identify
uncacheable image flavors.||
||OPEN||Make sure all streams are properly closed.||
||OPEN||Support injection of manually built Image subclasses through the Source mechanism
(meaning: act during URI resolution and build the final image (ex. as BufferedImage or Graphics2DImagePainter)
instead of providing a stream to an encoded image).||
||OPEN||Decide if the Graphics2DAdapter/Graphics2DImagePainter pair is still in the right
place (in the render package) as it is heavily used now in the image package.||
||OPEN||Integrate the new image package into the layout engine (ImageInfo/ImageSize), the
renderers (Image/ImageFlavor) and the FOP extensions.||
||OPEN||Reimplement support for baseline adjustment (for MathML)||
||OPEN||Enhance the existing penalty mechanism to allow manual fine-tuning of the conversion
decisions.||
||OPEN||Create a branch and upload what's there already for early feedback.||
||OPEN||Write some design docs on the new design.||

= Open Questions =

 * What should the final package name be? Currently, I'm working in org.apache.fop.image2
in order to keep the old one next to the new one while I'm rewriting.

 * How much focus should I put on backwards-compatibility in the renderer area? FOP extensions
could be affected. ATM, I'm not as far as to integrate the whole thing in the renderers, yet.

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


Mime
View raw message