Abstract

Status of this Document

This section describes the status of this document at the time of its publication. Other documents MAY supersede this document. The latest status of this document series is maintained at the W3CPWG.

All sections of this document are normative unless noted as informative.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

Document Difference Marking Conventions

Note: The following review conventions are used in this document:

• The presentation of this sentence indicates how text, inserted since the submission of the PWG specification to the W3C, is shown.
• Text in the PWG specification and deleted from this document is shown as follows: " in this manner".
• Editorial comments that are not meant for the final version are shown using the style of the following paragraph.

  This is an example of a comment written by the editor. The comment is meant to aide discussions of the document and will not appear in the final draft.

Table of Contents

1. Introduction

All sections of this document are normative unless noted as informative.

1.1. XHTML for Printing

This section is informative.

This document specifies a simple XHTML based data stream suitable for printing as well as display. It is based on the W3C's XHTML Basic [XHTMLBASIC] with the addition of Ccascading Sstyle Ssheets (CSS) from CSS Print Profile [CSSPP]. Its targeted usage is for printing in environments where it is not feasible or desirable to install a printer-specific driver and where some variability in the formatting of the output is acceptable. Throughout this document this data stream is called "XHTML-Print."

XHTML-Print is designed to be appropriate for low-cost printers that mightmay not have a full-page buffer and that generally print from top-to-bottom and left-to-right with the paper in a portrait orientation. For other printers (i.e., those that print in another direction or orientation) a full-page buffer couldmay be neededrequired.

XHTML-Print is not appropriate when strict layout consistency and repeatability across printers are neededrequired. The design objective of XHTML-Print is to provide a relatively simple, broadly supportable page description format where content preservation and reproduction are the goal, i.e. "Content is King." Traditional printer page description formats such as PostScript or PCL are more suitable when strict layout control is neededrequired. XHTML-Print does not utilize bi-directional communications with the printer either for capabilities or status inquiries.

This document creates a set of conformance criteria for XHTML-Print. It references style sheet constructs drawn from CSS2 [CSS2] and proposed for CSS3 Paged Media [PAGEMEDIACSS3] as defined in the CSS Print Profile [CSSPP] to provide a strong basis for rich printing results without a detailed understanding of each individual printer's characteristics.

It also defines an extension set that provides stronger layout control for the printing of mixed text and images, tables and image collections.

The document type definition for XHTML-Print is implemented based on the XHTML modules defined in Modularization of XHTML [XHTMLMOD].

1.2. Terminology

The keywords "MUST", "SHALL", "MUST NOT", "SHALL NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" when used in this document are to be interpreted as described in RFC 2119 [RFC2119]. However, for readability, these words do not appear in all uppercase letters in this specification.

1.3. Design Rationale

This section explains why certain HTML features are not part of XHTML-Print and any special circumstances concerning a module and printing.

1.3.1. Script and Events

Scripts, as programs that are executed in conjunction with a document, are not relevant to the printed page. However, documents can provide information as an alternative to a script. Therefore, the script module is part of XHTML-Print since the content of the script element MUST be discarded and the content of the noscript element printed.The script and noscript elements are not supported as a printer lacks typical user interaction necessary for a script.  Content of the script should not be printed.

Events are not applicable to static, printed versions of a document. Therefore, the Intrinsic Events module is not part of XHTML-Print.

1.3.2. Presentation

Many simple printers cannot print a wider variety of fontsother than the generic serif, sans serif and monospace. It is RECOMMENDED that style sheets be used to create a presentation that is appropriate for a particular category of printer. How printers are categorized, what those categories are, how a printer identifies itself as a member of a category, and how style sheets are selectively applied based on category, is outside the scope of this document.

The Presentation module ([XHTMLMOD], section 5.4.1) of [XHTMLMOD] is supported to allow very simple printers to support basic font variants and rules without the need to implement support for CSS as REQUIRED by CSS Print Profile [CSSPP]. However, printers SHOULD provide support for CSS within the limits of their device.since it allows a very simple user agent to support font variants. The module contains elements that are both structural and presentational, provides the only method for specifying rules (the hr element), and allows very simple clients that might not support CSS the means for identifying font variants such as bold, italic, superscript and subscript. Supporting this module allows a client to render these common elements in a manner that is appropriate for its capabilities.

1.3.3. Forms

Basic XHTML forms ([XHTMLMOD], section 5.5.1) [XHTMLMOD] are supported. Content developers SHOULD keep in mind that users mightmay not be able to input many characters from some devices (e.g. from a mobile phone). Furthermore, developers are cautionedNote that a printer prints a static version of a form, and the visual appearance of a form depends heavily on the implementation.

1.3.4. Tables

Basic XHTML tables ([XHTMLMOD], section 5.6.1) [XHTMLMOD] are supported, but tables can be difficult to format on very low resource devices.  Furthermore, content developers are cautionedNote that in the Basic Tables Module, nesting of tables is prohibited.

1.3.5. Frames

Frames are not supported. Frames depend on a screen interface and therefore are not applicable to printers.

1.3.6. Attributes

XHTML-Print is a member of the family of XHTML languages defined by Modularization of XHTML [XHTMLMOD]. Therefore, the elements and attributes in the modules that make up XHTML-Print are all valid constructs of the language. However, not all the attributes are applicable to a rendering of an XHTML-Print document in a printed media, especially those that are integral to a dynamic display of the document in a browser and the submission of a form. Furthermore, special attention is given to simple printers and some attributes are deemed too complex for a such a printer to render. These attributes are treated as discretionary in that a conforming printer is not REQUIRED to support them, but ifshould a printer wishes to provide that support, there are requirements stated for consistency in the implementation of extensions.

2. Conformance

2.1. Document Conformance

A conforming XHTML-Print document is a document that requires only the facilities described as mandatory in this specification. Such a document SHALL meet all of the following criteria:

1. The document SHALL validate against the DTD found in Appendix C and conform to the constraints expressed in Design Rationale.
2. The root element of the document SHALL be <html>.
3. The name of the default namespace on the root element SHALL be the XHTML namespace name, http://www.w3.org/1999/xhtml.
4. There SHALL be a DOCTYPE declaration in the document prior to the root element. If present, the public identifier included in the DOCTYPE declaration SHALL reference the DTD found in Appendix C using its Formal Public Identifier. The system identifier MAY be modified appropriately.
   
   <!DOCTYPE html PUBLIC "-//W3CPWG//DTD XHTML-Print 1.0//EN"
   "http://www.w3xhtml-print.org/TR/xhtml-print/xhtml-print10.dtd">
    
5. The DTD subset MUST NOT be used to override any parameter entities in the DTD.

The MIME type used to refer to a conforming XHTML-Print document SHALL be "application/xhtml+xml" "application/vnd.pwg-xhtml-print+xml". An OPTIONAL "charset" parameter MAY be provided with the MIME type. The only valid value for the "charset" parameter is "utf-8". Invalid values MUST be ignored and the result be as if the value were "utf-8". Usage of the OPTIONAL "charset" parameter is as described in section 3.2 of RFC3023 - XML Media Types [RFC3023].

Additionally, printers may support a MIME type of "application/xhtml+xml" with a profile of "http://www.xhtml-print.org/xhtml-print/xhtml-print10.dtd". Not all printers will support this option, therefore clients cannot always depend upon it. Use of a profile is as described in section 2 and section 8 of [RFC3236].

2.2. Client Conformance

1. Clients SHALL produce a well-formed XHTML-Print document as defined in XHTML 1.0 [XHTML1] and in Document Conformance.
2. Beyond number 1 above, clients are not REQUIRED to use more of the XHTML-Print elements or Style Sheet attributes than necessary to get the desired output.

