On Sun, 9 Mar 2003 18:40:26 -0500 (EST), "David A. Desrosiers"
<[EMAIL PROTECTED]> wrote:
> 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-deletio
> If you do a delete from the document list _within_ the viewer, no need:
> the doc list update is done regardless of how your update prefrence is
> set.
Oddly, this is not how it works in the emulator. If you delete a
document in the Document Library, the list is not updated. On a real d
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of David A.
> Desrosiers
> Sent: Sunday, March 09, 2003 6:13 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Deleting documents while set to Manual update
>
> > Sounds alot like CodeBase :) That's all we need, DBF
>
> 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
> Then what's the maximum width of an image? I've loaded a 2000x30x8bpp
> (60K) image and it displays well. It's just an image record, i.e. not an
> embedded image.
More importantly, how do apps like FireViewer and others view images
which are 2000x2000x16bpp on the Palm? What magic are t
> Sounds alot like CodeBase :) That's all we need, DBF support in plucker ;)
Even simpler. If you're in the doclist, and delete a document, and
your document preferences are set to "Manual Update", strikeout the title of
the document, or change the icon to 'N/A' or something for "offline"
On Sun, Mar 09, 2003 at 09:27:43PM +, Michael Nordström wrote:
> I know from past experience that Adam has a different view than me
> when it comes to the viewer's memory use; IMO, we should use as
> little memory as possible to be able to support also older devices
> and not only the latest a
On Sun, Mar 09, 2003, Laurens M. Fridael wrote:
> Images this wide will lead to gigantic PDBs, so in practice you
> won't even go near this limit.
The difference between Adam's suggestion (based on what he wrote; I
haven't seen the code, yet) and my suggestion is not only about the
image size, but
On Sun, Mar 09, 2003 at 09:16:02PM +0100, Laurens M. Fridael wrote:
> 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
Michael Nordström wrote:
> Whatever that fits within the 60k limit and has a height of 1 pixel,
> i.e. it also depends on the bitdepth how wide the resulting image
> can be.
>
> However, I kind of doubt there are any "interesting" images that have
> a height of 1 pixel ;-)
So in effect Adam's solu
On Sun, Mar 09, 2003, Laurens M. Fridael wrote:
> Then what's the maximum width of an image?
Whatever that fits within the 60k limit and has a height of 1 pixel,
i.e. it also depends on the bitdepth how wide the resulting image
can be.
However, I kind of doubt there are any "interesting" images t
Michael Nordström wrote:
> On Sun, Mar 09, 2003, Adam McDaniel wrote:
>> Well, I don't see any problem in creating a single image thats 1000
>> pixels wide and 1 high. Ofcourse, the altmaxwidth/altmaxheight value
>> would cap any runaway issues like that.
>
> In other words, you are replacing one l
I have a fuzzy memory of Bill mentioning on the list that the parser had the capacity
to crop
out a specified section of an image (in the capacity to crop to some 150x150 part of a
big
image and show it on the palm, instead of shinking the whole image to 150x150). I
think that is
what it was
On Sun, Mar 09, 2003, Adam McDaniel wrote:
> Well, I don't see any problem in creating a single image thats 1000
> pixels wide and 1 high. Ofcourse, the altmaxwidth/altmaxheight value
> would cap any runaway issues like that.
In other words, you are replacing one limitation with another (i.e.
ther
On Sun, Mar 09, 2003 at 03:01:53PM +, Michael Nordström wrote:
> On Sun, Mar 09, 2003, Adam McDaniel wrote:
> > Now comes the problem. I have written the code in the viewer to
> > support this but I have no idea how to handle support in the python
> > parser
>
> Hmm, I can see more problems th
On Sun, Mar 09, 2003, Adam McDaniel wrote:
> Now comes the problem. I have written the code in the viewer to
> support this but I have no idea how to handle support in the python
> parser
Hmm, I can see more problems than just to make the parser split up the
image; what if I have an image that is
I think I've found a solution to our little 64k max memory size
problem in images. I have the viewer code done to handle it (not
committed to CVS yet) but I need a volunteer to handle the parser
side...
My python and Java experience is limited at best, so I guess I'm
asking either Bill or Laurens
17 matches
Mail list logo
