XP Mail Archive: XP> Multiple Referenced Images With Same Co

XP> Multiple Referenced Images With Same Content Location

From: WISSENBACH,DAVID (HP-Boise,ex1) (david_wissenbach@hp.com)
Date: Tue Jan 28 2003 - 12:26:11 EST

  • Next message: BIGELOW,JIM (HP-Boise,ex1): "RE: XP> January 23, 2003 versions of XHTML-Print and CSS Print Pr ofile re leased"

    -----Original Message-----
    >From: BIGELOW,JIM (HP-Boise,ex1)
    >Sent: Monday, January 27, 2003 3:55 PM
    >To: WISSENBACH,DAVID (HP-Boise,ex1); 'xp@pwg.org'
    >Subject: RE: Specifying the Persistence of Appmuxed Reference Objects

    >What if the contentID were unique for each image but the content-Location
    >identical for each identical image. For example, in the case of a series
    of
    >paragraphs that start with the same image, an information icon, the
    document
    >would look like the following:

    This might solve my problem--not wanting to modify the root document for a
    variety of reasons. I'd change this proposal slightly to not specify a
    Content-ID in the mime header for each image if the references were relative
    URLs, indicating reference by Content-Location.

    Of course, we would continue to support the straightforward method of
    modifying the original document to use a unique Content-ID for each instance
    of the repeated image in the stream.

    ><p class="info"><img src="info_icon.jpg" height="10" width="10">
    >Informational message: daba daba do...
    ></p>
    ><p class="info"><img src="info_icon.jpg" height="10" width="10"> Windows
    Haiku: Serious error. All shortcuts have disappeared.
    >Screen. Mind. Both are blank.
    ></p>

    >Then the multiplexed document would interleave the same image twice,
    >each with different contentID's but identical, "info_icon.jpg",
    content-Locations.
    >For example the multiplexed document could look like the following:

    I would have the multiplexer leave the Content-ID out. (Think of the missing
    Content-ID as a promise by the application-multiplexed document not to refer
    to this image in the compound document by content-ID.)

    I've modified the example accordingly.

    Content-Type: application/vnd.pwg-multiplexed;
    type=application/vnd.pwg-xhtml-print+xml

    CHK 1 428 MORE
    Content-Type: application/vnd.pwg-xhtml-print+xml
    Content-Location: infomsg.html
    Content-Disposition: inline

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://ww.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <title>info</title>
    </head>
    <p class="info"><img src="info_icon.jpg" height="10" width="10">
    Informational message: daba daba do... </p>

    CHK 2 512 LAST
    Content-Location: info_icon.jpg
    Content-Type: image/jpeg

    ... Header bytes of first instance of info_icon.jpg ...

    CHK 1 253 MORE

    <p class="info"><img src="info_icon.jpg" height="10" width="10"> Windows
    Haiku: Serious error. All shortcuts have disappeared. Screen. Mind. Both are
    blank. </p>

    CHK 3 1024 LAST
    Content-Location: info_icon.jpg
    Content-Type: image/jpeg

    ... Header bytes of second instance of info_icon.jpg ...

    CHK 1 113 LAST
    Content-Type: application/vnd.pwg-xhtml-print+xml
    Content-Location: infomsg.html
    Content-Disposition: inline

    <body>
    </body>
    </html>

    CHK 0 0 LAST

    >This method would allow the printer to only store the single image since
    the names are the same.

    What I would do in the MIME demultiplexer when the clone of the image
    arrives (and I know that it is a clone because the Content-Location is the
    same) is determine whether the XHTML-Print processor had consumed and
    discarded any data from the first instance, depending on the implementation
    of the XHTML-Print processor. If the XHTML-Print processor has consumed some
    of the data in the first image, then the MIME demultiplexer would have to
    create a new content-handler and storage for the clone. If the XHTML-Print
    processor has not consumed any data in the first image, then the MIME
    demultiplexer would increment a reference count in the store of the first
    image and discard all further data with channel 3 in the chunk header.

    In effect, we are no longer conforming to one constraint of RFC2557, that
    unique Content-Locations be assigned to each part of the message. But this
    is a case not addressed by RFC2557, because this part of the document is an
    exact copy, or clone, of the first.

    >Based on this approached I suggest the following, amended paragraph be
    added to section B.2:

    >Producers and consumers of Application/Vnd.pwg-multiplexed
    >entities, as defined in [MIMEMPX], should consider each
    >image as having one and only one reference. The producer
    >should not make assumptions about the buffering abilities
    >of the consumer of an Application/Vnd.pwg-multiplexed
    >entity and include a copy of an image for each reference
    >to it. Each chunk containing an image should have a unique
    >ContentID and a Content-Location whose value is the name
    >of the image referenced in the src attribute of the img
    >element or the href attribute of the object element.
    >Consumers may release the resources associated with
    >an image when the reference to it is satisfied, and are
    >free to optimize references to identical images in an
    >implementation dependent manner.

    I'd change the paragraph in B.2 to the following:

    Producers and consumers of Application/Vnd.pwg-multiplexed
    entities, as defined in [MIMEMPX], should consider each component image
    message of the compound document as having one and only one reference. The
    producer of the compound document must assume that the consumer of
    the Application/Vnd.pwg-multiplexed entity has limited memory and
    therefore include a unique image message for each image reference
    found in the root document. If a ContentID is present in the header of
    an image message, that ContentID must be unique. If a Content-Location
    is present in the header of an image message, that Content-Location
    is required to be unique except for the special case where a repeated
    reference
    to the same image URL causes several messages containing of the exact same
    image data to be
    present in the compount document. Consumers may release the message data
    associated
    with an image reference as the image is rendered, because the Consumer can
    be
    confident that another reference to the same image will be accompanied by
    another message containing an copy of that same image data. Consumers
    may also substitute image data for a message with a given Content-Location
    header value with
    image data from other messages with the same Content-Location header value
    because
    Consumers can be confident that messages with identical Content-Location
    values
    do in fact contain identical data.

    I suggest a further clarification by adding a following paragraph.

    URL references in the the root document of the multiplexed document must be
    matched to
    Content-Location and/or Content-ID fields of the referenced message object
    according
    to the rules given by RFC2557. An exception to the rules given by RFC2557
    occurs when a reference is made to a message object named with a
    Content-Location. In
    that special case, multiple instances of that message are required in the
    compound document.



    This archive was generated by hypermail 2b29 : Tue Jan 28 2003 - 12:27:17 EST