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
