On Thu, Feb 13, 2003 at 10:45:16AM -0800, Taras wrote: > >Do you actually mean that the home record IS an image, or HAS an image? > >If it is an image, I don't think it's supposed to work that way :) > > > It IS an image. Plucker seems to happily pluck it. Not sure why it > wouldnt work. Plucker almost displays the image. It even draws the > little back button on the bottom.
It probably crashed because no one anticipated that anyone would be doing it that way :) Might be an easy fix though. Which version are you running? > Wow..I just did some searching on png on palm...Well i got a GPL program > that will display png images on a palm. As long as the png uses the > colormap from that package..it works great. > http://palmboxer.sourceforge.net > Not only does it display pngs..but it is able to display them on lower > res devices. So an 8bit png displayed just fine on my m125(unfortunately > I don't have the clie handy to test the actual color). However the > program doesn't seem to want to work in the palmos5 simulator. I'm > guessing the guy is using some strange api's to invoke the png viewer > app from zboxz. I've seen the same thing with that program. However I was never actually able to get the pinger to work. > So anyways, now I got a feature request..Could some one please play > around with this png code? It would rock so much to be able to display > png images in plucker. It even looks like it would be able to display > them fullscreen on a highres device. And I love the fact that it can > display the images on lower res devices too. > Aparently GIF files work too, but I haven't figured out the trick needed > to display them yet. Well, it wouldn't quite work that way. The idea I was playing around involve actually storing the images inside the .pdb as a png, not as a tbmp. Plus, since png files can be compressed it would help out (though not solve) the 64k limitation on images. The idea is to tell the parser to convert every image it sees into a png (rather than a tbmp) and import that into the image record) > The other cool part about the png stuff is that no conversion would have > to be done :) On the contrary, more conversion would be required. The parser would have to convert the gif/jpg/bmp into a png first, then the viewer would have to convert the png into a tbmp to display the image. The goal of this is to use png as a container to sneak under the 64k limitation on images. One nasty side effect of this is that it could severly slow down the load-times on plucked sites, plus you'd need to install a libpng.prc library. Users with faster devices (ie OS5) probably wouldn't notice a difference, but slower ones could fall back on the existing tbmp method. -- Adam McDaniel Array.org Calgary, AB, Canada _______________________________________________ plucker-list mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-list