2.3 Printer Conformance

2.3.1 Formatting/Rendering Rules

A printer MUST conform to the XHTML Family User Agent Conformance section of the "Modularization of XHTML" specification ([XHTMLMOD], section 3.5) with the following exceptions and additions:

1. Validation is not REQUIRED to claim conformance to this standard. A printer MAY ignoreflush or otherwise reject a non-conforming XHTML-Print document.
2. Images:
   • If a printer encounters an image in a format it does not support, it SHALL render any alternate content provided, and MAY reserve the space specified by the height and width attributes by optionally drawing a box around this space of the size specified for the image.
   • If the image format is not supported or the height and width attributes are absent and no alternate content is provided, the image MAY be omitted and no space reserved.
   • If the image format is supported and the height and width attributes were omitted, the printer MAY choose to omit the image from the page.
   • A printer MAY choose to omit images referenced by a URI [RFC2396] containing a scheme name other than cid [RFC2392] and http [RFC2616]. Image data within the object element need not be supported.
3. Printers may choose not to render content within elements defined by XHTML [XHTML1] or HTML [HTML4] that are obviously not intended to be rendered, e.g. <script>.
4. Printers that do not support the xml:lang attribute are not REQUIRED to adhere to the rules for language specific whitespace handling.

2.3.2 XHTML Requirements

1. A conforming printer SHALL support all XHTML Modules listed in The XHTML-Print Document Type.
2. A conforming printer SHALL print a static version of a form using default and selected values as specified in the form.
3. Printers supporting inline image data SHALL support RFC3391 - The MIME Application/Vnd.pwg-multiplexed Content-Type [MIMEMPX] as described in Appendix B.
4. A conforming printer SHALL identify this datastream by the exact string: "XHTML-Print" (without the quotation marks) in all service discovery records and protocols, device identification records and protocols, and in other cases where a list of supported datastreams is to be presented by the printer.  Where such datastreams are identified by a MIME media type, the string "application/vnd.pwg-xhtml-print+xml" SHALL be used.
5. A conforming printer SHALL support the CSS constructs and associated values given in the CSS Print Profile [CSSPP]; support for other values and other properties or constructs is OPTIONAL.

2.4. Enhanced Layout Extension Conformance

To further support print applications requiring more exacting page layout (e.g., photo album pages), the style sheet properties of the Enhanced Layout Extension of the CSS Print Profile ([CSSPP] section 2.1) and image processing (Appendix A.3) SHALL be supported in an OPTIONAL, discoverable (via some means outside the scope of this document) Enhanced Layout Extension.

The following is an informative example using absolute positioning with image data:

3. The XHTML-Print Document Type

The XHTML-Print document type is defined as a set of XHTML modules. All XHTML modules are defined in the "Modularization of XHTML" specification [XHTMLMOD].

XHTML-Print consists of the following XHTML modules:

Structure Module*

body, head, html, title

Text Module*

abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var

Hypertext Module*

a

List Module*

dl, dt, dd, ol, ul, li

Text Extension Module - Presentation**

b, big, hr, i, small, sub, sup, tt

Basic Forms Module

form, input, label, select, option, textarea

Basic Tables Module

caption, table, td, th, tr

Image Module

img

Object Module

object, param

Metainformation Module

meta

Scripting Module**

noscript, script

Style Sheet Module**

style

Style Attribute Module**

style attribute

Link Module

link

Base Module

base

(*) = This module is a REQUIRED XHTML Host Language module.
(**) = These modules are not a part of XHTML Basic but are REQUIRED for XHTML-Print.

An XML 1.0 DTD is available in Appendix C.

3.1 Attributes and Attribute Collections

HTML allows binary attributes to be given without a value, e.g. <option selected>. However, XML, and hence XHTML 1.0 languages, requires all attributes to take a value. Thus in XHTML-Print these shall be given with a cloned value (e.g. selected="selected").

Some of the attributes defined in the Modularization of XHTML [XHTMLMOD] are not applicable to the printed page or are not relevant due to the exclusion of their module from XHTML-Print. Other attributes have equivalent CSS properties that when present take precedence over the attribute. Other attributes are not REQUIRED but if supported by a printer, support SHOULD be provided in the RECOMMENDED manner.

Each attribute in the following sections is annotated to indicate how it should be treated bythe processing REQUIRED of a conforming printer:

Key	Description
MUSTYes	Support is mandatory; a conforming printer MUST implementhonor this attribute
SHOULD	The attribute is concerned with functionality that SHOULD be implemented but MAY be beyond the capability of a conforming printer. For example, a monochrome printer can only render a gray scale equivalent of color images. A conforming printer MUST not treat this attribute as an error.
MAY	The attribute's functionality is considered too complex, either in processing or memory requirements, for a conforming printer. For example, determining vertical alignment within the cells of a row that spans multiple pages could exceed a low cost printer's available memory, therefore, it is not REQUIRED of a conforming printer. A conforming printer MUST NOT treat this attribute as an error.
N/ANo	The attribute does Not Apply to the printed page;Support is optional; a conforming printer MAY ignore this attribute for one of the following reasons, but cannot treat it as an error: The attribute applies to a user interface which is not represented on a printed page. For example, the accesskey attribute is irrelevant. The attribute applies to form submission which is not performed by the printer, the method attribute of the form element for example, The attribute, such as title, describes data which is not represented on a printed page The attribute applies to objects other than JPEG images, such as Jjava applets. The attribute does not apply since links specified by the anchor element are not followed. The attribute is part of functionality that is deemed too complex for low cost printers, such as language specific processing, printing on landscape oriented pages, buffering of images for later use, and vertical alignment of cell data in tables that span multiple pages.

The Modularization of XHTML ([XHTMLMOD], section 5.1) contains a set of attribute collections for ease of presentation. This specification continues this practice with the same conditions, that isas in [XHTMLMOD], that the collections below are informative and their contents normative.

Collection Name	Attributes in Collection	REQUIRED ProcessingSupported
Core	class (NMTOKENS†)	MUSTYes
Core	id (ID†)	MUSTYes
Core	title (CDATA†)	N/ANo
I18N	xml:lang (NMTOKEN†)	MAYNo
Style	style (CDATA†)	SHOULDYes
Common	Core + I18N + Style	See Collections

Table Note:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

Note that the title attribute of the Core collection is not applicable to the printed page since there is no place to display such supplementary information.

Note that support for the xml:lang attribute is optional,if a A printer MAY supports special processing based on the naturalspoken language of the document, such as the use of guillemots for quotation marks in French text. If a printer implements processing based on the natural language of the document, that processing SHALL be controlled by ththe xml:langthis attribute.

A printer SHOULD support CSS style sheets, as noted in section 1.3.2 Presentation, within the limits of its capabilities.

3.2 Structure Module

Elements	Attributes	REQUIRED ProcessingSupported
body	Common	See Collection
head	I18N,	See Collection
head	profile (URI†)	MAYNo
html	I18N,	See Collection
html	version (CDATA†),	N/ANo
html	xmlns (URI† = "http://www.w3.org/1999/xhtml")	MUSTYes
title	I18N	See Collection

Table Note:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

If the printer implements support for meta data then it MUST support the profile attribute of the head element.

The version attribute is not applicable for printing since it was deprecated in the HTML 4.01 Specification [HTML4] in favor of version information within the DTD.

A printer can ignore the content of the title element since it is not part of the document's body.

3.3 Text Module

