xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: XML Graphics common components
Date Wed, 09 Mar 2005 08:35:22 GMT

On 08.03.2005 21:12:05 Simon Pepping wrote:
> Hi,
> 
> These are two reactions to the XML Graphics common components wiki
> page, other than the issue of the transcoders.
> 
> 1. I do not like the term axgc; it makes sense in the apache
>    organisation, but it is not a good name. The name used by Chris,
>    xmlgraphics-commons.jar, is better. A real name would be best of
>    course, but I do not have one.

I don't care so much what name to take. Either suits me.

> 2. I very much like the idea that modules such as
>    PDFDocumentGraphics2D and PSDocumentGraphics2D become useful in
>    other contexts than FOP alone.

This comment and Peter's question on fop-dev got me thinking about
something that plays into the issue of placing the PDF and PS
transcoders. Given that the naked PDF(Document)Graphics2D classes are
useful stand-alone (i.e. without dependencies on Batik) it would be
worth thinking if we should put only the parts into the common area that
are not dependent on Batik.

The problem is that there are some extensions in PDFGraphics2D to handle
special Batik-proprietary patterns paints. Either we have to have a
subclass of PDFDocumentGraphics2D in Batik which adds this functionality
or create some kind of plug-in (which I would prefer because Batik uses
PDFDocumentGraphics2D while FOP uses PDFGraphics2D). Separating this
part would ease my sorrows about control over the code but obviously
also make maintenance a bit difficult (because of the separation). At
any rate there's no problem with mutual dependencies like if the whole
transcoder would be separated and we would have an obvious place for the
JPS StreamPrintService implementations for PDF and PS. What's unclear to
me is the package structure in this case. Ideas? Opinions?

That separation would create the following tasks:
- org.apache.batik.ext.awt.g2d.AbstractGraphics2D needs to go to the
common area. It has no dependencies on Batik itself.
- Light-weight plug-in for handling the Batik-specific pattern paints 
(code in Batik).


Jeremias Maerki


---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message