> On Thu, Oct 10, 2002, Bill Janssen wrote:
> > The first is that we use the function code as a "hint" preceding a
> > regular image function code (or big-image function code).
>
> I like this idea. However, why do you need to include the alignment?
> There is a set alignment function that could
On Thu, Oct 10, 2002, Bill Janssen wrote:
> The first is that we use the function code as a "hint" preceding a
> regular image function code (or big-image function code).
I like this idea. However, why do you need to include the alignment?
There is a set alignment function that could be used if n
Mike, I've had second thoughts about the current proposal:
<0x1F><3-byte width+height><1-byte depth><1-byte alt tag len>
Mainly, this breaks the format specification. Older viewers won't
find and display these images. We really shouldn't switch formats
without updating the version number. It
On Tue, Oct 08, 2002, Bill Janssen wrote:
> What do you think about the 12-bit width and height?
I'm not too crazy about it (since it will require bit shifting to get
the data), but I guess it's an acceptable solution to this problem ;-)
/Mike
___
plu
- Original Message -
From: "Blake Winton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 09, 2002 12:51 AM
Subject: RE: Include width and height data in inlined images
> It also works on my Palm Vx, and my friend's Palm V. By which
> On Tue, Oct 08, 2002, Laurens M. Fridael wrote:
> > I'm not sure I understand. Is color to grayscale conversion
> > built in OS 3.5+?
> My example was not 100% correct (it would be true for a color device,
> but not for other devices). It seems that the device must be able to
> support the bit
> It's not that simple. I can create a document with 4bpp images that
> will display just fine on my TRGpro, but not on my Palm III. I don't
> think that is an "error" in the document.
OK with me then. What do you think about the 12-bit width and height?
Bill
___
On Tue, Oct 08, 2002, Laurens M. Fridael wrote:
> I'm not sure I understand. Is color to grayscale conversion built in OS
> 3.5+?
My example was not 100% correct (it would be true for a color device,
but not for other devices). It seems that the device must be able to
support the bit depth, but i
- Original Message -
From: "Michael Nordström" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 08, 2002 4:40 PM
Subject: Re: Include width and height data in inlined images
> On Tue, Oct 08, 2002, Laurens M. Fridael wrote:
> > An argum
On Tue, Oct 08, 2002, Laurens M. Fridael wrote:
> An argument for including the bit depth is that the document may be shared
> among users with different devices
Any device running PalmOS 3.5 or later will be able to display images
of a different bit depth, i.e. if the included image is a 8bpp co
- Original Message -
From: "Bill Janssen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 08, 2002 1:38 AM
Subject: Re: Include width and height data in inlined images
> Actually, I think there's a good argument for not includin
On Mon, Oct 07, 2002, Bill Janssen wrote:
> The distiller should never put in images that are too big, and if
> it does, you discover it when you uncompress the image anyway, and
> it's an error in the document.
It's not that simple. I can create a document with 4bpp images that
will display just
> Sure. Or we could just use 24 bits for the width and height (12 bits
> each), and include both the bit-depth and the alt tag in a slightly
> simpler format:
Actually, I think there's a good argument for not including the
bit-depth at all. The distiller should never put in images that are
too
> If we use the last byte to indicate the number of "extended" data
> items, we could use much more data,
>
> ...<# extended data items>
> ...
>
> For example, the new image function code would look like this,
>
> <0x1F><0x2>
> ..., where N <= 255
>
> That would make it possible to use an "un
On Mon, Oct 07, 2002, Bill Janssen wrote:
> Sure, I can put that in. Though I'd rather do it with a new image
> record,
Well, the idea was to *not* access the image record, i.e. putting
the data in a new record will not help (it will help when supporting
large images, though) ;-)
I'm talking ab
> Would it be difficult to include the width and height for an inlined
> image? If that information was available to the viewer it could layout
> the inlined images without being forced to find, open and uncompress
> the image record. That should make it faster when a document has many
> inlined i
On Mon, Oct 07, 2002, Laurens M. Fridael wrote:
> In case you hadn't thought of it: width and height should be shorts
> (2bytes).
Yep, and I did think about it. The last three bits of the function
code is the size of the data, i.e. 0x1E == 0000 -> last three
bits = 110 -> 6 bytes of data ;-)
- Original Message -
From: "Michael Nordström" <[EMAIL PROTECTED]>
To: "Plucker Development List" <[EMAIL PROTECTED]>
Sent: Monday, October 07, 2002 11:26 AM
Subject: Include width and height data in inlined images
>
> Function code 0x1E could
Would it be difficult to include the width and height for an inlined
image? If that information was available to the viewer it could layout
the inlined images without being forced to find, open and uncompress
the image record. That should make it faster when a document has many
inlined images, sin
19 matches
Mail list logo
