Re: Transcoders

2003-03-13 Thread Jeremias Maerki
I've added a Wiki page dedicated to our transcoders:
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPBatikTranscoders


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



Re: Transcoders

2003-03-13 Thread Jeremias Maerki
+1, but PDF transcoder only for the moment and only a release candidate
first.

Let's put together a checklist of things to do for the release:
- Tag CVS
- Check and update documentation (I've recently added an example to the
  embedding examples I ported from the maintenance branch. Need to
  document that)
- Make sure it will also be advertised on the Batik site.
anything else?

PS Transcoder: Only the infrastructure is set up. The output is not so
good ATM. Stroke widths are too wide, for example. So it's not ready for
release, yet.

I want to do an EPS transcoder, too. I'll probably start with that some
time next week.

On 14.03.2003 07:39:07 Keiron Liddle wrote:
> 
> As there is likely to be a batik beta release sometime soon what does everyone 
> feel about having at least a PDF transcoder release.
> A PS transcoder would be good if it is working okay (I have no PS viewer at the 
> moment).
> 
> Doing a release doesn't really depend on batik from our end. So if we can make a 
> release and then make that available to batik.
> 
> We will need to make a cvs tag. It will need to be decided within the next few 
> days.
> Here"s my +1
> 
> So what do others think.



Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



Transcoders

2003-03-13 Thread Keiron Liddle

As there is likely to be a batik beta release sometime soon what does everyone 
feel about having at least a PDF transcoder release.
A PS transcoder would be good if it is working okay (I have no PS viewer at the 
moment).

Doing a release doesn't really depend on batik from our end. So if we can make a 
release and then make that available to batik.

We will need to make a cvs tag. It will need to be decided within the next few 
days.
Here"s my +1

So what do others think.

Keiron.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



Re: batik transcoders

2003-03-05 Thread Jeremias Maerki
Hi Keiron

On 06.03.2003 00:45:01 Keiron Liddle wrote:

> > > 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



Re: batik transcoders

2003-03-05 Thread Keiron Liddle
Hi Jeremias,

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

That is correct.

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

That could be a good idea for the future.
For the short term just a bundling.

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

Thats fine.

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

Okay.

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

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.

> > 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



Re: batik transcoders

2003-03-05 Thread Jeremias Maerki
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



batik transcoders

2003-03-04 Thread Keiron Liddle
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]