To really fix the printing performance, I think you will need to either: 1. The drawer needs to have a viewport concept that filters content stream operators better they render. I don't know if this is even possible or reasonable. I would have thought that sharing like this would suggest be implemented, but I couldn't find it. If it is implemented, then adjusting the print handler to extract the band viewport would probably help performance a lot.
Or 2. Create a private raster at the correct dpi, then render to it first, then transfer data to the printer from that raster. I think that you would want a disk based raster for this (similar to BigBufferedImage but better designed) Given the design of the Java print system, it may not be possible to extract the band viewport, in which case option will probably be your best bet. On Mon, Nov 8, 2021, 12:48 AM Tilman Hausherr <[email protected]> wrote: > Am 08.11.2021 um 06:03 schrieb Kevin Day: > > But that's only with a single render. Because printing can involve > > rendering many times for banded printing (on my test device, I am seeing > > well over 100 bands when printing this sample file), the page level > caching > > should be substantial (the rendering on your test PDF is so slow that it > > almost can't be printed) - it is certainly a huge improvement for my test > > document. > > The printing improvement should be the first thing to test because this > has been criticized for years. This happens with all PDFs that have > transparencies, there are several issues about this. JPedal has the same > problem. > > (It might take a few days before I test this) > > Tilman > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