Elements	Attributes	REQUIRED ProcessingSupported
abbr, acronym, address	Common	See Collection
blockquote	Common,	See Collection
blockquote	cite (URI†)	N/ANo
br	Core	See Collection
cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p	Common	See Collection
pre	Common,	See Collection
pre	xml:space="preserve"	MUSTYes
q	Common,	See Collection
q	cite (URI†)	N/ANo
samp, span, strong, var	Common	See Collection

Table Note:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

xml:space="preserve" is the default for all elements in XHTML, and is a mechanism for specifying that space is preserved on input of the document. To specify that space is also preserved on output, the CSS property 'whitespace' is used. In the absence of any CSS rules to the contrary, the <pre> element MUST be rendered as if it has a value for the CSS whitespace property of 'pre'.The CSS white-space property is preferred over the xml:space attribute, since the attribute is an internal mechanism between the XML processor and the formatting application and doesn't directly control the formatting of the output.

3.4 Hypertext Module

Element	Attributes	REQUIRED ProcessingSupported
a	Common,	See Collection
a	accesskey (Character†),	N/ANo
a	charset (Charset†),	N/ANo
a	href (URI†),	N/ANo
a	hreflang (LanguageCode†),	N/ANo
a	rel (LinkTypes†),	N/ANo
a	rev (LinkTypes†),	N/ANo
a	tabindex (Number†),	N/ANo
a	type (ContentType†)	N/ANo

Table Note:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

3.5 List Module

Elements	Attributes	REQUIRED ProcessingSupported
dl, dt, dd, ol, ul, li	Common	See Collection

3.6 Presentation Module

Elements	Attributes	REQUIRED ProcessingSupported
b, big, hr, i, small, sub, sup, tt	Common	See Collection

Table Note:

† See [XHTMLMOD],section 4.3

3.7 Basic Forms Module

Elements	Attributes	REQUIRED ProcessingSupported
form	Common,	See Collection
form	action* (URI†),	N/ANo
form	method ("get"** | "post"),	N/ANo
form	enctype (ContentType†)	N/ANo
input	Common,	See Collection
input	accesskey (Character†),	N/ANo
input	checked ("checked"),	MUSTYes
input	maxlength (Number†),	N/ANo
input	name (CDATA†),	N/ANo
input	size (Number†),	MUSTYes
input	src (URI†),	N/ANo
input	tabindex (Number†),	N/ANo
input	type("text"** )	MUSTYes
input	type("password" )	MUSTYes
input	type("checkbox" )	MUSTYes
input	type("radio" )	MUSTYes
input	type("submit")	MUSTYes
input	type("reset" )	MUSTYes
input	type("hidden" )	MUSTYes
input	value (CDATA†)	MUSTYes
label	Common,	See Collection
label	accesskey (Character†),	N/ANo
label	for (IDREF†)	N/ANo
select	Common,	See Collection
select	multiple ("multiple"),	N/ANo
select	name (CDATA†),	N/ANo
select	size (Number†),	MUSTYes
select	tabindex (Number†)	N/ANo
option	Common,	See Collection
option	selected ("selected"),	MUSTYes
option	value (CDATA†)	MUSTYes
textarea	Common,	See Collection
textarea	accesskey (Character†),	N/ANo
textarea	cols* (Number†),	MUSTYes
textarea	name (CDATA†),	N/ANo
textarea	rows* (Number†),	MUSTYes
textarea	tabindex (Number†)	N/ANo

Table Notes:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

* The attribute MUST be present.

** The value is the default.

The src attribute of the <input> element is not supported since the 'image' type is not part of basic forms.

The 'hidden' type for the <input> element MUST be supported even though nothing is printed, so that a printer can correctly recognize and ignore the element.

3.8 Basic Tables Module

Elements	Attributes	REQUIRED ProcessingSupported
caption	Common	See Collection
table	Common,	See Collection
table	summary ( Text† )	N/ANo
td, th	Common,	See Collection
td, th	abbr (Text†),	MAYNo
td, th	align ("left" | "center" | "right"),	MUSTYes
td, th	axis (CDATA†),	N/ANo
td, th	colspan (Number†),	MUSTYes
td, th	headers (IDREFS†),	N/ANo
td, th	rowspan (Number†),	MUSTYes
td, th	scope ("row" | "col"),	N/ANo
td, th	valign ("top" | "middle" | "bottom")	MUSTYes
th	Common,	See Collection
	abbr (Text†),	MayNo
	align ("left" | "center" | "right"),	MustYes
	axis (CDATA†),	N/ANo
	colspan (Number†),	MustYes
	headers (IDREFS†),	N/ANo
	rowspan (Number†),	MustYes
	scope ("row" | "col"),	N/ANo
	valign ("top" |"middle" | "bottom")	MustYes
tr	Common,	See Collection
tr	align ("left" | "center" | "right"),	MUSTYes
tr	valign ("top" | "middle" | "bottom")	MUSTYes

Table Note:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

If a printer implements a feature to truncate the contents of a cell because of space constraints, it MUST support the abbr attribute and print the value of the abbr attribute (if present) instead of the cell's content.If a printer implements a feature to truncate the contents of a cell because of space constraints, it must support the abbr attribute so that it may print the value of the abbr attribute (if present) instead of the cell's content.

A printer MUST support the values "left," "right," and "center" for the align attribute of the td, th, and tr elements, other values are OPTIONAL. If the align attribute is missing or has an unsupported value a printer MUST act as if the align attribute has the value "left."

A printer MUST support the values "top," "middle," and "bottom" for the valign attribute of the td, th, and tr elements, other values are OPTIONAL. If the valign attribute is missing or has unrecognized value, a printer SHOULD act as if the valign attribute has the value "middle." Vertical alignment is undefined across page boundaries.

3.9 Image Module

Elements	Attributes	REQUIRED ProcessingSupported
img	Common,	See Collection
img	alt* (Text†),	MUSTYes
img	height (Length†),	MUSTYes
img	longdesc (URI†),	N/ANo
img	src* (URI†),	MUSTYes
img	width (Length†)	MUSTYes

Table Notes:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

* The attribute MUST be present.

Printers MUST support the cid [RFC2392] and http [RFC2616] schemes of a URI [RFC2396], support for other schemes is OPTIONAL.

Conforming documents SHOULD specify the width and height of the image using the width and height attributes, since some printers MAY ignore such images. (2.3.1 Formatting/Rendering Rules).

3.10 Object Module

Elements	Attributes	REQUIRED ProcessingSupported
object	Common,	See Collections
object	archive (URIs†),	N/ANo
object	classid (URI†),	N/ANo
object	codebase (URI†),	MUSTYes
object	codetype (ContentType†),	N/ANo
object	data (URI†),	MUSTYes
object	declare ("declare"),	MAYNo
object	height (Length†),	MUSTYes
object	name (CDATA†),	N/ANo
object	standby (Text†),	N/ANo
object	tabindex (Number†),	N/ANo
object	type ("image/jpeg"),	MUSTYes
object	width (Length†)	MUSTYes
param	id (ID†),	N/ANo
param	name* (CDATA†),	N/ANo
param	type (ContentType†),	N/ANo
param	value (CDATA†),	N/ANo
param	valuetype ("data"** | "ref" | "object")	N/ANo

Table Notes:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

* The attribute MUST be present.

** The value is the default.

Printers MUST support the cid [RFC2392] and http [RFC2616] schemes of a URI [RFC2396], support for other schemes is OPTIONAL.

AIf the printer MAY support inline image data as described in B.3 Using object for In-line Image Data. If it does, thenimplements object storage then the declare attribute of the object element MUST be supported.

