You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@greenmail.ch> on 2004/09/04 13:44:19 UTC
[PATCH] Avoid tiling bitmaps for PDF and PS transcoders
I'd like to propose a patch which changes the behaviour of
GraphicsUtil.drawImage. By default, bigger images coming from filter
effects, for example, are tiled and then rendered to the destination.
I experienced ugly overlaps of these tiles within Acrobat Reader even
though I can't make out any rounding errors in the code and the
generated PDF code. So I changed GraphicsUtils so I can supply a
RenderingHint from the PDF and PS Graphics2D implementations so these
images get rendered in one step. A nice side-effect is that the
resulting PDFs get a lot smaller.
I've fixed up a ZIP with the patch and an SVG and resulting PDF that
shows the problem in Acrobat Reader 5 and 6.
http://cvs.apache.org/~jeremias/batik-tiling-patch.zip
WDYT?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [PATCH] Avoid tiling bitmaps for PDF and PS transcoders
Posted by Jeremias Maerki <de...@greenmail.ch>.
Hi Thomas
On 05.09.2004 12:56:19 Thomas DeWeese wrote:
> Hi Jeremias,
>
> Jeremias Maerki wrote:
>
> > I'd like to propose a patch which changes the behaviour of
> > GraphicsUtil.drawImage. By default, bigger images coming from filter
> > effects, for example, are tiled and then rendered to the destination.
> > I experienced ugly overlaps of these tiles within Acrobat Reader even
> > though I can't make out any rounding errors in the code and the
> > generated PDF code.
>
> It looks like they aways push the images out to the nearest
> pixel boundary. This ensures that the images touch in all cases
> so you don't get 'drop outs'. For opaque images this works great
> but for transparent images (like your example) it generally causes
> double opacity for 1 pixel on the edge at all zoom levels.
Makes sense.
> > So I changed GraphicsUtils so I can supply a
> > RenderingHint from the PDF and PS Graphics2D implementations so these
> > images get rendered in one step. A nice side-effect is that the
> > resulting PDFs get a lot smaller.
>
> I must say that I am very surprised at this result, any idea
> why it would be 1/2 as large? How do you normally store images in the
> PDF file?
Not exactly sure how this huge difference results without having a
closer look. Sorting the bitmaps in PDF is pretty much the pixels in a
byte array (RGB=3 bytes per pixel). The resulting stream is then flate
compressed and ascii-85 encoded. Color and transparency bitmaps each
separately. The setup code for each bitmap is already quite big and
painting [1] each bitmap (plus transparency bitmap) also takes some room
but that's probably not all there is to it. It could be that the
accumulated width of the tiles is bigger than that of the single image
(a quick look hints at that, but I haven't looked at it more closely.
Too tired).
[1] Keep in mind that in my sample PDF files compression for the
painting code has compression disabled for debugging purposes.
> > WDYT?
>
> There are a few trivial tweaks that I might make (the value should
> be _ON, _OFF, _DEFAULT like the other Java2D rendering hints) but
> generally it looks fine.
Didn't realize that. Sorry.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [PATCH] Avoid tiling bitmaps for PDF and PS transcoders
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jeremias,
Jeremias Maerki wrote:
> I'd like to propose a patch which changes the behaviour of
> GraphicsUtil.drawImage. By default, bigger images coming from filter
> effects, for example, are tiled and then rendered to the destination.
> I experienced ugly overlaps of these tiles within Acrobat Reader even
> though I can't make out any rounding errors in the code and the
> generated PDF code.
It looks like they aways push the images out to the nearest
pixel boundary. This ensures that the images touch in all cases
so you don't get 'drop outs'. For opaque images this works great
but for transparent images (like your example) it generally causes
double opacity for 1 pixel on the edge at all zoom levels.
> So I changed GraphicsUtils so I can supply a
> RenderingHint from the PDF and PS Graphics2D implementations so these
> images get rendered in one step. A nice side-effect is that the
> resulting PDFs get a lot smaller.
I must say that I am very surprised at this result, any idea
why it would be 1/2 as large? How do you normally store images in the
PDF file?
> WDYT?
There are a few trivial tweaks that I might make (the value should
be _ON, _OFF, _DEFAULT like the other Java2D rendering hints) but
generally it looks fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org