XP Mail Archive: RE: XP> Incorrect example in Appendix B.3 o

RE: XP> Incorrect example in Appendix B.3 of XHTML Print

From: ElliottBradshaw@oaktech.com
Date: Fri Aug 01 2003 - 12:45:50 EDT

  • Next message: BIGELOW,JIM (HP-Boise,ex1): "XP> Call for review: CSS Print Profile, W3C Working Draft 13 August 2 003"

    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