Melinda:
Challenge away..... I didn't want it in there in the first place but my notes
indicated that was the concensus of the group. If we can disallow embedding the
image data and still claim support for <object> then OK but can we do that?
**********************************************
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 04/02/2002 02:59:19 PM
To: "Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com,
IMAGING%FORUM.UPNP.ORG@interlock.lexmark.com,
xp%pwg.org@interlock.lexmark.com
cc: (bcc: Don Wright/Lex/Lexmark)
Subject: RE: XP> Inline image data
I'm challenging the first assumption. Why do we need to require printers to
support inline binary data with the object element, as opposed to leaving
that support optional?
Melinda
-----Original Message-----
From: don@LEXMARK.COM [mailto:don@LEXMARK.COM]
Sent: Monday, April 01, 2002 12:11 PM
To: IMAGING@FORUM.UPNP.ORG
Subject: Re: XP> Inline image data
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 : Tue Apr 02 2002 - 15:12:46 EST