> 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, since it would only be necessary to access the actual
> image data when the image should be displayed.

Sure, I can put that in.  Though I'd rather do it with a new image
record, which could also handle an image composed of multiple parts.
Well, we can do that next.

> Function code 0x1E could be used for this and the data would be record
> ID, width, and height (in that order). 

Three 16-bit values, right?  May I suggest that we make it function
code 0x1F, and the parameters ID, width, height, and
alternate-text-length?  That is, we add a byte that gives a number of
additional bytes (0-255) which, if present, contain the "alternate
text" for the image tag.  That way, if it's not presentable, you could
stick in the text instead.

Bill
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev

Reply via email to