You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Keiron Liddle <ke...@aftexsw.com> on 2003/03/05 04:18:39 UTC

batik transcoders

Hi All,

The PDF transcoder could be packaged with Batik so that it can be used by users 
of Batik only and also used independanlty from the rest of FOP.

So will there be any problems. There is the pdf-transcoder build target that 
creates the transcoder jar. We could create a tag for the release (call it beta2?).
We do need to make it clear that a FOP release cannot be used at the same time 
as this jar due to various changes.

The PDF transcoder seems to be working fine. There are a couple of problems.
Issues:
- the use of avalon Enumeration requires avalon in the path. It is only used as an 
interface for one of the font classes, do we really need that
- do we need all of the font classes for transcoding, which ones can be left out

There are some minor bugs with patterns in patterns, drawing images and fonts 
but there won't be any fixes soon.

Also what is the status of the PS transcoder? Could this be included.

Keiron

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: batik transcoders

Posted by Jeremias Maerki <de...@greenmail.ch>.
Hi Keiron

On 06.03.2003 00:45:01 Keiron Liddle wrote:
<snip/>
> > > There are some minor bugs with patterns in patterns, drawing images and 
> fonts 
> > > but there won't be any fixes soon.
> > 
> > Wouldn't it make sense to work with the Batik team to get the PDF and PS
> > transcoders into their test infrastructure so we have some good feedback
> > and can quickly improve on the quality to match the AWT output?
> 
> If I understand their testing properly, it is currently no setup in a way that could 
> handle PDF/PS output.
> They have various levels of testing: xml parsing, dom, bridge, gvt, image output 
> and various others. The image output is the one that is parallel with the PDF/PS 
> transcoding, it is done by comparing the result with a reference image stored in 
> cvs. Someone needs to know what the reference should be like. Also there are 
> PDF version/viewer version issues.
> I'll see what can be sorted out.

I see.

I was also thinking about using GhostScript for converting PostScript
and PDF files to bitmaps for testing and then calculating differential
images. Add to that a little GUI that let's you browse through a
testsuite and inspect the three bitmaps (ref, actual, differential).
This could be used for both SVG and XSL-FO stuff.


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: batik transcoders

Posted by Jeremias Maerki <de...@greenmail.ch>.
Hi Keiron

On 05.03.2003 04:18:39 Keiron Liddle wrote:
> The PDF transcoder could be packaged with Batik so that it can be used by users 
> of Batik only and also used independanlty from the rest of FOP.

You mean Batik will have pdf-transcoder.jar and ps-transcoder.jar in
their distributions? Not the source, right?

What about factoring out the code for the transcoders and supporting
classes (like fonts) into a separate container/subproject accessible by
both the FOP and Batik teams? XML-Commons, maybe? That way we could
encourage the Batik guys to participate in the future development of the
PDF- and PS-related SVG stuff. Just a thought.

> So will there be any problems. There is th/e pdf-transcoder build target that 
> creates the transcoder jar. We could create a tag for the release (call it beta2?).
> We do need to make it clear that a FOP release cannot be used at the same time 
> as this jar due to various changes.

+1. We could give the transcoders a bit more visibility on our site.

> The PDF transcoder seems to be working fine. There are a couple of problems.
> Issues:
> - the use of avalon Enumeration requires avalon in the path. It is only used as an 
> interface for one of the font classes, do we really need that

Not really at the moment. But as soon as I have this licensing issues
and an initial release of my barcode package behind me, I wanted to go
into full Avalon-refactoring mode. And that brings some more Avalon
stuff into FOP especially the renderers, fonts and image support.

I'd like to propose this:
- I'll modify the build so we can generate a raw pdf-transcoder.jar as
  it is now (needs avalon-framework.jar), but along with another
  (pdf-transcoder-all.jar) that also contains the necessary Avalon
  classes.
- I'll do the documentation involved.

> - do we need all of the font classes for transcoding, which ones can be left out

ATM the PFM parser and the apps subpackage are the only ones that can be
left out, I think.

> There are some minor bugs with patterns in patterns, drawing images and fonts 
> but there won't be any fixes soon.

Wouldn't it make sense to work with the Batik team to get the PDF and PS
transcoders into their test infrastructure so we have some good feedback
and can quickly improve on the quality to match the AWT output?

> Also what is the status of the PS transcoder? Could this be included.

I haven't set up the PS transcoder, yet. But I could do that soon. I'm
still hoping for George to send in a patch for his PostScript work.

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org