> So in effect Adam's solution has the limitation that images can only be
> 30K pixels wide in the most extreme case(with 16bpp). That's about 9
> screens across on a high-res device. Images this wide will lead to
> gigantic PDBs, so in practice you won't even go near this limit. Anyway,
> you're calling the shots here.
Another idea comes to mind... how about having images in one pdb,
and the textual content in another? This would have a few advantages (and
one disadvantage, more "crumbs" to clean up at doc-deletion time), however,
we can create a parser that can put the images into the second "image"
database compressed and in "raw" format, as if they were an ogg file sitting
on an SD card, and read them block by block, instead of storing them as Palm
records themselves.
I've never implemented something like this, but not all data
accessible on a Palm has to be in Palm Record format. We could then also
deal with the dynamic "chunking" viewer code I've just suggested in my
previous message to read the text content from the first database (or even
text plus images <64k) and then the large "pannable" images from the image
database, for images which are >64k.
d.
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
