Sorry, I didn't mean to change the actual requirements. Section B.3 should
stay informative and just be a discussion of different things a printer may
choose to implement.
However, there is at least one case of a conditional requirement elsewhere
in the document (the Object Module) that refers to this section.
But, it is confusing what problem this section is trying to solve (in an
optional way). And, it looks like the example for use of the declare
attribute is just plain wrong.
I propose that we re-write this section to eliminate all discussion of the
declare attribute, and simply show how to use the data URL scheme to handle
inline data.
For example:
<proposal>
This section is informative.
An alternative method to include inline image data in XHTML-Print is via
the "data" URL scheme (see RFC2397). Because this method normally encodes
the binary image data using base64 encoding, a significant increase in the
size of the data transmitted will be experienced. This SHOULD be avoided
over low speed connections. Printers supporting inline data MAYsupport
base64 encoding using the img or object element.
<object height="20 mm" width="20 mm" type="image/jpeg"
data="data:image/jpeg;base64,aGh67Fghsapa0Hji7dfGSweTa . . . ">
Example Image
</object>
or
<img height="20 mm" width="20 mm" alt="Example Image"
src="data:image/jpeg;base64,aGh67Fghsapa0Hji7dfGSweTa . . . " />
This method MAY be useful for very simple clients that cannot afford a
server for image downloading or for some reason cannot utilize the
Application/Multiplexed MIME type; however, it is not RECOMMENDED for
general use especially if the size of the printer's buffer is unknown.
</proposal>
------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Oak Technology Imaging Group
781 638-7534
"BIGELOW,JIM
(HP-Boise,ex1) To: ElliottBradshaw@oaktech.com, Jun Fujisawa
" <fujisawa.jun@canon.co.jp>
<jim.bigelow@h cc: don@lexmark.com, "BIGELOW,JIM (HP-Boise,ex1)"
p.com> <jim.bigelow@hp.com>, owner-xp@pwg.org, xp@pwg.org
Subject: RE: XP> Incorrect example in Appendix
08/01/2003 B.3 of XHTML Print
11:38 AM
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 - 12:50:27 EDT