Re: Renderers: work in progress

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Renderers: work in progress

Renaud Richardet
Bonjour,

I've cleaned the patch that I commited a long time ago, and posted a
new one to http://issues.apache.org/bugzilla/show_bug.cgi?id=33760

Basically, I did 2 things:
- I splitted the AWTRenderer from the Java2DRenderer and did some
clean up. Hopefully, this will make Robert's work easier and cleaner.
- I also implemented the PrintRenderer, PNGRenderer and TIFFRenderer.

There are still some issues, but it basically works. I think it would
be good to polish it and commit it, and fix the remaining issues.

Here is some (internal) discussion in response to the last feedback of Jeremias.

On 3/20/05, Jeremias Maerki <[hidden email]> wrote:

>
> On 19.03.2005 02:09:46 Renaud Richardet wrote:
> > Here's my work in progress for the renderers (AWT, Print, PNG and
> > TIFF). Could you please give it a quick look at my patch [1], thanks.
>
> Before I start with my comments, let me tell you that I'm happy to see
> that you're getting the hang of it. I'm looking forward to applying a
> revised patch adressing the issues outlined below. Thanks a lot for
> helping out!
>
> > There's a few points I would like to discuss.
> >
> > I splitted the AWTRenderer from the Java2DRenderer and did some clean
> > up. I also created the PrintRenderer, PNGRenderer and TIFFRenderer.
> > Please see the class diagram at the wiki FopAndJava2D. I also
> > documented my work there.
>
> Uhm, there's a discrepancy: You have a png and tiff subpackage while I
> would have preferred a bitmap subpackage as shown on the Wiki page.

Done.
 
> Furthermore, I'd remove the JPSPrintRenderer as it might be cause for
> confusion with the PrintRenderer. It's of not much use anyway. I'd
> rather create examples in examples/embedding that show how to use the
> PrintRenderer with JPS both with normal printers and StreamPrintServices.
> I'd also rename Java2DPrintRenderer to PrintRenderer even though there's
> a class with the same name one package higher up.

Done

> I think that base
> class should rather be renamed to something less misleading. But that'll
> take some opinion-gathering first.

Still open
 
> > Renderer registration:
> > I'm unsure if I've registered the 2 new Renderers (TIFF and PNG)
> > correctly in the front-end. Could you give it a look, especially
> > RendererFactory.createFOEventHandler(), thanks.
>
> Looks ok.

Please check it again, as thing might have changed since then.
 

> > The PNG-Renderer outputs 1 picture per page (right?), so we end up
> > with several files.
> > My pragmatic approach is to let the user specify the first file name
> > on the command line (eg. "image1.png"). FOP then creates the next
> > images using the same directory and name pattern ("image2.png", ASO).
> > For this, I had to register the outfile in FOUserAgent.
> > We could offer more configuration possibilities, but I think it's
> > sufficient ATM. I don't feel like changing the front end, which looks
> > very clean and robust.
>
> I agree it's ok for now. It can always be improved as need arises.

OK
 

> > For PNG, TIFF and Print, the quality of the output is _very_ poor. Am
> > I using the right image type in
> > Java2DRenderer.getPageImage(PageViewport pageViewport) ?
> > Oleg used a TYPE_BYTE_BINARY, which seems to be the only type which
> > works with the TIFFEncoder from Batik. See
> > TIFFRenderer$LazyPageImagesIterator.next(). But the quality is poorer.
> > Any hints?
>
> Yes. Simply increase the bitmap size. Use
> FOUserAgent.getPixelUnitToMillimeter() to calculate an enhanced
> scaleFactor in Java2DRenderer.getPageImage() to support bigger
> resolutions. Default resolution is 72dpi which explains the poor quality.
> You should probably support an additional command line parameter that
> enables the user to specify the resolution for the generated image.
> Compare with [1]
>
> [1] http://barcode4j.krysalis.org/cli.html

I haven't look at it yet.
 

> > AWTRenderer:
> > I had to modify PageViewport.isResolved(), so that the flag "done" in
> > RenderPageModel.addPage() gets a chance to be set to true. The Map
> > unresolvedID is sometimes empty, but not set to null.
> > This way, the user can see the first page while the layout engine is
> > still rendering the other pages in background. Please let me know if
> > there's a better way to define isResolved().
>
> I'd have to invest more time to answer that. I'll see what I can do.
> Maybe someone else has some input here.

Please do. I only had to make 2 minor changes in PageViewport, but I'm
not certain about the implications.
 

> > PrintRenderer works somehow (with awt.PrintJob). But what I would
> > really like to do is passing the output of the PSRenderer to JPS
> > (o.a.f.render.print.JPSPrintRenderer), but that doesn't seem to work
> > on windowsXP. I'll check that on linux.
>
> It works but only if you're printing to a PostScript-enabled printer. If
> you have a PCL-only printer it doesn't work because Windows doesn't have
> a PostScript interpreter to convert the PostScript to PCL. PrintRenderer
> does exactly what it's supposed to. It has to provide a Pageable and
> Printable interface and that's it. If someone want to pipe the PS output
> from the PSRenderer through to a PostScript printer, he's welcome to do
> so but this is not FOP's job. BTW in this case the PS file is really
> just piped through 1:1 and that's exactly why the approach only works on
> PostScript-enabled printers.
 
