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
