Re: [PATCH] Avoid tiling bitmaps for PDF and PS transcoders

2004-09-05 Thread Jeremias Maerki
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PATCH] Avoid tiling bitmaps for PDF and PS transcoders

2004-09-05 Thread Thomas DeWeese
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]