xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: [PATCH] Avoid tiling bitmaps for PDF and PS transcoders
Date Sun, 05 Sep 2004 20:59:52 GMT
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


Mime
View raw message