A printer MUST treat the object as a jpeg image when the value of the object element's type attribute is "text/jpeg." A printer MAY support other types of image formats and therefore other values of the type attribute. A printer MUST process the content of the object element when it does not recognize or support the object type referenced by the value of the type attribute. What processing occurs in this situation is implementation dependent

Conforming documents SHOULD specify the width and height of the image using the width and height attributes, since some printers MAY ignore such images. (2.3.1 Formatting/Rendering Rules).

The param element's purpose is to pass data to an application specified in the enclosing object element. Since only images, which do notdon't need initialization, are supported in the object element, the paramthis element can be completely ignored.

3.11 Metainformation Module

Elements	Attributes	REQUIRED ProcessingSupported
meta	I18N,	See Collection
meta	content* (CDATA†),	N/ANo
meta	http-equiv (NMTOKEN†),	N/ANo
meta	name (NMTOKEN†),	N/ANo
meta	scheme (CDATA†)	N/ANo

Table Notes:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

* The attribute MUST be present.

A printer MAY implement support for this element and provide implementation specific processing of the meta-information. However, guidelines and/or recommendations for processing a document's meta-information are beyond the scope of this document.

If the printer implements support for features of this element, the http-equiv attribute must be supported.

3.132 Style Sheet Module

Elements	Attributes	REQUIRED ProcessingSupported
style	I18N,	See Collection
style	media (MediaDesc†),	SHOULDYes
style	title (Text†),	N/ANo
style	type* ("type/css"),	SHOULDYes
style	xml:space="preserve"	SHOULDYes

Table Notes:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

* The attribute MUST be present.

A printer MUST read and process the content of style elements where the media attribute has the value "print" or "all." A printer MAY read and process the content of style elements where the media attribute has the value "projection". A printer SHOULD ignore the content of style elements where the media attribute has any other value. The absence of the media attribute MUST be treat as if the media attribute had the value "screen."

A printer MUST read and process the content of style elements where the value of the type attribute is "text/css," all other values MUST cause the content to be ignored. Style elements without a type attribute will be treated in an implementation dependent manner.

3.143 Style Sheet Attribute Module

This module adds the style attribute to the Common attribute collection (section 3.1).

3.154 Link Module

Elements	Attributes	REQUIRED ProcessingSupported
link	Common,	See Collection
link	charset (Charset†),	MUSTYes
link	href (URI†),	MUSTYes
link	hreflang (LanguageCode†),	MAYNo
link	media (MediaDesc†),	MUSTYes
link	rel ("stylesheet"),	MUSTYes
link	rev (LinkTypes†),	N/ANo
link	type ("text/css")	MUSTYes

Table Note:

† See Modularization of XHTML ( [XHTMLMOD], section 4.3 )

Printers MUST support the cid [RFC2392] and http [RFC2616] schemes of a URI [RFC2396], support for other schemes is OPTIONAL.

If the printer implements processing based on the natural language of the document,language selection then the hreflang attribute MUST be supported.

A printer MUST read and process the content of external style sheets where the media attribute has the value "print" or "all." A printer MAY read and process the content of external style sheets where the media attribute has the value "projection". A printer SHOULD ignore the content of external style sheets where the media attribute has any other value. The absence of the media attribute MUST be treat as if the media attribute had the value "screen."

A printer SHOULD support the value "stylesheet" for the rel attribute along with the value "text/css" for the type attribute, all other values are OPTIONAL.

3.165 Base Module

Elements	Attributes	REQUIRED ProcessingSupported
base	href* (URI†)	MUSTYes

Table Notes:

