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