Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@xmlgraphics.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Subject: Re: Release coordination in XML Graphics (was: [VOTE] Release
	Apache XML Graphics Commons 1.0 and Apache FOP 0.92beta)
From: Peter West <peter.west@hp.com>
To: general@xmlgraphics.apache.org
In-Reply-To: <20060413150306.9F93.DEV@jeremias-maerki.ch>
References: <20060413114802.9F83.DEV@jeremias-maerki.ch>
	 <1144933084.4909.63.camel@sellman-r-1.hpl.hp.com>
	 <20060413150306.9F93.DEV@jeremias-maerki.ch>
Content-Type: text/plain
Date: Thu, 13 Apr 2006 15:19:08 +0100
Message-Id: <1144937948.19348.15.camel@sellman-r-1.hpl.hp.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2006-04-13 at 15:25 +0200, Jeremias Maerki wrote:
> On 13.04.2006 14:58:04 Peter West wrote:
> > On Thu, 2006-04-13 at 12:11 +0200, Jeremias Maerki wrote:
> > > Ok, I think I'm beginning to see the problem. Looking at the Commons
> > > plan on the wiki it uses the term "transcoder". That's not good. We're
> > > planning to move to the PDF and PS/EPS transcoders to Batik, not to
> > > Commons (mentioned in parantheses on the wiki page). Only the basic
> > > Graphics2D implementations will go to Commons. That will give Batik
> > > committers write access and full control over the Transcoders. FOP is
> > > not interested in the Transcoders, but it is interested in the
> > > Graphics2D implementations for handling extensions like SVG, MathML,
> > > Barcode4J etc.
> > > 
> > Ok, but I'm hazy about the pathways here. What *is* the pathway for svg
> > rendering to, say, pdf in fop?
> 
> FOP's PDFSVGHandler:
> - sets up the SVG document
> - configures the Batik-specific bridges which are used to generate
> elements that should be handled in a more specific way than is possible
> with Graphics2D (links for examples)
> - Creates a PDFGraphics2D instance that is given as paint target to
> Batik.
> - Batik is invokes to render the SVG document
> 
> Painting a barcode using Barcode4J is just slightly different but helps
> understanding the issues here:
> - The barcode extension requests a Graphics2D instance from the Renderer
> to paint on (This is just another PDFGraphics2D)
> - Barcode4J paints against the Graphics2D instance
> (no Batik-specific elements involved here)
> 
> > 
> > > The dependency tree at the end of the migration process will look like
> > > this:
> > > 
> > > - Commons depends on a minimal set of external libraries (probably only
> > > Jakarta Commons IO and JAXP)
> > > - Batik depends only on Commons, not on FOP.
> > > - FOP depends on Commons and only optionally on Batik for SVG
> > > functionality.
> > > 
> > Optionally?
> 
> That's a personal wish. IMO, the Batik dependency should evolve into an
> optional dependency (like the MathML and Barcode extensions). I can
> remember some people asking if it is possible to scale down FOP by
> removing SVG support. My main goal is to compile FOP using IKVM into a
> .NET DLL where Batik might be a problem as the Java2D support in IKVM is
> not as advanced as it could be, yet. On the other side, making Batik an
> optional dependency (as opposed to mandatory) simply enforces cleaner
> design.
> 
> > > That should eliminate most dependency problems we suffer from today. The
> > > rest is mostly talking to each other.
> > > 
> > > The big problem with this whole problem is resources. I'm doing my part
> > > in this on my own time which is limited. I don't think the Batik
> > > committers have lots of free time to move on quickly here. So, if you
> > > want to help unwinding the whole thing, you're most welcome. You're
> > > still a committer in FOP (and therefore in Commons) and you can always
> > > request write access to the repository (yours got removed during the
> > > switch to SVN).
> > 
> > Same problem here. It may come to that if I need the Graphics2D some
> > time soon.
> > 
> > > 
> > > Concerning your comments on the build files: I usually work with SVN
> > > checkouts in Eclipse (FOP referencing the Batik project and not the JAR
> > > file in the lib directory, and not using Ant to build inside the IDE).
> > > Compatibility is verified by updating the JARs in the lib directory and
> > > using the Ant builds from the command-line. I'm happy that way. But
> > > that's just how I do it.
> > > 
> > I work with NetBeans; i.e. a thin veneer over the build files. I think
> > of the build files as canonical.
> > 
> > If I understand you correctly, Batik's dependency on FOP is addressed by
> > moving the transcoders holus-bolus into Batik.
> 
> Yes.
> 
> > Meanwhile, all of the PDF
> > and PS rendering (upon which the transcoders depend), and the font
> > configuration, goes into Commons. That leaves both Batik and FOP
> > dependent on Commons. The Graphics2D implementations also go to Commons,
> > where any dependencies of either FOP or Batik on them are resolved.
> 
> Exactly.
> 
> > What use does Batik make of the Graphics2D implementations? I thought
> > they were created for Batik.
> 
> Not exclusively. Originally they were simply created to provide SVG
> support to PDF output in FOP.
> 
That's where I had it wrong.  The pathway for the barcodes makes that
clear.

> The Transcoders use the Graphics2D implementations to render the basic
> graphic elements. Special elements like links, text and more can
> optionally handled using special "bridge" classes (SVG/Batik-specific).
> 
Text which uses either the base14 or embedded fonts seems to be
rendering without invoking the bridge classes.  In general, text should
be able to be rendered through Graphics2D.  For the base14 fonts, some
extra work is required, but for fonts which are being embedded, the
bridge should not be required, should it? In fact, for base14, it is
only the co-ordination with the font configuration that's required,
isn't it?

> FOP can use the Graphics2D implementations without the Batik
> specialities to render things like MathML, barcodes, charts or whatever.
> 
> Furthermore, the Graphics2D implementations (or more specifically the
> Document*Graphics2D subclasses) can be used to create stand-alone PDF
> and EPS documents by simply painting to a Graphics2D instance. See:
> http://svn.apache.org/viewcvs.cgi/xmlgraphics/commons/trunk/examples/java/java2d/ps/EPSExample1.java?view=markup
> 
> Folio could use this approach for PDF production. You've decided to go
> the Java2D route, right? Another example: I've done a small proof-of-concept
> implementation of a JPS (Java Printing System) backend to produce PDF.
> This enables any Java application printing using JPS to produce PDF
> files. Cool, ey? :-)

Peter


---------------------------------------------------------------------
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