OK

> > I put some more ant tasks on build.xml for the examples tiff and png.
> > the target examples-png is throwing a build.xml:1080:
> > java.lang.NullPointerException, and I don't understand why??
>
> These examples should go into the build.xml file in the examples/fo
> directory. This shouldn't be in the root build.xml

OK, removed
 
> > [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=33760

> One more thing: Why did you include the codecs in the patch? Can't you
> just use the ones in batik.jar? It worked fine here. If you have to make
> any modifications to the codec please create an additional patch that
> will be sent to the Batik team.

Removed (was for easier debugging)
 
> Thanks for enduring my comments and keep it up!

Thank you very much for your comments.

Regards,
Renaud

--
renaud.richardet (at) gmail (dot) com
+41 78 675 9501
www.oslutions.com
Reply | Threaded
Open this post in threaded view
|

Re: Renderers: work in progress

Jeremias Maerki

On 08.06.2005 23:16:15 Renaud Richardet wrote:
> Bonjour,
>
> I've cleaned the patch that I commited a long time ago, and posted a
> new one to http://issues.apache.org/bugzilla/show_bug.cgi?id=33760
>
> Basically, I did 2 things:
> - I splitted the AWTRenderer from the Java2DRenderer and did some
> clean up. Hopefully, this will make Robert's work easier and cleaner.
> - I also implemented the PrintRenderer, PNGRenderer and TIFFRenderer.

Great work!

> There are still some issues, but it basically works. I think it would
> be good to polish it and commit it, and fix the remaining issues.

Right. I've already done a few things.

> Here is some (internal) discussion in response to the last feedback of Jeremias.

<snip/>

> > Furthermore, I'd remove the JPSPrintRenderer as it might be cause for
> > confusion with the PrintRenderer. It's of not much use anyway. I'd
> > rather create examples in examples/embedding that show how to use the
> > PrintRenderer with JPS both with normal printers and StreamPrintServices.
> > I'd also rename Java2DPrintRenderer to PrintRenderer even though there's
> > a class with the same name one package higher up.
>
> Done
>
> > I think that base
> > class should rather be renamed to something less misleading. But that'll
> > take some opinion-gathering first.
>
> Still open

Let's leave it for now. It's not that bad. If we see a problem it is
fixed quickly.

> > > Renderer registration:
> > > I'm unsure if I've registered the 2 new Renderers (TIFF and PNG)
> > > correctly in the front-end. Could you give it a look, especially
> > > RendererFactory.createFOEventHandler(), thanks.
> >
> > Looks ok.
>
> Please check it again, as thing might have changed since then.

It's still ok.

> > > The PNG-Renderer outputs 1 picture per page (right?), so we end up
> > > with several files.
> > > My pragmatic approach is to let the user specify the first file name
> > > on the command line (eg. "image1.png"). FOP then creates the next
> > > images using the same directory and name pattern ("image2.png", ASO).
> > > For this, I had to register the outfile in FOUserAgent.
> > > We could offer more configuration possibilities, but I think it's
> > > sufficient ATM. I don't feel like changing the front end, which looks
> > > very clean and robust.
> >
> > I agree it's ok for now. It can always be improved as need arises.
>
> OK

I've made the whole thing here a bit safer and fixed a bug. I've got
some ideas here but will need some more time to do this.

> > > For PNG, TIFF and Print, the quality of the output is _very_ poor. Am
> > > I using the right image type in
> > > Java2DRenderer.getPageImage(PageViewport pageViewport) ?
> > > Oleg used a TYPE_BYTE_BINARY, which seems to be the only type which
> > > works with the TIFFEncoder from Batik. See
> > > TIFFRenderer$LazyPageImagesIterator.next(). But the quality is poorer.
> > > Any hints?
> >
> > Yes. Simply increase the bitmap size. Use
> > FOUserAgent.getPixelUnitToMillimeter() to calculate an enhanced
> > scaleFactor in Java2DRenderer.getPageImage() to support bigger
> > resolutions. Default resolution is 72dpi which explains the poor quality.
> > You should probably support an additional command line parameter that
> > enables the user to specify the resolution for the generated image.
> > Compare with [1]
> >
> > [1] http://barcode4j.krysalis.org/cli.html
>
> I haven't look at it yet.

DONE.

> > > AWTRenderer:
> > > I had to modify PageViewport.isResolved(), so that the flag "done" in
> > > RenderPageModel.addPage() gets a chance to be set to true. The Map
> > > unresolvedID is sometimes empty, but not set to null.
> > > This way, the user can see the first page while the layout engine is
> > > still rendering the other pages in background. Please let me know if
> > > there's a better way to define isResolved().
> >
> > I'd have to invest more time to answer that. I'll see what I can do.
> > Maybe someone else has some input here.
>
> Please do. I only had to make 2 minor changes in PageViewport, but I'm
> not certain about the implications.

I'll postpone this for the moment. Maybe Robert can have a look.

<snip/>

Thanks again, Renaud, for your work. FOP is again a step closer to where
I want to see it.


Jeremias Maerki