Or to put it another way, XHTML-Print describes a single way of doing
something. Wherease HTML and its derivatives frequently support multiple
ways of getting the same effect.
In the past, we have have resisted features that appear easy, unless they
actually extend the capabilities of what can be done.
Since I think a UTF-8 oriented client can get the same work done as a
UTF-16 client, we should not mandate the extension.
IMHO.
E.
--------------------------------------------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Zoran Imaging Group (formerly Oak Technology Imaging Group)
781 638-7534
don at lexmark.co
m To: "BIGELOW,JIM (HP-Boise,ex1)"
Sent by: <jim.bigelow at hp.com>
owner-xp at pwg.o cc: xp at pwg.org
rg Subject: Re: XP> Relaxing XHTML-Print's
restriction to UTF-8 to include UTF-16
09/02/2003
09:05 PM
Jim:
I would disagree. I don't believe that all XHTML-Print enabled printers
will necessarily bite the bullet and include a complete XML parser that
requires support for UTF-16. I don't believe we should force that to
occur. Perhaps you should remind the group that XHTML-Print is target for
LOW-END printers with this embedded. No 3 gigahertz Pentium 4's with 512
MB of memory!!!
*******************************************
Don Wright don at lexmark.com
Chair, IEEE SA Standards Board
Member, IEEE-ISTO Board of Directors
f.wright at ieee.org / f.wright at computer.org
Director, Alliances and Standards
Lexmark International
740 New Circle Rd C14/082-3
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
*******************************************
"BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow at hp.com>@pwg.org on 09/02/2003
08:42:14 PM
Sent by: owner-xp at pwg.org
To: www-html-editor at w3.org
cc: xp at pwg.org
Subject: XP> Relaxing XHTML-Print's restriction to UTF-8 to include
UTF-16
> From: Henri Sivonen [mailto:hsivonen at iki.fi]
...
> It is said that if a "charset" parameter is present for the
> application/xhtml+xml MIME type, the only valid value is "utf-8". It
> would make sense to allow "utf-16" as well. All XML processors are
> required to support UTF-16 in addition to UTF-8, so allowing
> UTF-16 for XHTML-Print doesn't cause any additional burden
> to implementations. Also, the payload of
> Application/Vnd.pwg-multiplexed chunks is defined
> as octets, so UTF-16 strings can be delivered as
> Application/Vnd.pwg-multiplexed chunks without any further encoding.
>
I tend to agree with Henri when he says that support UTF-16 would not be
much more expensive than UTF-8. Does anyone on this list or the PWG's
XHTML-Print list disagree?
Jim