† See Modularization of XHTML( [XHTMLMOD], section 4. 3

* The attribute MUST be present.

Printers MUST support the cid [RFC2392] and http [RFC2616] schemes of a URI [RFC2396], support for other schemes is OPTIONAL.

3.176 Character Entities

XHTML-Print is in the family of XHTML document types, since it is created by combining XHTML modules. The character entities that are part of XHTML-Print are, therefore, defined in XHTML Character Entities ([XHTMLMOD], Section F.1).

4. How to Use XHTML-Print

XHTML-Print inherits all the structure, encoding and other basic infrastructure specified by XHTML 1.0 [XHTML1]. The following sections describe and clarify the application and usage restrictions of XHTML-Print.

4.1 RECOMMENDED Attributes on the "img" and "object" Elements

Because many printers create the page in a serial manner from top to bottom, it is important for the printer to know the size of images before retrieving the image data itself. This information is then used to create portions of the page layout.

Therefore, the sender SHOULD include the height and width attributes within the img or the object element. Printers MAY omit from the page images that do not include height and width attributes (see item 2, Images, of section 2.3.1 ). These attributes MAY be expressed as pixels or percentages within the img or the object element. Percentages are relative to the parent element and not the page width or printable area.

This document specifies only one mandatory image format: baseline JPEG as defined in JPEG File Interchange Format [JPEG]. See Appendix A for a description of JPEG decoder requirements. Printers are not REQUIRED to support:

• Embedded thumbnails
• Rotation
• Progressive rendering

within the JFIF and EXIF files.

4.2 Style Sheets

Conforming XHTML-Print printers SHALL support both in-line and referenced style sheets within the style element or link element in the head element of a document. Conforming XHTML-Print printers SHALL also support the style attribute (i.e. in-line style) when used within other elements as defined by XHTML 1.1[XHTML1.1]. Normal cascading rules apply.

4.3 Image Data

In traditional Wweb-based applications of XHTML, image data is contained in a separate file on a Wweb server that the user agent retrieves.

However, there are circumstances where it is desirable to include the image data along with the rest of the print data. For example, sSome low cost, resource constrained clients MAY want to include images in their print output but cannot afford to include a server. Furthermore, sSome printers applications MAY require that all the print data can be encapsulated in a single file for transportability, avoiding firewall issues, etc. Therefore, conforming XHTML-Print printers MUST support two document formats: a format that contains both a document and its referenced image data and the traditional format that contains only the document.

[Informative] Furthermore, both formats MUST be supported since there is no guaranteed mechanism for the printer to advertise the formats it supports. Lacking the ability to determine a printer's support for one or both formats a sending application MUST be able to depend on support for both formats so that it can chose the format that is best for its circumstances.

See Appendix B for discussion of the method that SHALL be used to collect both XHTML-Print and associated image data into a single file or data stream.

4.4 Side-by-Side Images

Low-cost printers today often have very little memory into which page data can be stored before being printed. As such, they MAY build and print the page in swaths on the fly from the top of the page to the bottom. To enable the use of XHTML-Print in these low cost printers, some restrictions on the order of images contained in the XHTML-Print data stream MUST be added.

1. If two or more images will be even partially side-by-side on the printed page they SHOULD be included by reference, for example ( <img src="http://example.com/example10.10.2/images/logo.jpg">, or by means of a data interleaving scheme such as described in B.2.1 Interleaving Images<object data="http://10.10.10.2/images/logo.jpg">) rather than included inline. (See Appendix B). This allows the printer to get chunks of the image, as it needs it, as it prints down the page. If images aremust be included inline, the methods and techniques of Appendix B.2 are REQUIRED and the method discussed in Appendix B.3 is discouraged.
2. An XHTML-Print conforming printer lacking sufficient buffer space to hold multiple side-by-side images MAY choose to reformat the layout of the page to preserve content. Printers SHALL attempt to preserve content when encountering side-by-side images that MAY be impossible to print as specified within the XHTML-Print. Discarding the second and subsequent of the side-by-side images SHOULD be avoided unless preservation of content is best achieved by doing so. Other than attempting to best preserve content, this specification does not mandate any specific behavior when encountering this situation. Clients providing images inline SHOULD order them from left-to-right top-to-bottom unless the print direction is known to be otherwise.

4.5 Forms Usage

An HTML form is a dynamic entity when the document is displayed in a browser : data can be entered into text fields, buttons MAY be pushed, selections made, and options checked. None of this dynamic activity can be rendered on a printed page. However, a printed page can permanently record a particular state of the form. For example, users MAY wish to print forms that record products ordered or payments made.

The following discussion illustrates the activity involved when interacting with and printing forms. Please refer to Sequence Diagram 1

Sequence Diagram 1. Forms Usage

Steps:

1. The User enters a URL into the Browser
2. The Browser fetches the form from the Server and displays it
3. The User enters data into the form
4. The User asks the Browser to print the form
5. The Browser composes a page with the form and the user data
6. The Browser sends the new composed form to the printer
7. The User selects the Submit button on the form
8. The Browser sends the user data to the Server

Detailed discussion of Steps:

1. The user interacts with a browser on a mobile device to access a form presented by a server on the network (lines 1 and 2 of Sequence Diagram 1). The following fragment of an XHTML-Print document shows what the server sends to the browser to present to the user. Please note, that the form is blank when first presented to the user.
   <form action="http://example.com/prog/adduser" method="post">
   <label for="firstname">First name: </label>
   <input type="text" id="firstname" /><br />
   <label for="lastname">Last name: </label>
   <input type="text" id="lastname" /><br />
   <label for="email">email: </label>
   <input type="text" id="email" size="40" /><br />
   <input type="checkbox" name="member" value="IEEE" /> IEEE <br />
   <input type="checkbox" name="member" value="ACM" /> ACM <br />
   <input type="submit" value="Send" /> <input type="reset" />
   </form>
   

   Here is an example presentation of the above form as the user would see it:

   First name:
   Last name:
   email:
   IEEE
   ACM
   
   
2. The user enters data (line 3 of Sequence Diagram 1) into the text fields and checks the IEEE check box so that the form now looks like the following:
   
   First name:
   Last name:
   email:
   IEEE
   ACM
   
   
3. The user then clicks on the browser's print button (line 4 of Sequence Diagram 1), to print the form as it currently appears.
4. The browser then creates a, possibly new, document (line 5 of Sequence Diagram 1) containing the original form and the users data. Note in the XHTML-Print document below, created by the browser, that the user's data is include either by a value attribute or a checked attribute.
   <form action="http://example.com/prog/adduser" method="post">
   <label for="firstname">First name: </label>
   <input type="text" id="firstname" value="John"/><br />
   <label for="lastname">Last name: </label>
   <input type="text" id="lastname" value="Doe"/><br />
   <label for="email">email: </label>
   <input type="text" id="email" value="johnd@>example.org" /><br />
   <input type="checkbox" name="member" checked="checked" value="IEEE" /> IEEE <br />
   <input type="checkbox" name="member" value="ACM" /> ACM <br />
   <input type="submit" value="Send" /> <input type="reset" /><br />
   </form>
5. The browser sends (line 6 of Sequence Diagram 1) the document created in line 5 to the printer.
6. Sometime later the user clicks on the submit form button (line 7 of Sequence Diagram 1) and the browser submits the form (line 8 of Sequence Diagram 1) using the procedures given in the HTML 4.01 Specification ([HTML4], Forms Submission).

5. Acknowledgements

This section is informative.

This specification is based, almost exclusively, on the specification of the same name, XHTML^™-Print [XHTMLPRINT], from was prepared by the Printer Working GroupPWG, a program of and through the IEEE Industry Standards and Technology Organization, Inc., XHTML-Print Working Group and the editor wishes to express his gratitude to all of those who contributed to it.

A. JPEG Decoder Requirements

A.1 Introduction

A.1.1 Intent

This appendix describes RECOMMENDED behaviors for JPEG decoders in XHTML-Print devices. Behaviors for both minimal printers and enhanced layout printers are described. Many of the behaviors described in this document follow directly from language already present in the relevant JPEG standards, but are repeated here to emphasize their importance.

A.1.2 Objectives

The decoder behaviors described in this document are intended to minimize implementation complexity, while retaining maximum compatibility with existing JPEG files. In particular, these recommendations seek to ensure compatibility with both EXIF and baseline JFIF (i.e. the subset of JFIF files that use only baseline JPEG processes). Support for JPEG streams using non-baseline processes, such as arithmetic coding or progressive coding, is not mandated for XHTML-Print compliance.

A.2 Behaviors of Minimal Printers

This section describes behaviors of JPEG decoders for minimal XHTML-Print implementations.

A.2.1 JPEG Processes

A JPEG decoder for an XHTML-Print printer SHALL support all baseline JPEG processes as defined in [CCITT], except for 2- and 4-component images. These processes include grayscale and 3-component images, 8-bit/component sample depth, Huffman entropy coding, 444, 422, 411, and 400 subsampling modes, and sequential (i.e. non-progressive) scan.

A.2.2 Handling of APPx Markers

Baseline decoders MAY ignore application-specific markers, such as the JFIF APP0 marker and the EXIF APP1/APP2 markers. This will cause all images to print in an un-rotated orientation, with image size as specified in the JPEG SOF marker if not overridden by XHTML-Print mark-up. A JPEG decoder for a minimal printer SHALL NOT fail as a consequence of encountering an unsupported APPx marker (i.e. all such markers SHALL be correctly parsed, even if they are ignored).

A.2.3 Color Management

This section describes a RECOMMENDED color management approach for minimal XHTML-Print printers.

Greyscale Images

Sample values in a grayscale (single-component) JPEG image SHALL be converted to the sRGB color space by setting

R_out= G_out= B_out= Gray_in

Color Images

Sample values in 3-component JPEG images SHALL be interpreted as YCbCr samples, as would be obtained by applying the matrices described in ITU BT.601 [BT601.5] to sRGB input data.

A.3 JPEG Decoder for XHTML-Print Enhanced Layout Extension

This section describes behaviors of JPEG decoders for XHTML-Print devices that support the XHTML-Print Enhanced Layout Extension, an OPTIONAL feature block. The behaviors described below SHOULD be interpreted as "in addition to" those described in XHTML-Print Document Type and Printer Conformance (the requirements for minimal XHTML-Print devices).

A.3.1 Handling of EXIF APP1 and APP2 Markers

A JPEG decoder for an XHTML-Print implementation which supports the Enhanced Layout Extension MAY decode the TIFF IFDs embedded in the EXIF APP1 and APP2 markers, as described in Section 2.6.4 of [JEIDA]. The following IFDs MAY be supported. However, any future XHTML elements or CSS properties affecting image orientation SHALL take precedence over these IFDs.

B. Inline Image Data

B.1 Introduction

B.1.1 Intent

The intent of this appendix is to describe the method for including XHTML-Print and associated image data in a single data stream or file. Support for Inline Image Data is REQUIREDconditionally mandatory; i.e. any device supporting Inline Image Data SHALL support this method. (See Image Data.) Mandating support for Inline Image Data is outside the scope of this document.

In addition to images, if separate style sheets are to be interleaved with the XHTML-Print data, the same method SHALL be used.

B.1.2 Objectives

• Minimize image data size
• No or minimal additional encoding / decoding of image data REQUIRED
• Enable juxtaposition between image data and associated XHTML-Print content
• Many printers are unable to buffer significant amounts of page content data, so the image data is printed more or less as it is received. This implies the image data SHALL be sent near the related XHTML-Print content, so that layout and printing can occur without extensive data buffering.
• Minimize complexity
• Leverage existing standard capabilities

B.2 MIME type Application/Multiplexed

This section includes by reference the entirety of "RFC3391 - The MIME Application/Multiplexed Content-type", Robert Herriot [MIMEMPX]. All printers MUST support inline data using RFC3391[MIMEMPX].For all printers that support inline data, [MIMEMPX] SHALL be supported.

Producers and consumers of Application/Vnd.pwg-multiplexed entities (compound documents), as defined in [MIMEMPX], SHOULD consider each component image message of the compound document as having one and only one reference. The producer of the compound document MUST assume that the consumer of the compound documentApplication/Vnd.pwg-multiplexed entity has limited memory and therefore include a unique image message for each image reference found in the root document. If a ContentID is present in the header of an image message, that ContentID MUST be unique. If a Content-Location is present in the header of an image message, that Content-Location is REQUIRED to be unique except for the special case where a repeated reference to the same image URL causes several messages containing the same image data to be present in the compound document. Consumers MAY release the message data associated with an image reference as the image is rendered, because the Consumer can be confident that another reference to the same image will be accompanied by another message containing the image data. Consumers MAY also substitute image data for a message with a given Content-Location header value with image data from other messages with the same Content-Location header value because Consumers can be confident that messages with identical Content-Location values do in fact contain identical data.

URL references in the root document of the multiplexed document MUST be matched to Content-Location and/or Content-ID fields of the referenced message object according to the rules given by [RFC2557]. An exception to the rules given by [RFC2557] occurs when a reference is made to a message object named with a Content-Location. In that special case, multiple instances of that message are REQUIRED in the compound document.

B.3 Using object for In-Line Image Data

This section is informative.

An alternative method to include inline image data in XHTML-Print is via the object element and a forward reference. The declare attribute of the object element is used to define the object, but delay its processing. The id attribute is used to associate the forward reference with the image content, sent at the end of the XHTML-Print document. Because this method normally encodes the binary image data using base64 encoding, a significant increase in the size of the data transmitted will be experienced. This SHOULD be avoided over low speed connections.  Printers supporting inline data MAY support base64 encoding using object.

See RFC2397 for information on the "data" URL scheme.

This method MAY be useful for very simple clients that cannot afford a server for image download or for some reason cannot utilize the Application/Multiplexed MIME type; however, it is not RECOMMENDED for general use especially if the size of the printer's buffer is unknown.

C. XHTML-Print DTD and Modules

This section contains the pieces of the XHTML-Print DTD that are unique to XHTML-Print. The remaining entities and modules are as specified in reference [XHTMLMOD].

The following SHOULD be used from Modularization of XHTML [XHTMLMOD]:

1. xhtml-attribs-1.mod
2. xhtml-base-1.mod
3. xhtml-basic-form-1.mod
4. xhtml-basic-table-1.mod
5. xhtml-blkphras-1.mod
6. xhtml-blkpres-1.mod
7. xhtml-blkstruct-1.mod
8. xhtml-charent-1.mod
9. xhtml-datatypes-1.mod
10. xhtml-framework-1.mod
11. xhtml-hypertext-1.mod
12. xhtml-image-1.mod
13. xhtml-inlphras-1.mod
14. xhtml-inlpres-1.mod
15. xhtml-inlstruct-1.mod
16. xhtml-inlstyle-1.mod
17. xhtml-lat1.ent
18. xhtml-link-1.mod
19. xhtml-list-1.mod
20. xhtml-meta-1.mod
21. xhtml-notations-1.mod
22. xhtml-object-1.mod
23. xhtml-param-1.mod
24. xhtml-pres-1.mod
25. xhtml-qname-1.mod
26. xhtml-special.ent
27. xhtml-struct-1.mod
28. xhtml-style-1.mod
29. xhtml-symbol.ent
30. xhtml-text-1.mod

C.1. XHTML-Print 1.0 DTD

<!-- ....................................................................... -->
<!-- XHTML-Print 1.0 DTD ................................................... -->
<!-- file: xhtml-print10.dtd
-->

<!-- XHTML-Print 1.0 DTD

     This is XHTML-Print 1.0, a variant of XHTML Basic for printing.

     Copyright 2001-2003 Printer Working Group, All Rights Reserved.
     

     Permission to use, copy, modify and distribute the XHTML-Print DTD and
     its accompanying documentation for any purpose and without fee is hereby
     granted in perpetuity, provided that the above copyright notice and
     this paragraph appear in all copies.  The copyright holders make no
     representation about the suitability of the DTD for any purpose.

     It is provided "as is" without expressed or implied warranty.

        Author:   Jun Fujisawa <fujisawa.jun@canon.co.jp>
        Revision: $Id: xhtml-print10.dtd,v 1.5 2003/02/09 06:59:04 fujisawa Exp $


-->
<!-- This is the driver file for version 1.0 of the XHTML-Print DTD.

     This DTD is identified by the PUBLIC and SYSTEM identifiers:

        PUBLIC "-//PWG//DTD XHTML-Print 1.0//EN"
        SYSTEM "http://www.xhtml-print.org/xhtml-print/xhtml-print10.dtd"
-->
<!ENTITY % XHTML.version "-//PWG//DTD XHTML-Print 1.0//EN" >

<!-- Use this URI to identify the default namespace:

         "http://www.w3.org/1999/xhtml"
-->
<!ENTITY % NS.prefixed "IGNORE" >
<!ENTITY % XHTML.prefix "" >

<!-- Reserved for use with the XLink namespace:
-->
<!ENTITY % XLINK.xmlns "" >
<!ENTITY % XLINK.xmlns.attrib "" >

<!-- reserved for future use with document profiles -->
<!ENTITY % XHTML.profile "" >

<!-- Bidirectional Text features
     This feature-test entity is used to declare elements
     and attributes used for bidirectional text support.
-->
<!ENTITY % XHTML.bidi "IGNORE" >

<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->

<!ENTITY % xhtml-events.module "IGNORE" >
<!ENTITY % xhtml-bdo.module "%XHTML.bidi;" >

<!-- Style Attribute Module ............................ -->
<!ENTITY % xhtml-inlstyle.module "INCLUDE" >
<![%xhtml-inlstyle.module;[
<!ENTITY % xhtml-inlstyle.mod
     PUBLIC "-//W3C//ENTITIES XHTML Inline Style 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-inlstyle-1.mod" >
%xhtml-inlstyle.mod;]]>

<!-- Document Model Module ............................. -->
<!ENTITY % xhtml-model.mod
     PUBLIC "-//PWG//ENTITIES XHTML-Print 1.0 Document Model 1.0//EN"
            "http://www.pwg.org/xhtml-print/xhtml-print10-model-1.mod" >

<!-- Modular Framework Module (required) ............... -->
<!ENTITY % xhtml-framework.mod
     PUBLIC "-//W3C//ENTITIES XHTML Modular Framework 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-framework-1.mod" >
%xhtml-framework.mod;

<!-- Text Module (required) ............................ -->
<!ENTITY % xhtml-text.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Text 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-text-1.mod" >
%xhtml-text.mod;

<!-- Hypertext Module (required) ....................... -->
<!ENTITY % xhtml-hypertext.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Hypertext 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-hypertext-1.mod" >
%xhtml-hypertext.mod;

<!-- Lists Module (required) ........................... -->
<!ENTITY % xhtml-list.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Lists 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-list-1.mod" >
%xhtml-list.mod;

<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->

<!-- Presentation Module ............................... -->
<!ENTITY % xhtml-pres.module "INCLUDE" >
<![%xhtml-pres.module;[
<!ENTITY % xhtml-pres.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Presentation 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-pres-1.mod" >
%xhtml-pres.mod;]]>

<!-- Image Module ...................................... -->
<!ENTITY % xhtml-image.module "INCLUDE" >
<![%xhtml-image.module;[
<!ENTITY % xhtml-image.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Images 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-image-1.mod" >
%xhtml-image.mod;]]>

<!-- Tables Module ..................................... -->
<!ENTITY % xhtml-table.module "INCLUDE" >
<![%xhtml-table.module;[
<!ENTITY % xhtml-table.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Basic Tables 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-basic-table-1.mod" >
%xhtml-table.mod;]]>

<!-- Forms Module ...................................... -->
<!ENTITY % xhtml-form.module "INCLUDE" >
<![%xhtml-form.module;[
<!ENTITY % xhtml-form.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Basic Forms 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-basic-form-1.mod" >
%xhtml-form.mod;]]>

<!-- Style Sheet Module ................................ -->
<!ENTITY % xhtml-style.module "INCLUDE" >
<![%xhtml-style.module;[
<!ENTITY % xhtml-style.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Style Sheets 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-style-1.mod" >
%xhtml-style.mod;]]>

<!-- Link Module ....................................... -->
<!ENTITY % xhtml-link.module "INCLUDE" >
<![%xhtml-link.module;[
<!ENTITY % xhtml-link.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Link Element 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-link-1.mod" >
%xhtml-link.mod;]]>

<!-- Metainformation Module ............................ -->
<!ENTITY % xhtml-meta.module "INCLUDE" >
<![%xhtml-meta.module;[
<!ENTITY % xhtml-meta.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Metainformation 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-meta-1.mod" >
%xhtml-meta.mod;]]>

<!-- Base Module ....................................... -->
<!ENTITY % xhtml-base.module "INCLUDE" >
<![%xhtml-base.module;[
<!ENTITY % xhtml-base.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Base Element 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-base-1.mod" >
%xhtml-base.mod;]]>

<!-- Param Module ...................................... -->
<!ENTITY % xhtml-param.module "INCLUDE" >
<![%xhtml-param.module;[
<!ENTITY % xhtml-param.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Param Element 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-param-1.mod" >
%xhtml-param.mod;]]>

<!-- Object Module ..................................... -->
<!ENTITY % xhtml-object.module "INCLUDE" >
<![%xhtml-object.module;[
<!ENTITY % xhtml-object.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Embedded Object 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-object-1.mod" >
%xhtml-object.mod;]]>

<!-- Structure Module (required) ....................... -->
<!ENTITY % xhtml-struct.mod
     PUBLIC "-//W3C//ELEMENTS XHTML Document Structure 1.0//EN"
            "http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-struct-1.mod" >
%xhtml-struct.mod;

<!-- end of XHTML-Print 1.0 DTD ............................................ -->
<!-- ....................................................................... -->

C.2. XHTML-Print 1.0 Document Model Module

<!-- ....................................................................... -->
<!-- XHTML-Print 1.0 Document Model Module ................................. -->
<!-- file: xhtml-print10-model-1.mod

     This is XHTML-Print 1.0, a variant of XHTML Basic for printing.

     Copyright 2001-2003 Printer Working Group, All Rights Reserved.
     Revision: $Id: xhtml-print10-model-1.mod,v 1.5 2003/02/09 06:59:04 fujisawa Exp $


     This DTD module is identified by the PUBLIC and SYSTEM identifiers:

        PUBLIC "-//PWG//ENTITIES XHTML-Print 1.0 Document Model 1.0//EN"
        SYSTEM "http://www.xhtml-print.org/xhtml-print/xhtml-print10-model-1.mod"

     ....................................................................... -->

<!-- XHTML-Print 1.0 Document Model

     This module describes the groupings of elements that make up
     common content models for XHTML-Print elements.
-->

<!-- Optional Elements in head ......................... -->

<!ENTITY % HeadOpts.mix
     "( %meta.qname; | %link.qname; | %object.qname; | %style.qname; )*" >

<!-- Miscellaneous Elements ............................ -->

<!ENTITY % Misc.class "" >

<!-- Inline Elements ................................... -->

<!ENTITY % InlStruct.class "%br.qname; | %span.qname;" >

<!ENTITY % InlPhras.class
     "| %em.qname; | %strong.qname; | %dfn.qname; | %code.qname;
      | %samp.qname; | %kbd.qname; | %var.qname; | %cite.qname;
      | %abbr.qname; | %acronym.qname; | %q.qname;" >

<!ENTITY % InlPres.class
     "| %tt.qname; | %i.qname; | %b.qname; | %big.qname;
      | %small.qname; | %sub.qname; | %sup.qname; " >

<!ENTITY % I18n.class "" >

<!ENTITY % Anchor.class "| %a.qname;" >

<!ENTITY % InlSpecial.class "| %img.qname; | %object.qname;" >

<!ENTITY % InlForm.class
     "| %input.qname; | %select.qname; | %textarea.qname;
      | %label.qname;"
>

<!ENTITY % Inline.extra "" >

<!ENTITY % Inline.class
     "%InlStruct.class;
      %InlPhras.class;
      %InlPres.class;
      %Anchor.class;
      %InlSpecial.class;
      %InlForm.class;
      %Inline.extra;"
>

<!ENTITY % InlNoAnchor.class
     "%InlStruct.class;
      %InlPhras.class;
      %InlPres.class;
      %InlSpecial.class;
      %InlForm.class;
      %Inline.extra;"
>

<!ENTITY % InlNoAnchor.mix
     "%InlNoAnchor.class;
      %Misc.class;"
>

<!ENTITY % Inline.mix
     "%Inline.class;
      %Misc.class;"
>

<!-- Block Elements .................................... -->

<!ENTITY % Heading.class
     "%h1.qname; | %h2.qname; | %h3.qname;
      | %h4.qname; | %h5.qname; | %h6.qname;"
>
<!ENTITY % List.class  "%ul.qname; | %ol.qname; | %dl.qname;" >

<!ENTITY % Table.class "| %table.qname;" >

<!ENTITY % Form.class  "| %form.qname;" >

<!ENTITY % BlkStruct.class "%p.qname; | %div.qname;" >

<!ENTITY % BlkPhras.class
     "| %pre.qname; | %blockquote.qname; | %address.qname;"
>

<!ENTITY % BlkPres.class "| %hr.qname;" >

<!ENTITY % BlkSpecial.class
     "%Table.class;
      %Form.class;"
>

<!ENTITY % Block.extra "" >

<!ENTITY % Block.class
     "%BlkStruct.class;
      %BlkPhras.class;
      %BlkPres.class;
      %BlkSpecial.class;
      %Block.extra;"
>

<!ENTITY % Block.mix
     "%Heading.class;
      | %List.class;
      | %Block.class;
      %Misc.class;"
>

<!-- All Content Elements .............................. -->

<!ENTITY % FlowNoTable.mix
     "%Heading.class;
      | %List.class;
      | %BlkStruct.class;
      %BlkPhras.class;
      %BlkPres.class;
      %Form.class;
      %Block.extra;
      | %Inline.class;
      %Misc.class;"
>

<!ENTITY % Flow.mix
     "%Heading.class;
      | %List.class;
      | %Block.class;
      | %Inline.class;
      %Misc.class;"
>

<!-- end of xhtml-print10-model-1.mod -->

D. References

D.1. Normative References

[HTML4]

"HTML 4.01 Specification", W3C Recommendation, D. Raggett, A. Le Hors, I. Jacobs, eds., World Wide Web Consortium, 24 December 1999. Available at: http://www.w3.org/TR/1999/REC-html401-19991224.  The latest version is available at: http://www.w3.org/TR/html4

[XHTML1]

"XHTML 1.0: The Extensible HyperText Markup Language - A Reformulation of HTML 4 in XML 1.0", W3C Recommendation, Steven Pemberton, et al., World Wide Web Consortium, 26 January 2000. Available at: http://www.w3.org/TR/2000/REC-xhtml1-20000126.  The latest version is available at: http://www.w3.org/TR/xhtml1

[XHTML1.1]

"XHTML 1.1 - Module-based XHTML", W3C Recommendation, Murray Altheim, Shane McCarron, eds., World Wide Web Consortium, 31 May 2001. Available at: http://www.w3.org/TR/2001/REC-xhtml11-20010531.  The latest version is available at: http://www.w3.org/TR/xhtml11

[XHTMLBASIC]

"XHTML Basic", W3C Recommendation, Mark Baker, Masayasu Ishikawa, et al., eds., World Wide Web Consortium, 19 December 2000 is available at: http://www.w3.org/TR/2000/REC-xhtml-basic-20001219.  The latest version is available at: http://www.w3.org/TR/xhtml-basic

[XHTMLMOD]

"Modularization of XHTML", W3C Recommendation, M. Altheim, F. Boumphrey, S. Dooley, S. McCarron, eds., World Wide Web Consortium, 10 April 2001. Available at: http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410. The latest version is available at: http://www.w3.org/TR/xhtml-modularization

[XML]

"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, eds., World Wide Web Consortium, 6 October 2000. Available at: http://www.w3.org/TR/2000/REC-xml-20001006.  The latest version is available at: http://www.w3.org/TR/REC-xml

[CSSPP]

"CSS Print Profile", Printer Working Group Proposed Standard 5102.2, March 31, 2003 J. Bigelow, Printer Working Group, 31 March 2003. Available at: http://www.pwg.org/xhtml-print/HTML-Version/CSS-Print.html

[CSS1]

"Cascading Style Sheets, Llevel 1",W3C Recommendation,  Håkon Wium Lie, Bert Bos, eds., World Wide Web Consortium, 11 January 1999. Available at: http://www.w3.org/TR/1999/REC-CSS1-19990111.  The latest version is available at: http://www.w3.org/TR/REC-CSS1

[CSS2]

"Cascading Style Sheets, Llevel 2", W3C Recommendation, Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, eds., World Wide Web Consortium, 12 May 1998.  Available at: http://www.w3.org/TR/1998/REC-CSS2-19980512 . The latest version is available at:  http://www.w3.org/TR/REC-CSS2

[CSS3]

"Introduction to CSS3", W3C Working Group Draft, Eric A. Meyer, Bert Bos, eds., 23 May 2001.  Available at: http://www.w3.org/TR/2001/WD-css3-roadmap-20010523/. The latest version is available from: http://www.w3.org/Style/Group/css3-src/css3-roadmap/

[PAGEMEDIA]

Paged Media Properties for CSS3, Working Group Draft, Robert Stevahn, World Wide Web Consortium, 28 September 1999. Available from http://www.w3.org/TR/1999/WD-css3-page-19990928

[RFC2119]

"RFC2119 - Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, The Internet Engineering Task Force, March 1997. It is available from http://www.ietf.org/rfc/rfc2119.txt?number=2119

[JPEG]

"JPEG File Interchange Format, version 1.02, September 1, 1992", Eric Hamilton, C-Cube Microsystems, 1 September 1992. Available from ftp://ftp.uu.net/graphics/jpeg/jfif.ps.gz or ftp://ftp.uu.net/graphics/jpeg/jfif.txt.gz

[CCITT]

"CCITT Recommendation T.81 | ISO/IEC 10918-1, Digital Compression and Coding of Continuous-tone Still Images: Requirements and Guidelines", ISO, 21 January 2000. Available from http://www.iso.org/iso/en/StandardsQueryFormHandler.StandardsQueryFormHandler

[JEIDA]

"JEIDA-49-1998 Digital still camera image file format standard(exif)", Japan Electronics and Information Technology Industries Association (JEITA). Available from http://tsc.jeita.or.jp/

[MIMEMPX]

"RFC3391 - The MIME Application/Vnd.pwg-multiplexed Content-Type", R. Herriot, The Internet Engineering Task Force,. December 2002. It is available from http://www.ietf.org/rfc/rfc3391.txt

[RFC2392]

Content-ID and Message-ID Uniform Resource Locators, E.Levinson, The Internet Engineering Task Force, August 1998. It is available from http://www.ietf.org/rfc/rfc2392.txt

[RFC2396]

Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, The Internet Engineering Task Force, August 1998. It is available from http://www.ietf.org/rfc/rfc2396.txt

[RFC2397]

"RFC2397 - The "data" URL scheme", L. Masinter, The Internet Engineering Task Force, August 1998. It is available from http://www.ietf.org/rfc/rfc2397.txt

[RFC2616]

Hypertext Transfer Protocol -- HTTP/1.1, T. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, The Internet Engineering Task Force, June 1999. It is available from http://www.ietf.org/rfc/rfc2616.txt

[RFC3023]

"RFC3023 - XML Media Types", M. Murata, S. St.Laurent, and D. Kohn, The Internet Engineering Task Force,. January 2001. It is available from http://www.ietf.org/rfc/rfc3023.txt.

[RFC3236]

"RFC3236 - The 'application/xhtml+xml' Media Type", M. Baker, The Internet Engineering Task Force,. January 2002. It is available from http://www.ietf.org/rfc/rfc3236.txt.

[RFC2557]

"RFC2557 - MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", J.Palme, A. Hopmann, N. Shelness,, The Internet Engineering Task Force, March 1999. It is available from http://www.ietf.org/rfc/rfc2557.txt.

[BT601.5]

ITU-R Recommendation BT.601-5, "Studio Encoding Parameters of Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect Ratios", International Telecommunications Union, October 1995. It is available from http://www.itu.int/ITU-R

D.2. Informative References

[XHTMLPRINT]

XHTML-Print, Printer Working Group PWG Propose Standard 5102.1, Don Wright, Melinda Grant, Peter Zehler, Jun Fujisawa, and Jim Bigelow, eds. Printer Working Group, 31 March 2003March 31, 2003. Available at: http://www.pwg.org/xhtml-print/HTML-Version/XHTML-Print.html.

[RFC2045]

"RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed, N. Borenstein, Section 6.8. "Base64 Content-Transfer-Encoding" is of particular interest. It is available at http://www.ietf.org/rfc/rfc2045.txt

[CHTML]

Compact HTML for Small Information Appliances, W3C Note, T. Kamada, 9 February 1998. Available at: http://www.w3.org/TR/1998/NOTE-compactHTML-19980209

[GUIDELINES]

"HTML 4.0 Guidelines for Mobile Access, W3C Note, T. Kamada, T. Asada, M. Ishikawa, S. Matsui, eds., 15 March 1999. Available at: http://www.w3.org/TR/1999/NOTE-html40-mobile-19990315
The latest version is available at: http://www.w3.org/TR/NOTE-html40-mobile

[WCAG10]

"Web Content Accessibility Guidelines 1.0", W3C Recommendation, W. Chisholm, G. Vanderheiden, I. Jacobs, eds., 5 May 1999. Available at: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
The latest version is available at: http://www.w3.org/TR/WCAG10

[WML]

"Wireless Markup Language Specification", WAP Forum Ltd. Available from http://www.wapforum.org/what/technical.htm

Comments are owned by the poster. All other material is Copyright © 2001-2024 The Printer Working Group. All rights reserved. IPP Everywhere, the IPP Everywhere logo, and the PWG logo are trademarks of the IEEE-ISTO.
About the PWG · Privacy Policy · PWG Webmaster