Jeremias,

Thanks for having a look at my patch and for your comments.

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

OK, I ll do it. 

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

OK here too. Good idea to create the examples.
 
> > I end up with a lazy rendering: Java2DRenderer only stores Viewports
> > and no Images. No actual rendering is done at this point. Page images
> > are actually rendered (with getPageImage()) when the concrete
> > renderers need them (that is: when the user wants to see a page (AWT)
> > or just before the page is encoded (PNG and TIFF) or printed. No
> > BufferedImage is stored. This way, the memory print should be reduced.
> > Is this approach OK? Could there be some thread issues?
> 
> Yes, it's ok, although for me it's not always clear that you can always
> tell which approach takes more memory, especially if you're able to
> release FO and area tree memory. It may even be necessary for bigger
> documents to temporarily serialize the area tree.
> 
> I don't see any threading issues as (and when) the renderers all run in
> the main thread.

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

Thanks, I'll try that. 
What about the image type? (TYPE_??) Which one fits the picture?

> > 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, now I see.
 
> 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.

Oh yes, I forgot to remove that. (It was just a dirty trick to let
eclipse access Batik's codec's code while debugging. BTW, if you know
a better way, let me know...)

> Thanks for enduring my comments and keep it up!

There is noting for me to *endure* in your comments. It is exactly the
kind of feedback that I needed.

Thanks,
Renaud

Reply via email to