[comp.sys.palmtops.pilot] Re: Great new Reader with innovative scroll
I've seen the following program in the newsgroups and its method of auto-scrolling does seem quite smart, eliminating the LCD flicker we all know and love. Can I make this a feature request, please? ;-) Thanks. From: [EMAIL PROTECTED] Newsgroups: comp.sys.palmtops.pilot Subject: Re: Great new Reader with innovative scroll Date: Thu, 26 Apr 2001 12:34:48 GMT You have to try it to really understand. Basically it fills the screen with a page. As that page fills, the next page fills in behind it. If you have the scanning rate set right you are reading ahead of the fill and when you hit the bottom, you return to the top of the page and continue to read the subsequent page as another fills in behind that. The effect is much like reading a regular book. Instead of switching to the top of the next page, or worse yet, turning a page, you just flick your eyes back to the top. I like the idea of incorporating this in CSpotRun. However, from the developers point of view, even though he made this freeware, he may not want to give his code away. I think if he developed it within GNU, he would have to also post the code. END QUOTE -- MJR
Re: viewer crash w/ big gfx (this time w/ attachment)
On Wed, Apr 25, 2001, Daniel Vollmer wrote: > Created a database with a comic (megatokyo) in 2bpp. > Plucker did not display the .gif (650x975) at all, so i rescaled it to > 520x780. this gfx now crashes the palm-viewer w/ a DataMgr > write error... This is a parser problem, since it creates a database that is not according to the spec. The database format specifies that the document header should include the total size of the text/image *before* compression using a 16 bit variable (i.e. max 64k). If we than add the fact that you are trying to squeeze in a too large image we have a major problem ;-) 520 x 780 x 2 / 8 = 100k, but when you put that value into a 16 bit variable it will all of sudden indicate that the total size of the data is about 35k, so when the viewer attempts to uncompress the data the DmWrite operation will write outside the allocated space... The parser should make sure that the data is 64k or less before compressing it (images shouldn't be bigger than 6 bytes or the viewer will refuse to display them). /Mike
