----- Original Message ----- From: "Michael Nordstr�m" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 26, 2002 11:20 AM Subject: Re: Maximum image size again
> On Wed, Sep 25, 2002, Bill Janssen wrote: > > Yes, but does this affect the 60,000 byte limit? > > > > The distiller is of the opinion that the image in Palm format > > (whether or not that format uses one of the image compression > > schemes) can be 60,000 bytes :-). > > It can continue to be of that opinion. However, the PalmOS viewer > will not display images that will crash the device (if you attempt > to create an offscreen window that is larger than 64k PalmOS will > not return an error code; it will just crash) I did some tests. The Viewer can display a 598x100x8bpp RLE-encoded image, but it crashes when it tries to display a 599x100x8bpp RLE-encoded image. Notice that 599 is an uneven number and that there are really 600 bytes per row (the number of bytes per row must be even). This makes for 60000 bytes needed by the offscreen buffer which apparently is already over the limit. (I assume it would work if the offscreen buffer required 59998 bytes. However, Fireworks won't let me create a 59998x1x8bpp image so I can't try that out.) The Plucker format specification was right all along but didn't state it very clearly: images must be *less* than 60000 (60k) bytes in their non-compressed state. width x height x bpp is the formula to use here. I found out something neat along the way. ZLIB compression will sometimes yield better results if the image is *not* RLE or Scanline encoded beforehand. I.e. ZLIB does a better job of compressing a raw bitmap rather than an encoded bitmap. This might save a few KB per image. I don't know if the Python parser takes this into account, but I thought I'd mention it. Regards -Laurens _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
