XHTML Print Meeting
April 17, 2002
Held at Oak Technology, Boston MA
The meeting started at 10:30 AM following the PWG Plenary. Elliot
Bradshaw agreed to be minute taker for the meeting.
Inline images
==========
Discussion: Since includes a data attribute that allows for
base64 inline data, should this be mandatory in XHTML-Print? It would
provide another method in addition to interleaving (UPnP) or reference to
image data in the client (Bluetooth).
Decision: This should not be mandatory.
Action: Don will edit the spec to say that, for printers that implement
inline data, the mandatory method is MIME interleaving, and support for
base64 object data is optional.
Attributes
=======
Discussion: There is some confusion over which attributes of which
elements should be mandatory in the printer.
Action: Melinda and Elliott will circulate a proposal by mid-May.
MIME parameters
=============
Discussion: RFC 3236 ("The 'application/xhtml+xml' Media Type") defines
two optional parameters.
"charset" has identical semantics to charset in "application/xml" (RFC
3023); 3023 explains why this is "more authoritative" than the
corresponding XML declaration.
"profile" allows for the specification of a DTD to indicate a more specific
language based on XHTML. In this case it would be the DTD for XHTML-Print.
[However, look at the first paragraph in Section 8 of RFC 3236. It says
this is a short term solution for "negotiation, not delivering content".
Is this applicable to sending XHTML-Print data?]
Decision:
Modify the XHTML-Print spec to say that a printer may optionally support
the charset parameter. [By implication, if supported it should override
any XML declaration.]
Modify the XHTML-Print spec to say that:
MIME type of "application/vnd.pwg-xhtml-print+print+xml" must be
supported in the printer (as now)
MIME type of "application/xhtml+xml" with a profile of "
HTTP://www.xhtml-print.org/xhtml-print+10.dtd" should be supported (with a
note advising clients that they cannot always depend on it)
Action: Don to make these changes.
Image rotation
==========
Discussion: Lee Farrell pointed out that the current use of EXIF markers
to indicate image rotation is dangerous, since browsers don't honor them,
and users would get different printed results than browsed. In addition
the need to modify the image content makes it harder to use caching for
cases when the same image is printed at different rotations.
His proposal is to remove the use of EXIF markers, and replace them with an
attribute or some such outside the data, e.g. . The CSS
group has so far not given guidance on this, though we have asked. There
is reluctance to define a non-W3C extension.
Decision: Leave EXIF markers in for now, but look for a replacement.
Lobby with CSS for an answer.
Action: Don to follow up with CSS group.
Rotation and photo support in basic XHTML-Print
====================================
Discussion: Lee expressed Canon's desire to have solid support for photo
printing in a basic print product. This would include rotation. Canon
feels that Enhanced layout may be too complex for a minimal photo printer.
He suggested making rotation mandatory in the XHTML-Print core. However,
Melinda and others expressed concern that rotation increases the memory
usage of a printer, and would exclude Deskjet-class products from
compliance.
Another approach is to review the Enhanced Layout extensions in the context
of Canon's photo requirements. Other photo people were involved in
defining Enhanced Layout, but maybe it can be streamlined, or maybe we can
create an "intermediate bar" for photo printing.
Decision: Leave basic as it is and explore the best way to support photo
printing.
Action: Lee/Canon to review Enhanced Layout and propose a subset for Photo
Printing. Group will then discuss whether this is in addition to or
replacement of Enhanced Layout.
Structure of XHTML-Print specification
=============================
Discussion: Lee proposed the idea that the XHTML-Print specification could
document modifications to a baseline, rather than a list of features.
Today it generally does that for elements, specifying changes from XHTML
Basic, but it does not do so for CSS. There is no obvious baseline for
properties.
One recent possibility is CSS Mobile. Melinda has looked at it and it has
a few problems as a baseline. In particular it specifies giving the user
the option to resolve ambiguous link elements; we would have to exclude
this for printing. However for other properties it might be a good
baseline. [Also, it has an interesting set of selectors, which could be
used for XHTML-Print, which is currently silent on the subject.]
If we wanted to structure the spec more like W3C documents, we would
probably separate elements from properties (i.e. we would add "CSS-Print").
We could also modularize it in the spirit of XHTML. It was unclear how
important this is to the group.
Actions: Lee/Canon to suggest a different structure based on a particular
baseline for properties. Separately, Melinda to suggest additional spec
language for selectors.
Conversion of DTD to XML Schema
===========================
Discussion: This is the W3C direction going forward. When will they
require it? When will conversion of XHTML to Schema be complete?
Consensus is that devices will not actually examine either the DTD or the
Schema, so this is only an issue for the specification, and possibly clever
client tools.
Decision: No need for immediate change.
Action: Don? check with Fujisawa-san at Canon, who wrote the DTD, to get
his opinion on difficulty/value/willingness for conversion.
More media types
=============
Discussion: Today there is only one CSS media type for print. Variations
of this would allow for style sheets that are sensitive to the kind of
printing being done, e.g. mono vs. color.
Action: Don to ask CSS group if they are interested in doing this.
Intellectual Property
===============
Discussion: We reviewed the PWG ground rules. They seem to be:
participants (which is meant to include non-members) must disclose IP
claims prior to final PWG approval, and make their IP available on
reasonable terms. For XHTML-Print this is targeted for Q4, so it will be
some time before we know.
The group believes that all the W3C material we use is unencumbered.
Action: Don will send an email request asking participants to discuss any
IP claims as soon as they can.
--------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Oak Technology Imaging Group
781 638-7534