Hello,
Elliott wrote:
> I see two issues here, perhaps separable.
> 1. Use of inline data.
>
> This can be accomplished by adding support for the data scheme.
> ...
>
> 2. Separation of the data from the reference
>
> ...
>
> I think the first requirement is good to have, but we can
> probably drop the second, especially since the ordering is
> probably not what we want.
>
I'm not perfectly clear on what you think the requirements should be. The
current spec says that printer may support in-line data via the object/img
elements, but is not required to.
Are you calling for a change to this statement?
Arguments against requiring support for in-line image data have been that:
1. it requires too much buffering
2. the image data could overflow the memory used to store element
attributes. Alternately, to avoid the possibility of exceeding the memory
set aside for storing element attributes while processing a job, a printer
must either reserve large amounts of memory to avoid problems in this one,
almost unique case, or implement a complex, dynamic memory allocation
scheme.
In any event supporting in-line data via the object and image attributes
means that the entire image is funneled through the document parser,
whereas, alternate means of handling image data are possible if the image is
referenced via the cid or http schemes.
There is another method for managing image data buffering, Section B.2.1
In-line images of the W3C spec provides some informative suggestions about
ways to stage the delivery of image data using the (required) multiplexed
document format. This method seeks to reduce the memory needed to store
images while processing the document, by providing enough of the image
header to determine the image's size, synchronized with the image's
reference. The remainder or bulk of the image is delivered later in the
document, hopefully, when the printer is ready to commit the image to the
page.
Jim
--
This archive was generated by hypermail 2b29 : Fri Aug 01 2003 - 11:39:15 EDT