Melinda, et al:
#1) My notes from the meeting were that since we mandate support for <object>
then we have to allow its usage for inline data. We don't guarantee it will
work with a minimal memory printer but we have to allow it and properly parse
the element.
#2) If not base64, please explain what encoding you propose for binary data in
the middle of XML? Can't have a binary sequence of </> or some other "magic"
string happening by accident!! I don't see a way to specify the byte count of
the image with <object> and therefore I don't see a way to just drop in the
binary data. What am I missing here????
**********************************************
Don Wright don@lexmark.com
Member, IEEE SA Standards Board
Member, IEEE-ISTO Board of Directors
f.wright@ieee.org / f.wright@computer.org
Director, Alliances & Standards
Lexmark International
740 New Circle Rd
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
**********************************************
"GRANT,MELINDA (HP-Vancouver,ex1)" <melinda_grant%hp.com@interlock.lexmark.com>
on 03/26/2002 10:53:09 PM
To: "Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com, Jun Fujisawa
<fujisawa.jun%canon.co.jp@interlock.lexmark.com>
cc: PWG XHTML-Print <xp%pwg.org@interlock.lexmark.com>,
imaging%upnp.org@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark)
Subject: RE: XP> Inline image data
I don't see anything in the (HTML 4.01) specification that indicates to me
that support for the object element requires support for base64 encoding.
My takeaway from UPnP discussions was that we would require support for
application/vnd.pwg-multiplexed en lieu of requiring support for base64
(i.e., we would standardize one required method to ensure a job could be
transmitted as a single "pushed" data stream or file; others would be
optional).
I don't recall an XHTML-Print discussion where we agreed to require support
for base64; so my opinion is that it currently is not required, and that the
only required object data format is jpeg.
Do others have different memories or read the specs differently? Would we
accrue any major benefits by adding the requirement that the printer be able
to decode base64 objects? If so, which base64 objects?
Melinda
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Friday, March 08, 2002 7:13 AM
To: Jun Fujisawa
Cc: PWG XHTML-Print
Subject: Re: XP> Inline image data
Jun, et al:
I have no problem including other ways to include in-line image data using
the
object and/or img elements. The issue the group needs to decide on is what
is
the compliance answer? Are all the possible methods acceptable? Should we
identify one and only one that is required for compliance? Any discussion
from
others?
I'll add a reference to RFC2397.
**********************************************
Don Wright don@lexmark.com
Member, IEEE SA Standards Board
Member, IEEE-ISTO Board of Directors
f.wright@ieee.org / f.wright@computer.org
Director, Alliances & Standards
Lexmark International
740 New Circle Rd
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
**********************************************
Jun Fujisawa <fujisawa.jun%canon.co.jp@interlock.lexmark.com> on 03/08/2002
02:11:37 AM
To: PWG XHTML-Print <xp%pwg.org@interlock.lexmark.com>
cc: (bcc: Don Wright/Lex/Lexmark)
Subject: XP> Inline image data
The description of an alternate method to include inline image
by using 'declare' attribute of 'object' element has been added
to Appendix B of XHTML-Print 0.951 specification.
I don't think this particular method is the only "conditionally
mandatory" method to include inline image in XHTML-Print.
What's wrong with the following methods?
- 'object' element without 'declare' attribute
<object width="20 mm" height="20 mm" type="image/jpeg"
data="data:image/jpeg;base64,aGh67Fghsapa0Hji7dfGSweTa..."
- 'img' element
<img width="20 mm" height="20 mm"
src="data:image/jpeg;base64,aGh67Fghsapa0Hji7dfGSweTa..."
Also, I'd like to suggest to add a reference to RFC2397.
"RFC2397 - The "data" URL scheme", L. Masinter.
It is available from http://www.ietf.org/rfc/rfc2397.txt.
-- Jun Fujisawa <mailto:fujisawa.jun@canon.co.jp>
This archive was generated by hypermail 2b29 : Mon Apr 01 2002 - 15:09:09 EST