We've also played with idea of using the "declare" attribute on the obj
element. The idea being that if you declare the object, that means you
want to store its contents for the duration of the job.
I don't know if this exactly matches what the W3C had in mind for this
attribute. It would also be limited to the object element. But for images
the object element is OK, and it has the advantage that it would work in
any XHTML-Print configuration, regardless of transport.
------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Oak Technology Imaging Group
781 638-7534
"WISSENBACH,DAV
ID To: "'xp@pwg.org'" <xp@pwg.org>
(HP-Boise,ex1)" cc: "BIGELOW,JIM (HP-Boise,ex1)"
<david_wissenba <jim.bigelow@hp.com>
ch@hp.com> Subject: XP> Specifying the Persistence of
Sent by: Appmuxed Reference Objects
owner-xp@pwg.or
g
01/08/2003
03:29 PM
Dear people,
I (Dave Wissenbach, an HP engineer) have a small nit to pick with the
specification and usage of the application/multiplexed format which I
explain below:
The MIME Application/Vnd.pwg-multiplexed document format is provided to
minimize memory requirements in a printer. This requirement to minimize
memory usage suggests that referenced image data should be thrown away as
soon as the images have been rendered. Yet I have found no documentation to
suggest that this is indeed the case, other than the suggestion in the
application/multiplexed RFC3391 that objects that are out of scope no
longer
need to be stored, and can then be discarded, and that a mechanism is (or
should be?) provided for that purpose.
If a given image is repeatedly used in the document, is the image to be
included repeatedly, but with a different Content-ID each time? HP has a
prototype MIME multiplexer that specifies Content-Location: instead of
Content-ID in the header for each referenced object. I suppose that the
advantage of this approach to a multiplexed document is that the root
document need not be modified. But then we have the problem that the
multiply referenced object needs to persist over the entire course of
rendering the root XHTML-Print document.
Even the multiplexing application always uses Content-ID, and alters the
root XHTML-Print document to reference a different Content-ID each time, we
have the problem of wastefully resending the document.
To solve these problems, I am suggesting that persistence be explicitly
specified by the sending application by adding an extended
Content-Disposition header. See RFC 2183, Communicating Presentation
Information in Internet Messages: The Content-Disposition Header Field for
a
method to extend the Content-Disposition header.
If an object is to persist, I suggest the following in the Message Header
for that object:
CHK 2 570 MORE
Content-Type: image/jpeg
Content-Location: Rachel.jpg
Content-Disposition: inline;
persistence=refcount;
references=5;
Image Data here...
Or for a watermark that must appear on every page
CHK 2 570 MORE
Content-Type: image/jpeg
Content-Location: Watermark.jpg
Content-ID: Content-ID: <49568.45876Watermark.jpg@hp.com>
Content-Disposition: inline;
persistence=infinite;
Values for persistence would be once, refcount or infinite
Value for reference count would be 1 and above.
If the Content-Disposition header field is missing, the XHTML-Print
interpreter would free the image as it was consumed with the first
rendering.
As an alternative to this proposal we should document the understanding
that
Content-ID always be specified, and that each reference, even to the same
image, be required to represent the data inline.
There is probably one other way to make a persistent image, which is to
assign an objectID in the header of the html document, but I prefer to have
a solution that lets a web-based document be examined and mime-wrapped
without further modification.
Dave
This archive was generated by hypermail 2b29 : Wed Jan 08 2003 - 16:45:13 EST
