Publication Structure 1.0.1 Publication Structure 1.0.1 Publication Structure 1.0.1Copyright © 2001 by Open eBook Forum™.
All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the Open eBook Forum.
The purpose of the Open eBook Publication Structure is to provide a specification for representing the content of electronic books. Specifically:
This specification is based on the premise that in order for electronic-book technology to achieve widespread success in the marketplace, reading systems must have convenient access to a large number and variety of titles.
This specification has been developed through a cooperative effort, bringing together publishers, reading system vendors, software developers, and experts in the relevant standards. The “Open eBook Authoring Group” was composed of the following people (affiliations given are those at the time of publishing version 1.0, September 16, 1999):
Version 1.0.1 of this specification was prepared by the Open eBook Forum Publication Structure Working Group. Active members of the working group at the time of publication of this revision (1.0.1) were:
This specification combines subsets and applications of other specifications. Together, these facilitate the construction, organization, presentation, and unambiguous interchange of electronic documents:
OEB is based on XML because of its generality and simplicity, and because this increases the likelihood that documents will survive longer. XML also provides well-defined rules for the syntax of documents, which decreases the cost to implementers and reduces incompatibility across systems. Further, XML enables extensibility because it is not tied to any particular set of element types, it supports internationalization, and it encourages document markup that can represent a document’s internal parts more directly, making them amenable to formatting and other types of computer processing.
OEB reading systems must be XML processors as defined in XML 1.0. All OEB documents must be well-formed XML documents, although they need not be valid XML documents. However, this specification ensures that for any basic OEB document, there is a syntax form that:
The last point above does not claim full HTML 4.0 conformance for one primary reason: HTML 4.0 supports the XML empty element syntax in practice (i.e., it works in browsers) but not in formal HTML 4.0 specifications prior to XHTML 1.0.
XML well-formedness requires characteristics beyond what HTML browsers typically require, such as:
Empty elements are those (such as the HTML br and hr elements) that permit no content. The XML and formal HTML syntaxes for these are incompatible, though the XML form with whitespace before the trailing slash is accepted by most HTML browsers (and is strictly conformant XML, as XML ignores whitespace within tags. For this reason, this specification requires this (conforming) variation of the XML form (for example, “<br />”); this is the most portable syntax and it contributes the most to document longevity, even though, strictly speaking, it is not valid in HTML.
Syntactic transformation from valid HTML to well-formed XML is trivial (though semantic transformations that also add brand-new structure and information value may not be). Transformation from invalid but moderately clean HTML is also usually an easy process and easily automated: several free tools already exist for this, such as “Tidy” (see http://www.w3.org/People/Raggett/tidy/). Transformation from extremely dirty HTML to XML, however, is of unpredictable complexity.
Not all well-formed XML 1.0 documents are conformant OEB documents. This is because this specification imposes further constraints in order to improve interoperability. These constraints are the “OEB Common Requirements,” defined below.
This specification defines two XML DTDs—the package DTD and the basic OEB document DTD. The package forms the “root” of a complete publication, and reading systems should use it to find and organize publication components. The basic OEB document DTD formally defines the HTML subset described in this specification.
This version of the specification does not demand that reading systems process XML namespace prefixes according to the XML Namespaces Recommendation at http://www.w3.org/TR/REC-xml-names.
Namespace prefixes are a method for prefixing element and attribute names to distinguish identical names that are drawn from different definition sets. A prefix is associated with a unique URI by an XML namespace declaration. Alternatively, a namespace declaration may identify a URI as the default namespace, applicable to elements lacking a namespace prefix. The XML namespace prefix is separated from the suffix element by a colon.
This specification forbids the use of an oeb: namespace prefix within OEB documents. The use of the dc: prefix, however, is required for Dublin Core metadata element attributes in the OEB package. An element within the OEB document that contains a namespace prefix is treated as an extended element, with the colon acting as a normal XML name character. Reading systems must recognize the colon as a valid name character within an OEB document.
For upwards compatibility, the element dc-metadata in an OEB package is required to have an attribute of xmlns:dc="http://purl.org/dc/elements/1.0/" and xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.0/". In addition, the Dublin Core elements will be declared in the OEB package DTD with an explicit prefix of dc:.
This specification recognizes the importance of current software tools, legacy data, publication practices, and market conditions, and so is based on HTML. This approach allows content providers to exploit current HTML content, tools, and expertise.
To minimize the implementation burden on reading system implementers (who may be working with devices that have power and display constraints), the publication structure does not include all HTML elements and attributes. The elements and attributes were selected from the HTML 4.0 specification and were chosen to be consistent with current directions in HTML and XHTML development and the emergence of XML. See Appendix A for a complete table of the element types in HTML 3.2, HTML 4.0, and OEB documents.
Any HTML construct deprecated in HTML 4.0 is either omitted from this specification or is deprecated; CSS-based equivalents are provided in most such cases. Stylesheet constructs are also used for new functionality beyond that provided in HTML 4.0.
To achieve predictable results and to support upwards compatibility with future versions of this specification, it is strongly recommended that basic OEB documents be valid XML documents with respect to the OEB document DTD.
This specification defines a style language based on CSS 1 and CSS 2, with a media type of “text/x-oeb1-css”. The Publication Structure Working Group is aware that this definition of a media type goes against the recommendation of the CSS Working Group (see http://www.w3.org/TR/REC-CSS1), but has chosen to do so due to practical considerations.
The CSS-based stylesheet constructs in this specification have been included to define baseline rendering functionality. To minimize the burden on reading system developers and device manufacturers, not all CSS 1 or CSS 2 properties are included. A few additional properties and values have been added for supporting page layout, headers, and footers.
In a number of cases, this specification does not require reading systems to provide the full range of rendering that a standard CSS stylesheet might request. For example, some reading systems will use monochrome displays. It would neither be acceptable to limit all reading systems to monochrome, nor to declare color use a non-standardized extension beyond OEB. In such cases, the CSS settings are allowed, and keep their meanings; but a conforming reading system may gracefully degrade to a simpler rendering.
This specification supports the inline style attribute, the style element, and externally linked stylesheets. This specification does not require that any handling of XML namespaces be performed by the reading system in the processing of stylesheets.
Stylesheets can be associated with an OEB document in several ways:
The relative priority of the first three cases is as defined for HTML 4.0 and CSS 2. Stylesheets linked via a processing instruction are treated as if they had been linked via HTML link elements preceding any actual HTML link elements. As defined in the Conformance section, if no stylesheet is defined or no applicable style is found for a given element, HTML rendering is the default as defined elsewhere in this specification and the HTML4.0 specification.
Styles attached via the first two methods listed above may use only those CSS constructs defined as supported in Section 4 of this specification. External stylesheets linked via the HTML link element or by the processing instruction xml-stylesheet, however, may use this or any other style language, such as XSL (see http://www.w3.org/TR/WD-xsl).
Only those CSS constructs defined as supported in Section 4 of this specification may be included in stylesheets of type “text/x-oeb1-css”. Stylesheets of other MIME media types may be substituted for the text/x-oeb1-css stylesheets at the discretion of the reading system.
The HTML 4.0 specification groups externally linked stylesheets into sets by their titles (including a “persistent” set for which the title is the null string). This specification requires that at least one stylesheet in each such set must be of MIME media type “text/x-oeb1-css”.
Reading systems that implement only the OEB CSS subset may ignore any stylesheets using other style languages. Reading systems that support extended stylesheet functionality may choose among any of the other external stylesheets. It is strongly recommended that unique MIME media types be defined for any novel stylesheet languages supported, and that stylesheets in those languages be detected by examining the MIME media type.
The Dublin Core is designed to minimize the burden of cataloging on authors and publishers, while providing enough data to be useful. This specification supports the entire current set of Dublin Core metadata elements, supplemented with a small set of additional attributes addressing areas where more specific information may be useful. For example, the role attribute added to the dc:Contributor element allows for much more detailed specification of contributors to a publication, including their roles expressed via relator codes.
Content providers must include a minimum set of a metadata elements, defined in section 2.2, and should incorporate additional metadata to enable readers to discover publications of interest.
Publications may use the entire Unicode character set, in UTF-8 or UTF-16 encodings, as defined by Internet RFC 2279 (see http://www.ietf.org/rfc/rfc2279.txt). The use of Unicode facilitates internationalization and multilingual documents. However, reading systems are not required to provide glyphs for all Unicode characters.
Reading systems are required to parse all UTF-8 and UTF-16 characters properly (as required by XML). Reading systems may decline to display some characters, but must be capable of signaling in some fashion that undisplayable characters are present. They must not display Unicode characters merely as if they were 8-bit characters. For example, the biohazard symbol (0x2623) need not be supported by including the correct glyph, but must not be parsed or displayed as if its component bytes were the two characters “&#” (0x0026 0x0023).
This specification defines a list of “core” MIME media types that all reading systems must support and publications may include. Publications may include resources of other media types, but for each such resource must include an alternative resource of a core MIME media type (using methods defined in this specification).
The core OEB MIME media types are:
| Media Type | Reference | Description |
|---|---|---|
| image/jpeg | RFC 2046 | Used for raster graphics |
| image/png | RFC 2083 | Used for raster graphics |
| text/x-oeb1-document | this specification | Used for basic or extended OEB documents |
| text/x-oeb1-css | this specification | Used for OEB CSS-subset stylesheets |
This section defines conformance for OEB documents, publications, and reading systems.
This specification defines two named levels of conformance for OEB documents–basic and extended, and one conformance level for OEB publications.
Conformant OEB documents (both basic and extended) and conformant OEB package files must meet these necessary conditions, referred to in this specification as the “common requirements:”
A document is a basic OEB document if and only if:
A document is an extended OEB document if and only if
OEB documents, basic or extended, may or may not be valid (as defined in XML 1.0) with respect to an associated DTD. However, all OEB documents must be well-formed XML 1.0 documents.
A collection of files is a conforming OEB publication if and only if
This specification defines only one level of conformance for a reading system. A reading system is conformant if and only if it processes documents as follows:
A) When presented with a basic OEB document the reading system
B) When presented with an extended OEB document the reading system
C) When presented with an OEB package the reading system
D) When providing navigation via the OEB spine, the reading system
E) When presented with one or more style sheets via the HTML link mechanism or the XML-stylesheet processing instruction, described in http://www.w3.org/TR/xml-stylesheet, the reading system
Note: Reading systems are not required to support XML entity and attribute declarations (beyond parsing past them as XML requires), because such constructs are not permitted in conforming OEB documents.
It is the intent of the contributors to this specification that subsequent generations of this specification continue in the directions established by the 1.0 release. Specifically:
Version 1.0.1 of the OEB Publication Structure is not meant to be a “new” specification. It does not add additional features to the specification, but rather removes some ambiguities and corrects errors. The changes made fall into one of three broad categories: clarifications of ambiguities; correction of typographical errors; and correction of other errors or inconsistencies.
It was a goal of version 1.0.1 that all documents conformant according to version 1.0 would remain conformant under 1.0.1. While several inconsistencies rendered full compatibility with version 1.0 impossible, these incompatibilities are unlikely to have appeared in real-world documents. These include:
OEB was developed in parallel with and in reference to XHTML 1.0, which requires the use of the alt attribute for img and area elements. It was intended that the OEB Publication Structure version 1.0 contain a similar requirement, which is reflected by the requirement of img and area alt in the Publication Structure version 1.0 XML DTD. Version 1.0.1 now reflects this intention in the text. While technically the prose specification of version 1.0 is authoritative over the DTD, the contributors felt that it was best to modify the specification to reflect original intention, because any version 1.0 Basic OEB Documents, if validated against the version 1.0 DTD, would have already contained the alt attribute for these elements.
Certain information in the version 1.0 DTD relating to the XLink specification, which was still under development when the OEB Publication Structure 1.0 was released, was incorrect in light of later XLink modifications. It was thought best that XLink-related information not be included in the current specification, which makes no reference to XLink in its prose. Removing the XLink namespace identification attribute xmlns:xlink from the html element in the XML DTD, however, means that any document that conforms to OEB 1.0 and includes this attribute explicitly will now be non-conforming under version 1.0.1. Since the xmlns:xlink attribute was not mentioned in the version 1.0 prose, and since the version 1.0 DTD provided a fixed default value, it is again unlikely that many documents explicitly include that attribute.
Use of extended OEB documents is the recommended mechanism for adding information and structure beyond that provided by the HTML subset defined in this specification, for example, to associate further semantics with content. Arbitrary non-OEB elements may be added as long as such elements are provided with style definitions in accompanying stylesheets.
For example, the following document would be an extended OEB document excerpt:
<chapter> <milestone n="257" /> <chapterhead>Chapter one</chapterhead> <p>Now is the time… </p> </chapter>
if associated with a style sheet that contains the following excerpt:
chapter {page-break-before: always}
milestone { }
chapterhead {
font-weight: bold;
font-family: sans-serif;
text-align: center;
display: block;
margin-top: 4ex
}
This specification incorporates features that ensure content can be made accessible and usable by persons with disabilities. Existing accessibility features developed by the World Wide Web Consortium (W3C) for HTML 4.0 for content accessibility are incorporated into the OEB specification.
OEB publications should be authored in accordance with the W3C Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/) to ensure that the broadest possible set of users will have access to books delivered in this format.
In addition, recommendations from the W3C HTML 4.0 Guidelines for Mobile Access (http://www.w3.org/TR/NOTE-html40-mobile/) and the W3C Web Accessibility Initiative's proposed User Agent Guidelines (http://www.w3.org/TR/WD-WAI-USERAGENT/) should be reviewed and applied by OEB implementers to ensure that reading systems will be in conformance with accessibility requirements.
This specification is designed to take advantage of current practices while preparing for future developments. Although the nature of subsequent versions of this specification remain to be determined, it is the expectation of the contributors to this specification that these releases will continue in the same directions, including: increasing functionality, accessibility, internationalization, extensibility, and more rigorous separation of content and presentation, while maintaining alignment with relevant standards. Further, maintaining backward compatibility with this version of this specification is a high priority. Future directions can be tracked at http://www.openebook.org.
A publication conforming to this specification must include exactly one OEB package file, which specifies the OEB documents, images, and other objects that make up the OEB publication and how they relate to each other.
It is recommended that all package files use extension “.opf”, in order to make them readily identifiable within the group of files making up a publication. Package files are of MIME media type “text/xml”. This specification does not define means for physically bundling files together to make one data transfer object (such as using zip or tar).
It is not required that the OEB package DTD be physically included in every publication. If included, it should be referenced from the manifest (as described below for other files).
The major parts of the OEB package file are:
An OEB package must be a valid XML document conforming to the OEB package DTD. An informal outline of the package is as follows:
<?xml version="1.0"?> <!DOCTYPE package PUBLIC "+//ISBN 0-9673008-1-9//DTD OEB 1.0.1 Package//EN" "http://openebook.org/dtds/oeb-1.0.1/oebpkg101.dtd"> <package>
metadata
manifest
spine
guide
</package>
The following sections describe the parts of the OEB package.
The package element is the outermost element in a package file; all other elements are nested within it.
The package must specify a value for its unique-identifier attribute. The unique-identifier attribute’s value specifies which dc:Identifier element, described in section 2.2.10, provides the package’s preferred, or primary, identifier. The package file’s author is responsible for choosing a primary identifier that is unique to one and only one particular package (i.e., the set of files referenced from the package file’s manifest).
Notwithstanding the requirement for uniqueness, reading systems must not fail catastrophically should they encounter two distinct packages with the same purportedly unique primary identifier.
The required metadata element is used to provide information about the publication as a whole. It contains a Dublin Core metadata record within a dc-metadata element, and supplemental metadata in an x-metadata element.
The dc-metadata element contains specific publication-level metadata as defined by the Dublin Core initiative (http://purl.org/dc/). The descriptions below are included for convenience, and the Dublin Core's own definitions take precedence (see http://www.ietf.org/rfc/rfc2413.txt).
The x-metadata element must contain one or more instances of a meta element, analogous to the HTML 4.0 meta element, but applicable to the publication as a whole. The x-metadata element allows content providers to express arbitrary metadata beyond the data described by the Dublin Core language. Individual OEB documents may include the meta element directly (as in HTML 4.0) for document-specific metadata. This specification uses the OEB package file alone as the basis for expressing publication-level Dublin Core metadata.
For example:
<metadata>
<dc-metadata>
…
</dc-metadata>
<x-metadata>
<meta name="price" content="USD 19.99"/>
</x-metadata>
</metadata>
The XML namespace mechanism (see http://www.w3.org/TR/REC-xml-names/) is used to identify the elements used for Dublin Core metadata without conflict. Note that there is no requirement on reading systems to process namespaces. This syntax is used to provide for upwards-compatibility.
The dc-metadata element can contain any number of instances of any Dublin Core elements. Dublin Core element names begin with the “dc:” prefix followed by a leading uppercase letter. Dublin Core metadata elements may occur in any order; in fact, multiple instances of the same element type (multiple dc:Creator elements, for example) can be interspersed with other metadata elements without change of meaning.
For upwards-compatibility, the element dc-metadata in an OEB package is required to have an attribute of xmlns:dc="http://purl.org/dc/elements/1.0/" and xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.0/".
Each Dublin Core field is represented by an element whose content is the field's value. The dc:Title and at least one dc:Identifier must be included in the dc-metadata element. Dublin Core elements, like any other elements in the OEB package file, may have an id attribute specified. At least one dc:Identifier, that which is referenced from the package unique-identifier attribute, must have an id specified.
Because the Dublin Core metadata fields for Creator and Contributor do not distinguish roles of specific contributors (such as author, editor, and illustrator), this specification adds an optional role attribute for this purpose. See section 2.2.6 for a discussion of role.
This specification also adds a scheme attribute to the dc:Identifier element to provide a structural mechanism to separate an identifier value from the system or authority that generated or defined that identifier-value. See section 2.2.10 for a discussion of scheme.
This specification also adds a event attribute to the dc:Date element to enable content providers to distinguish various publication specific dates (for example, creation, publication, modification). See section 2.2.7 for a discussion of event.
For example:
<package unique-identifier="xyz"> <metadata> <dc-metadata xmlns:dc="http://purl.org/dc/elements/1.0/" xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.0/"> <dc:Title>Alice in Wonderland</dc:Title> <dc:Type>Novel</dc:Type> <dc:Identifier id="xyz" scheme="ISBN">123456789X</dc:Identifier> <dc:Creator role="aut">Lewis Carroll</dc:Creator> </dc-metadata> </metadata> … </package>
Attributes of elements within the dc-metadata element are not defined by the Dublin Core—only the elements’ contents are so defined.
The following subsections describe the individual Dublin Core metadata elements.
The title of the publication. Although an OEB package must include at least one instance of this element type, multiple instances are permitted. Any reading system that displays title metadata to the user should either use the first dc:Title only, or all dc:Title elements.
A primary creator or author of the publication. Additional contributors whose contributions are secondary to those listed in dc:Creator elements should be named in dc:Contributor elements.
Publications with multiple co-authors should provide multiple dc:Creator elements, each containing one author. The order of dc:Creator elements is presumed to define the order in which the creators’ names should be presented by the reading system.
This specification recommends that the content of the dc:Creator elements hold the text for a single name as it would be presented to the user.
The dc:Creator element has two optional attributes, role and file-as. The set of values for role are identical to those defined in section 2.2.6 for the dc:Contributor element. The file-as attribute should be used to specify a normalized form of the contents, suitable for machine processing. For example, one might find
<dc:Creator file-as="King, Martin Luther Jr." role="aut"> Rev. Dr. Martin Luther King Jr. </dc:Creator>
If a reading system displays creator information, the reading systems must display the contents of all dc:Creator elements, in the order provided, with appropriate separating spacing and/or punctuation.
Multiple instances of the dc:Subject element are supported, each including an arbitrary phrase or keyword. This specification makes no attempt to standardize subject naming schemes, such as the Library of Congress Subject Heading System.
Plain text describing the publication’s content.
The publisher as defined in RFC2413.
A party whose contribution to the publication is secondary to those named in dc:Creator elements.
Other than significance of contribution, the semantic of this element are identical to those of dc:Creator. Reading systems are free to choose to display dc:Creator information without accompanying dc:Contributor information.
The dc:Contributor element has two optional attributes, role and file-as. The file-as attribute is defined as for dc:Creator, and is documented in section 2.2.2.
The normative list of values used for the role attribute is defined by the USMARC relator code list (http://www.loc.gov/marc/relators/re0002r1.html). When roles are specified, the 3-character USMARC values must be used when applicable. Although that list is extensive, other values may be added if a required role is not covered by those predefined values. Such values must begin with “oth.”, and shall be considered subdivisions of the “other” relator code. Like other constructs in this specification, these values are case-sensitive and must be coded entirely in lower-case.
For convenience, some relator code values are listed here as examples. Consult the USMARC code list cited above for the complete list.
| Adapter [adp] | Use for a person who 1) reworks a musical composition, usually for a different medium, or 2) rewrites novels or stories for motion pictures or other audiovisual medium. |
| Annotator [ann] | Use for a person who writes manuscript annotations on a printed item. |
| Arranger [arr] | Use for a person who transcribes a musical composition, usually for a different medium from that of the original; in an arrangement the musical substance remains essentially unchanged. |
| Artist [art] | Use for a person (e.g., a painter) who conceives, and perhaps also implements, an original graphic design or work of art, if specific codes (e.g., [egr], [etr]) are not desired. For book illustrators, prefer Illustrator [ill]. |
| Associated name [asn] | Use as a general relator for a name associated with or found in an item or collection, or which cannot be determined to be that of a Former owner [fmo] or other designated relator indicative of provenance. |
| Author [aut] | Use for a person or corporate body chiefly responsible for the intellectual or artistic content of a work. This term may also be used when more than one person or body bears such responsibility. |
| Author in quotations or text extracts [aqt] | Use for a person whose work is largely quoted or extracted in a works to which he or she did not contribute directly. Such quotations are found particularly in exhibition catalogs, collections of photographs, etc. |
| Author of afterword, colophon, etc. [aft] | Use for a person or corporate body responsible for an afterword, postface, colophon, etc. but who is not the chief author of a work. |
| Author of introduction, etc. [aui] | Use for a person or corporate body responsible for an introduction, preface, foreword, or other critical matter, but who is not the chief author. |
| Bibliographic antecedent [ant] | Use for the author responsible for a work upon which the work represented by the catalog record is based. This may be appropriate for adaptations, sequels, continuations, indexes, etc. |
| Book producer [bkp] | Use for the person or firm responsible for the production of books and other print media, if specific codes (e.g., [bkd], [egr], [tyd], [prt]) are not desired. |
| Collaborator [clb] | Use for a person or corporate body that takes a limited part in the elaboration of a work of another author or that brings complements (e.g., appendices, notes) to the work of another author. |
| Commentator [cmm] | Use for a person who provides interpretation, analysis, or a discussion of the subject matter on a recording, motion picture, or other audiovisual medium. |
| Compiler [com] | Use for a person who produces a work or publication by selecting and putting together material from the works of various persons or bodies. |
| Designer [dsr] | Use for a person or organization responsible for design if specific codes (e.g., [bkd], [tyd]) are not desired. |
| Editor [edt] | Use for a person who prepares for publication a work not primarily his/her own, such as by elucidating text, adding introductory or other critical matter, or technically directing an editorial staff. |
| Illustrator [ill] | Use for the person who conceives, and perhaps also implements, a design or illustration, usually to accompany a written text. |
| Lyricist [lyr] | Use for the writer of the text of a song. |
| Metadata contact [mdc] | Use for the person or organization primarily responsible for compiling and maintaining the original description of a metadata set (e.g., geospatial metadata set). |
| Musician [mus] | Use for the person who performs music or contributes to the musical content of a work when it is not possible or desirable to identify the function more precisely. |
| Narrator [nrt] | Use for the speaker who relates the particulars of an act, occurrence, or course of events. |
| Other [oth] | Use for relator codes from other lists which have no equivalent in the USMARC list or for terms which have not been assigned a code. |
| Photographer [pht] | Use for the person or organization responsible for taking photographs, whether they are used in their original form or as reproductions. |
| Printer [prt] | Use for the person or organization who prints texts, whether from type or plates. |
| Redactor [red] | Use for a person who writes or develops the framework for an item without being intellectually responsible for its content. |
| Reviewer [rev] | Use for a person or corporate body responsible for the review of book, motion picture, performance, etc. |
| Sponsor [spn] | Use for the person or agency that issued a contract, or under whose auspices a work has been written, printed, published, etc. |
| Thesis advisor [ths] | Use for the person under whose supervision a degree candidate develops and presents a thesis, memoir, or text of a dissertation. |
| Transcriber [trc] | Use for a person who prepares a handwritten or typewritten copy from original material, including from dictated or orally recorded material. |
| Translator [trl] | Use for a person who renders a text from one language into another, or from an older form of a language into the modern form. |
Date of publication, in the format defined by “Date and Time Formats” at http://www.w3.org/TR/NOTE-datetime and by ISO 8601 on which it is based. In particular, dates without times are represented in the form YYYY[-MM[-DD]]: a mandatory 4-digit year, an optional 2-digit month, and if the month is given, an optional 2-digit day of month.
The dc:Date element has one optional attribute, event. The set of values for event are not defined by this specification; possible values may include: creation, publication, and modification.
Dublin Core provides examples of resource types “such as home page, novel, poem, working paper, technical report, essay, dictionary.” The Dublin Core is currently considering revisions to the usage of this field, and should be consulted for updated definitions.
An enumerated list of formats for this content is being developed by the Dublin Core.
A string or number used to uniquely identify the resource.
At least one dc:Identifier must have an id specified, so it can be referenced from the package unique-identifier attribute of Section 2.1.
The dc:Identifier element has an optional attribute, scheme. The scheme attribute names the system or authority that generated or assigned the text contained within the dc:Identifier element, for example “ISBN” or “DOI.” The values of the scheme attribute are case sensitive.
This specification does not standardize or endorse any particular publication identifier scheme. Specific use of URLs or ISBNs is not yet addressed by this specification. Identifier schemes are not currently defined by Dublin Core.
Information regarding a prior resource from which the publication was derived (see RFC 2413).
If specified, identifies the primary language of the content. The content of this element must comply with RFC 1766 (see http://www.ietf.org/rfc/rfc1766.txt), or its successor on the IETF Standards Track. US English (en-us) is the default. The Dublin Core permits other descriptions as well; this specification does not.
An identifier of an auxiliary resource and its relationship to the publication. An enumerated list of relationship types is currently under development by the Dublin Core.
The place or time which the publication’s content addresses.
A statement about rights, or a link to one. In this specification, the copyright notice and any further rights description should appear directly.
This specification does not address the manner in which a Content Provider specifies to a secure distributor any licensing terms under which readership rights or copies of the content may be sold.
The manifest provides a list of all the files that are parts of the publication. The manifest element must contain one or more item elements. Each item describes a document, an image file, a stylesheet, or other component that is considered part of the publication.
Each item element contained within a manifest element must have an id attribute. In addition, each item element in the manifest must have an href attribute, which is a URI (if relative, the URI is interpreted as relative to the package file itself). Additionally, each item element must have its MIME media type specified via the media-type attribute.
The order of item elements in the manifest is not significant.
For example,
<manifest> <item id="intro" href="introduction.html" media-type="text/x-oeb1-document" /> <item id="c1" href="chapter-1.html" media-type="text/x-oeb1-document" /> <item id="c2" href="chapter-2.html" media-type="text/x-oeb1-document" /> <item id="toc" href="contents.xml" media-type="text/x-oeb1-document" /> <item id="oview" href="arch.png" media-type="image/png" /> </manifest>
The URIs in href attributes of item elements in the manifest may not use fragment identifiers.
This specification defines a set of core MIME media types that all conforming reading systems must support. For a publication that uses only those media types, the manifest merely needs to list the publication's component files directly. However, content providers may construct publications that reference items of additional media types. In order that such publications can nevertheless be read by all conforming reading systems, content providers must always provide alternative “fallback” items for each such item. For every item that is not in a core media type, at least one of its associated fallback items must be of a type drawn from the set of core media types.
This specification defines two different mechanisms for specifying core media type fallbacks. For inline “replaced” elements, this specification relies on the HTML-based object element, described in section 3. For non-inline destinations, whether referenced from a document or a package, the fallback attribute of an item is used.
An item identifies a fallback item using its fallback attribute, which must specify the ID of the item element that identifies the fallback. Items referenced from fallback attributes may each specify a fallback attribute in turn, forming a longer “fallback path.” For example,
<manifest> <item id="item1" href="FunDoc.txt" media-type="text/plain" fallback="fall1" /> <item id="fall1" fallback="fall2" href="FunDoc.html" media-type="text/html" /> <item id="fall2" href="FunDoc.oeb" media-type="text/x-oeb1-document" /> <item …> </manifest>
If a fallback attribute points to an item that also has a fallback attribute, a reading system must continue down the fallback path until it reaches a reference to an item of a media type it can display. A reading system may continue further, and may display any item from the chain. Every item in a publication that is not of one of the core MIME media types must, directly or indirectly, specify a fallback path to an item of one of the core MIME media types.
Fallback paths must terminate; circular references are not permitted. Nevertheless, reading systems should not fail catastrophically if they encounter such a cycle.
Following the manifest, there must be one spine element, which defines a primary linear reading order of the publication. It specifies an ordered list of one or more OEB documents drawn from the manifest, using itemref elements contained within the spine element.
A publication must specify exactly one spine. Reading systems must treat the file named in the first itemref element within the spine as the first file to be rendered in the reading of the book. The successive files named in its itemref elements are those that are to be rendered using “next-page”-type functionality that may be available in the reading system.
The spine may refer only to item elements of media type text/x-oeb1-document. Content of other media types may be referenced via OEB documents, which can (and should) provide text alternates and other information to enhance accessibility as appropriate.
The spine need not include references to every one of the manifest’s item elements that reference OEB documents, because there are means other than the spine for accessing documents in the publication. For example, hypertext links may provide access to documents not in the spine, as may tours and guides (see below).
For example,
<manifest> <item id="toc" href="contents.html" media-type="text/x-oeb1-document" /> <item id="c1” href="chap1.html" media-type="text/x-oeb1-document" /> <item id="c2” href="chap2.html" media-type="text/x-oeb1-document" /> <item id="c3” href="chap3.html" media-type="text/x-oeb1-document" /> <item id="footnotes" href="footnotes.html" media-type="text/x-oeb1-document" /> <item id="f1" href="fig1.jpg" media-type="image/jpeg" /> <item id="f2" href="fig2.jpg" media-type="image/jpeg" /> <item id="f3" href="fig3.jpg" media-type="image/jpeg" /> </manifest> <spine> <itemref idref="toc" /> <itemref idref="c1" /> <itemref idref="c2" /> <itemref idref="c3" /> </spine>
In the above example, suppose the document referenced by ID “c1” is being viewed by a reader. When the end of that document is reached, the next document in linear order would be that referenced by ID “c2”. Document “c1” might also have hypertext links to locations in another file such as the “footnotes”. Such a file must be listed in the manifest, but need not be named by any itemref of the spine. If a reader follows the hyperlink in “c1” to “footnotes”, and the end of that file is reached, then no successor in linear order is defined by this specification.
Much as a tour-guide might assemble points of interest into a set of sightseers’ tours, a content provider may assemble selected parts of a publication into a set of tours to enable convenient navigation.
An OEB package may, but need not, contain one tours element, which in turn contains one or more tour elements. Each tour must have a title attribute, intended for presentation to the user. Reading systems may use tours to provide various access sequences to parts of the publication, such as selective views for various reading purposes, reader expertise levels, etc. Because reading systems are not required to implement tour support, content providers should also provide other means of accessing content referenced from tours.
Each tour element contains one or more site elements, each of which must have an href attribute and a title attribute. The href attribute must refer to an OEB document included in the manifest, and may include a fragment identifier as defined in section 4.1 of RFC 2396 (see http://www.ietf.org/rfc/rfc2396.txt). Each site element specifies a starting point from which the reader may explore freely. Reading systems may use the bounds of the referenced element to determine the scope of the site. If a fragment identifier is not used, the scope is considered to be the entire document. This specification does not require Reading Systems to mark or otherwise identify the entire scope of a referenced element. The order of site elements is presumed to be significant, and should be used by reading systems to aid navigation.
Example:
<tours>
<tour id="tour1" title="Chicken Recipes">
<site title="Chicken Fingers"
href="appetizers.html#r3" />
<site title="Chicken a la King"
href="entrees.html#r5" />
</tour>
<tour id="tour2" title="Vegan Recipes">
<site title="Hummus" href ="appetizer.html#r6" />
<site title="Lentil Casserole" href="lentils.html" />
</tour>
</tours>
Within the package there may be one guide element, containing one or more reference elements. The guide element identifies fundamental structural components of the publication, to enable reading systems to provide convenient access to them.
Example:
<guide>
<reference type="toc" title="Table of Contents"
href="toc.html" />
<reference type="loi" title="List Of Illustrations"
href="toc.html#figures" />
<reference type="other.intro" title="Introduction"
href="intro.html" />
</guide>
The structural components of the books are listed in reference elements contained within the guide element. These components may refer to the table of contents, list of illustrations, foreword, bibliography, and many other standard parts of the book. Reading systems are not required to use the guide element in any way.
Each reference must have an href attribute referring to an OEB document included in the manifest, and which may include a fragment identifier as defined in section 4.1 of RFC 2396 (see http://www.ietf.org/rfc/rfc2396.txt). Reading systems may use the bounds of the referenced element to determine the scope of the reference. If a fragment identifier is not used, the scope is considered to be the entire document. This specification does not require Reading Systems to mark or otherwise identify the entire scope of a referenced element.
The required type attribute describes the publication component referenced by the href attribute. The values for the type attributes must be selected from the list defined below when applicable. Other types may be used when none of the predefined types are applicable; their names must begin with the string “other.”. The value for the type attribute is case-sensitive.
The following list of type values is derived from the 13th edition of the Chicago Manual of Style:
| cover | the book cover(s), jacket information, etc. |
| title-page | page with possibly title, author, publisher, and other metadata |
| toc | table of contents |
| index | back-of-book style index |
| glossary | glossary |
| acknowledgements | |
| bibliography | |
| colophon | |
| copyright-page | |
| dedication | |
| epigraph | |
| foreword | |
| loi | list of illustrations |
| lot | list of tables |
| notes | |
| preface |
This section lists all element types included in the OEB document specification. They are drawn from the HTML 4.0 specification found at http://www.w3.org/TR/REC-html40. See also Appendix A, which includes an index of element types and their status in HTML 4.0 and this specification.
This section does not list HTML 4.0 element types that are not supported in OEB documents (the table in Appendix A, however, does show them explicitly and marks them as excluded). For elements that are supported, this section does, however, explicitly indicate attributes that are ruled out. Reading systems may accept the presence of additional attributes (except in valid OEB documents), but need not support their semantics.
The following typographic conventions are used to indicate the status of element types, attributes, and attribute values:
Attributes and attribute values whose names are struckthrough below are HTML 4.0 constructs that are explicitly not supported by this specification. Reading systems may, but need not provide default presentation for them. In some cases, the constructs are intended to be permanently obsolete; in other cases, future revisions of this specification may add support for these constructs.
Elements, attributes, and attribute values whose names are followed by “(meaning changed)” below have had their semantics altered from those of the HTML 4.0 specification.
Elements, attributes, and attribute values whose names are followed by “(deprecated)” below are deprecated (that is, permitted but not recommended) in OEB documents. The accompanying text indicates whether they are also deprecated in HTML 4.0. Although reading systems must recognize and support them, future releases of this specification are likely to prohibit them. Most but not all are deprecated in HTML 4.0. All elements, attributes, and attribute values that are deprecated in HTML 4.0 are either deprecated or prohibited by this specification.
Elements that cannot contain subelements or text content are shown with the required empty-element syntax, while others are shown as start- and end-tag pairs. Note the XML documents may not omit start- or end-tags. The supported HTML elements for which this restriction is relevant include: html, body, head, dt, li, p, caption, td, and th.
HTML 4.0 defines the following four attributes that may be applied to nearly all elements. These attributes are therefore not listed in the following element descriptions, except to note their absence from the few exceptional elements.
Similarly, XML 1.0 defines the attribute xml:lang, which may be applied to any element in a Basic OEB Document or an Extended OEB Document, and is therefore not listed in the following element descriptions.
This attribute is used to give a unique identifier to each element. Values for id must be unique across all elements in a single document, must begin with a letter, and may consist of the full range of XML name characters. For compatibility with HTML, restricting the id values to the HTML name characters (A-Za-z0-9.-_) is recommended.
This attribute applies to all elements in both Basic and Extended OEB Documents.
This attribute is included to allow for inline style specification. See the discussion of supported CSS properties elsewhere in this specification.
This attribute applies to all elements in both Basic and Extended OEB Documents.
This attribute is included to allow selector-based style specifications. Its value must be a space-separated list of class names. OEB class names are limited to valid HTML 4.0 names, although HTML 4.0 allows arbitrary CDATA.
This attribute applies to all elements in both Basic and Extended OEB Documents.
This attribute may be used to provide an “advisory title/amplification” for the element. Reading systems are not required to do anything in particular with its value.
This attribute may be inserted in documents to specify the language used in the contents and attribute values of any element in an XML document. The value of the xml:lang attribute must comply with RFC 1766 (see http://www.ietf.org/rfc/rfc1766.txt), or its successor on the IETF Standards Track.
A number of elements and attributes that are allowed below permit semantics that are not required of all OEB reading systems. For example, some devices may be monochrome, or provide mainly audio or tactile interfaces. In such cases this specification generally requires reading systems to accept all syntax (such as attribute values) permitted for the HTML construct, but does not require that they be honored. For example, a reading system must parse and recognize the border attribute on table elements, but may choose to treat all values other than 0 the same as 1.
Note that this specification does not mandate specific rendering behavior for HTML constructs. Some reading systems may choose to express the intent of elements in presentation by closely following web-browser usages—a blank line before a paragraph, but no first-line text-indent, for example. Other reading systems may gear their presentation towards sustained novel-like readability: for example, no extra whitespace between paragraphs, but text-indent on the first line of each. Still other systems, such as speech generators, may present particular elements or entire documents in completely different ways.
An OEB document must begin with the XML processing instruction
<?xml version="1.0" ?>
It is recommended that a character encoding be specified, for example:
<?xml version="1.0" encoding="UTF-16" ?>
A <!DOCTYPE> declaration in a basic OEB document must reference the OEB document DTD, by system and optionally the public identifier. For example:
<!DOCTYPE html PUBLIC "+//ISBN 0-9673008-1-9//DTD OEB 1.0.1 Document//EN" "http://openebook.org/dtds/oeb-1.0.1/oebdoc101.dtd">
Note that the <!DOCTYPE> declaration must not include a trailing slash, but may include “[ ]” preceding the closing “>”. “DOCTYPE” must be in upper case. Also, implementations should normalize whitespace in PUBLIC identifiers in accordance with the rules defined in XML, though the use of non-normalized whitespace in PUBLIC identifiers in OEB documents is prohibited.
Marks either the origin or destination for a hypertext link. Note that many browsers by default underline anchors with href attributes, to visually indicate links. Similarly, reading systems will use some sort of highlighting, perhaps some form of underline, to show links. The CSS-property setting text-decoration: none may be used to suppress such highlighting.
Used to provide an address to which hypertext links may refer.
Deprecated in XHTML 1.0 and in this specification, in favor of the id attribute. HTML 4.0 allows any string as the value of this attribute; this specification limits them to being XML names.
Provides a URI to be used as the destination when traversal from the a element is requested. If this URI references a destination that is not an OEB core media type, a fallback must be provided in the manifest to an OEB core media type. If a fallback is not provided in the manifest, content at the end of this link must not be rendered by the reading system.
May be used to indicate the relationship between the document or portion linked, and the current document or portion.
Omitted from this specification.
The possible values are:
| rect | The default. Coordinates are left, top, right, bottom values. |
| circle | Coordinates are center x, center y, and radius. |
| poly | Coordinates are x, y pairs for successive points. |
| default | The default type, rect, can also be set explicitly. |
Comma-separated list of lengths, as integer coordinates or percentages. The values are interpreted according to the specific shape value.
Provides a URI to be used as the destination when traversal from this area is requested (for example by clicking within a hotspot). If this URI references a destination that is not an OEB core media type, a fallback must be provided in the manifest to an OEB core media type. If a fallback is not provided in the manifest, the destination resource must not be rendered by the reading system.
If set to nohref="nohref", indicates that the area isn’t “hot,” effectively “punching a hole” in a larger hot region.
This required attribute must be used to provide an alternative textual representation for the hot-spot, accessible to print-disabled users.
Omitted from this specification.
The b tag is commonly used in HTML documents. Use of CSS font-weight:bold or the HTML strong tag is preferable.
Used in resolving links from OEB documents.
Provides a URI to be used as the basis for relative URIs elsewhere in the document.
HTML 4.0 and this specification exclude these general attributes from this element.
The big tag is sometimes used in HTML documents. Use of CSS font-size is preferable.
This optional attribute provides a URI for the source of the quoted material.
This element defines a container for OEB content. It is assumed, in formatting, that its default rendering is consistent with the CSS property page-break-before having been set to right (which behaves like always on one-page reading systems), but may be overridden by an appropriate stylesheet declaration.
Deprecated in HTML 4.0 and in this specification, in favor of CSS background-color equivalent. See section 4.1, the CSS color and background-color properties, for discussion of acceptable values.
Deprecated in HTML 4.0 and in this specification, in favor of CSS color equivalent. See section 4.1, the CSS color and background-color properties, for discussion of acceptable values.
This specification does not require reading systems to support color control of link anchors or background bitmaps. These attributes are deprecated in HTML 4.0 and omitted from this specification.
Omitted from this specification.
The possible values are:
| none (default) |
| left |
| right |
| all |
Deprecated in HTML 4.0, in favor of CSS clear property.
When present, the caption element's text should describe the nature of the table.
Deprecated in HTML 4.0 and omitted from this specification, in favor of CSS text-align property..
Equivalent to <div align="center">. Deprecated in HTML 4.0 and in this specification. See section 3.25.1 for additional discussion.
Citations of other sources.
Computer program fragments.
Definition description.
Inline definitions, such as the first instance of a definition.
See section 3.25.1 for additional discussion.
Definition list.
See section 3.58.2, ul, for additional discussion.
Definition term.
Emphasis, typically formatted like i.
The font element is deprecated in HTML 4.0 and this specification, with its functionality replaced by CSS equivalents.
Deprecated in HTML 4.0 and in this specification, in favor of CSS font-size property.
See section 3.12.1, the bgcolor and text attributes of the body element, for additional discussion.
Deprecated in HTML 4.0 and in this specification, in favor of CSS font-family property.
The possible values are:
| left |
| center |
| right |
| justify |
Deprecated in favor of the equivalent CSS construct, text-align.
Omitted from this specification.
HTML 4.0 excludes these general attributes from this element.
The possible values are:
| left |
| right |
| center |
Deprecated in favor of the equivalent CSS construct, text-align.
Deprecated in HTML 4.0, omitted from this specification.
Deprecated in HTML 4.0 and this specification, in favor of CSS height.
Deprecated in HTML 4.0 and this specification, in favor of CSS width. Value is specified in pixels or percentage.
This element is required in Basic OEB documents.
HTML 4.0 and this specification exclude these general attributes from this element.
The i tag is commonly used in HTML documents. Use of CSS font-style:italic or the HTML em tag is preferable.
A reference to an image to be displayed inline. This element may only be used to refer to images of OEB core media types (PNG and JFIF [JPEG]). Inline references to non-core media types require specification of alternate (fallback) rendering. The object element provides a general fallback mechanism by which all reading systems may locate an alternate of a core media type, and is the preferred mechanism for including non-core media types. However, a non-null value for the alt attribute, which must always be present, is also considered an adequate fallback.
Images must be of type PNG (see http://www.ietf.org/rfc/rfc2083.txt) or JFIF (see ISO/IEC 10918-1:1994(E) and http://www.w3.org/Graphics/JPEG).
This required attribute must be used to provide a non-graphical alternative to a graphic. This is crucial to accessibility of documents to print-disabled users, as well as for use on very low-resolution display devices. See http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-provide-equivalents for further information on the use of this and related accessibility attributes.
Value should be a URI pointing to a long description, typically more detailed than, but complementary to, alt. Use of this attribute is strongly recommended because it can greatly enhance accessibility for print-disabled users.
Deprecated in HTML 4.0 and this specification, in favor of CSS float and vertical-align properties.
The possible values are:
| top |
| middle |
| bottom |
| left |
| right |
Deprecated in this specification, though not in HTML 4.0, in favor of CSS width property.
Deprecated in this specification, though not in HTML 4.0, in favor of CSS height property.
Deprecated in HTML 4.0 and this specification, in favor of CSS border property.
Pixel width for image border. The value 0 is particularly useful for img elements embedded in a elements, because typical HTML browsers apply a default border when rendering image-based hypertext links. This specification requires only that values of 0 and 1 be respected. Values greater than 1 may be mapped by the reading device to any smaller non-zero value.
Deprecated in HTML 4.0 and this specification, in favor of CSS margin mechanisms.
Reserves equal amount of whitespace to the left and right of an image.
Deprecated in HTML 4.0 and this specification, in favor of CSS margin mechanisms.
Reserves equal amount of whitespace above and below an image.
Points to a client-side map; the value of usemap refers to the map element’s name or id attribute (see map 3.34).
Omitted from this specification. In HTML 4.0, value is a reference to a server-side map for defining hotspots.
The indication of text to be entered by a user, often used in software manuals.
| 1, a, A, i, I | Specifies a form of letters or numerals to use for the list items. |
Deprecated in HTML 4.0 and this specification, in favor of CSS list-style-type.
Deprecated in HTML 4.0 and omitted from this specification.
In HTML the link element allows for specification of various relationships with other documents. Reading systems must recognize external stylesheet references specified via the link element. See section 1.4.4.
Provides the URI of a linked object.
Indicates the relationship to the linked document. Reading systems must support rel="stylesheet" and rel="alternate stylesheet". See the HTML 4.0 specification.
May be used to indicate the intended destination for style information, but may be ignored by reading systems.
This required attribute is used to specify the stylesheet language (e.g. “text/x-oeb1-css” or “text/css”).
Omitted from this specification.
Contains area elements defining client-side hotspots for an image.
A required unique identifier for the map. See section 3.6, the a element, for restrictions on the characters permitted in names.
A unique identifier for the map. Deprecated in HTML 4.0 and in this specification, in favor of the id attribute; the name attribute is now optional. See section 3.6, the a element, for restrictions on the characters permitted in names.
See the HTML 4.0 specification for further information.
For information regarding publication description (Dublin Core) metadata, see Chapter 2 of this specification.
Omitted from this specification.
HTML 4.0 and this specification exclude these general attributes from this element.
The object element is the preferred method for generic object inclusion. When adding objects whose data media type is not drawn from the core OEB media type list or which reference an object implementation using the classid attribute, the object element must specify fallback information for the object, such as another object, an img element, or descriptive text. Inline fallback information is provided as OEB content appearing immediately after the final param element that refers to the parent object. Descriptive text for the object, using inline content, an included OEB file or some other method should be provided to allow access for people who are not able to access non-textual content.
Example:
<object classid="java:tictactoe" codetype="application/java"> <param name="height" value="60"> <param name="width" value="60"> <object type="image/png" data="tictactoe.png"> <param name="height" value="60"> <param name="width" value="60"> Tic-Tac-Toe, a <em> dull </em> game. </object> </object>
See the HTML 4.0 specification for details.
The URI of an implementation for the object. Conformant reading systems are not required to render objects that use external implementations, although they may do so.
The base path to be used for relative URIs in the classid attribute.
Specifies the MIME media type of the implementation referenced in classid.
Note: the type must match the MIME media type specified in the publication's manifest.
The URI of the data for this object.
The MIME media type of the information referenced by the data URI.
Note: the type must match the MIME media type specified in the publication's manifest.
Deprecated in HTML 4.0 (except height and width), and this specification. See section 3.30, img, for additional discussion.
Refers to a client-side map element by its name attribute's value, in order to define hotspots.
Omitted from this specification.
| 1, a, A, i, I | Specifies a form of letters or numerals to use for the list items. |
Deprecated in HTML 4.0 and this specification, in favor of CSS list-style-type.
Deprecated in HTML 4.0 and omitted from this specification. There is no OEB-CSS equivalent.
Omitted from this specification.
See section 3.25, h1, for additional discussion.
The param element is used to specify initialization values for objects. The param element may only appear before the renderable content of an object. Reading systems may examine only param elements that are direct children of the object.
The name of a parameter used by the parent object.
The value of the parameter.
The type of data stored in value:
| data | The default. The data stored in value is passed to the object as a string. |
| ref | The data is a URI, and is passed to the object as specified, without being resolved. |
| object | An identifier that refers to an object declaration in the same document. The identifier must be the value of the id attribute set for the declared object’s element. |
Used when the valuetype is “ref”. Specifies the MIME media type of the data a reading system should expect at the given URI.
HTML 4.0 and this specification exclude these general attributes from this element.
Preformatted text to be rendered in a monospace font, such as program listings.
Deprecated in HTML 4.0 and omitted from this specification, in favor of CSS width property..
Short inline quotation (see also section 3.11, blockquote).
Provides a URI for the source of the quoted material. Reading systems are not required to make use of this attribute.
Deprecated in HTML 4.0 and this specification, in favor of the CSS text-decoration:line-through property.
Identifies the contents as program output, scripts, etc.
Reading systems must not render the textual content of the script element, but may choose to execute the script itself. To render the textual content of the script element, this specification recommends using the CSS 1 display property to achieve this effect instead.
Omitted from this specification.
HTML 4.0 and this specification exclude these general attributes from this element.
The small tag is sometimes used in HTML documents. Use of CSS font-size is preferable.
Particularly useful for associating CSS style information with inline content.
Deprecated in HTML 4.0 and this specification, in favor of the CSS text-decoration:line-through property.
Strong emphasis, typically formatted like b.
See section 1.4.4.
The value must be:
| text/x-oeb1-css |
OEB documents’ embedded style information must always use only the CSS subset defined in this specification.
Omitted from this specification.
HTML 4.0 and this specification exclude these general attributes from this element.
Reading systems may exercise great flexibility in laying out tables which would otherwise be too large to fit on the display.
The possible values are:
| left | CSS equivalent is float:left |
| right | CSS equivalent is float:right |
| center | CSS equivalent is to enclose the table in a div element and set text-align:center |
According to HTML 4.0, any number of pixels may be specified. This specification only requires that values of 0 and 1 be respected. Values greater than 1 may be mapped by the reading system to any smaller non-zero value.
See section 3.12.1, the bgcolor attribute of body, for additional discussion.
A text summary of the table's purpose and/or structure, such as for speech output. This can be crucial in making documents accessible to print-disabled users.
Omitted from this specification.
Deprecated in HTML 4.0 and this specification. The non-deprecated alternative is to replace each run of whitespace with a single non-breaking space. Reading systems may choose to override this setting in cases where the default rendering of a particular table is bigger than the display surface.
The possible values are:
| left |
| center |
| right |
| justify |
The possible values are:
| top |
| middle |
| bottom |
Deprecated in HTML 4.0 and this specification. Instead, use the CSS width and height to set value in pixels.
See section 3.12.1, the bgcolor attribute of body, for additional discussion.
An abbreviated form of the content, particularly to enhance accessibility for the print-disabled user, but also useful for other purposes such as rendering on small displays.
Omitted from the specification.
See chapter 2 for information on the relationship between the HTML title and the Dublin Core metadata Title.
HTML 4.0 and this specification exclude these general attributes from this element.
Omitted from this specification.
The possible values are:
| top |
| middle |
| bottom |
See section 3.12.1, the bgcolor attribute of body, for additional discussion.
Monospace display inline.
Deprecated in HTML 4.0 and this specification, in favor of CSS text-decoration:underline.
Deprecated in HTML 4.0 and omitted from this specification. Reading systems need support only one form of bullet, preferably disc.
Deprecated in HTML 4.0 and omitted from this specification.
Identifies a mention of a variable or program argument.
This discussion refers to the CSS 1 and CSS 2 specifications, which can be found at http://www.w3.org/TR/REC-CSS1 and http://www.w3.org/TR/REC-CSS2/ respectively.
Like CSS stylesheets, OEB stylesheets are case-insensitive, except for parts that are not under the control of CSS. In particular, OEB documents are XML documents and, as such, their element names and attribute values are case-sensitive. Therefore, element names and attribute values in OEB stylesheets are case-sensitive. Currently, this applies only to element names and class names used in selectors.
Where there are differences in the syntax specified by CSS1 and CSS2, OEB stylesheets follow the CSS2 syntax. A list of these differences can be found in section D3 of the W3C Recommendation REC-CSS2-19980512, “Cascading Style Sheets, level 2 (CSS2) Specification” (http://www.w3.org/TR/REC-CSS2/grammar.html#tokenizer-diffs).
This specification requires support for only three kinds of CSS selectors. Specifically, those of the form
.classname {}
TAGNAME {}
TAGNAME.classname {}
This specification does not require support for id-based selectors, or selectors that qualify element types based on the element types of their containing elements.
Multiple selectors may be combined with commas, as in
h1, h2, h3, h4, h5, h6 {text-indent: 0em}
All non-zero coordinate and size values must have specified units. All units defined by CSS 1 and 2 are supported:
| px | Pixels |
| ex | x-height of current font |
| em | m-width of current font |
| pt | Points |
| in | Inches |
| cm | Centimeters |
| mm | Millimeters |
| pc | Picas |
Where percentage units are supported, informative text below explains their interpretation, which is as defined in the CSS specifications.
This specification does not list CSS properties omitted from this specification. It does identify, using the previous convention of strike-through, CSS 1 property values that are omitted from this specification. It underlines extensions beyond CSS 2. And it uses “(meaning changed)” to denote changes to the functionality of a property or keyword already defined in CSS.
All properties apply to elements as defined in CSS. That is, most properties can apply to all elements, while a few are limited based on the value of the display property (for example, text-align only applies when the display type is block, not inline). Reading systems are not, however, required to support every distinction; the main example is that they are not required to render borders or to float anything but the specific elements img and table.
Some reading devices do not support colors, or even gray-scale. Use of colors other than white or black may not produce useful renderings on all reading devices.
Current browsers support a host of keyword color names. HTML 4.0 defines 16 named colors, as well as numeric values. OEB stylesheets may use all CSS 1 forms. However, reading systems are not required to distinguish all these colors for rendering (otherwise monochrome devices would necessarily be non-conforming, which is not the intent).
| black | |
| white | |
| aqua | |
| blue | |
| fuschia | |
| gray | |
| green | |
| lime | |
| maroon | |
| navy | |
| olive | |
| purple | |
| red | |
| silver | |
| teal | |
| yellow | |
| #rrggbb | six-digit hexadecimal |
| #rgb | three-digit hexadecimal |
| rgb(r, g, b) | integers in the range 0-255 |
| rgb(r%, g%, b%) | floats in the range of 0.0% to 100.0% |
As with other names in this specification and in XML, these names are case-sensitive (unlike in HTML, which allows mixed case).
In addition, reading systems must recognize the keyword value:
| transparent |
This specification requires control of some aspects of borders, if only to provide non-deprecated alternatives to the <table border="n"> and <img border="n" /> attributes. Of the twelve border properties defined by CSS 1, this specification includes only the border property. It can be used to set a single combination of style, width, and color values for all four borders of an element. This specification also does not require rendering support for color borders.
Reading systems must recognize all of the following style keywords, but may choose to map any style other than none to solid, consistent with the rules for the “CSS 1 core.” Reading systems need not render borders except for img, object, and table.
| none | default, assumed if no style is specified |
| solid | |
| dotted | may be mapped to solid by reading system |
| dashed | may be mapped to solid by reading system |
| double | may be mapped to solid by reading system |
| groove | may be mapped to solid by reading system |
| ridge | may be mapped to solid by reading system |
| inset | may be mapped to solid by reading system |
| outset | may be mapped to solid by reading system |
Reading systems must recognize all of the following width values:
| thin | |
| medium | default, assumed if no style is specified |
| thick | |
| [absolute width] |
A reading system need not render three different widths for the three keyword values. For example, it may map non-zero absolute widths to 1 pixel.
Note: Reading systems must recognize the same set of color values for border as for background-color: and color: (see section 4.1 above), but need not actually distinguish them all in rendering.
Provide support equivalent to the deprecated br clear attribute. The possible values are:
| none (default) |
| left |
| right |
| both |
CSS 1 defines various values for this property, with CSS 2 adding more. Reading systems must respect the CSS 1 values block, inline, and none.
This specification also defines two new values: oeb-page-head and oeb-page-foot. Any content meant for presentation as a page-header or page-footer should be marked up and assigned these values via the display property.
The content of an element assigned display:oeb-page-head should be presented only as a header, and the content of an element assigned display:oeb-page-foot should be presented only as a footer. Neither should be simply presented as if it were inline or block. Reading systems, however, are free to present headers and footers either in special areas as usual for paper publications, or to make them available in another way. For example, a device with a small screen might instead pop them up on demand.
An element assigned display:oeb-page-head or display:oeb-page-foot shall not be considered in effect while any preceding content remains presented. For example, when rendered to a screen with appropriate style settings, the myhead element below would become the page header or footer as soon as nothing preceding the containing div is displayed:
<div> <myhead style="display: oeb-page-head">The OEB Spec: Introduction</myhead> <h2>Introduction</h2> <p>…
Such a header (or footer) remains in effect until another header (or footer) is in effect instead, or until no part of its parent element remains presented (such as when the div is no longer visible in the above example), whichever occurs first.
The possible values are:
| block | Indicates the element is to be formatted as a block, with line-breaks at both ends. |
| inline | Indicates the element is to be formatted without forcing line-breaks at the ends. |
| list-item | |
| oeb-page-head | Addition in support of page headers. |
| oeb-page-foot | Addition in support of page footers. |
| none |
Note: CSS enables a subtle mechanism for controlling whether or not a page-header should be displayed inline when rendered by existing browsers. The most straightforward construct:
<div style="display: oeb-page-head">
will render in an existing browser, for the browser will not recognize, and therefore ignore, the display: oeb-page-head setting. On the other hand,
<div style="display: none; display: oeb-page-head">
will not render in an existing browser. The browser will respond to display: none, ignore the display: oeb-page-head, and suppress formatting and rendering of the div.
Although CSS 1 applies this to all elements, enabling any element to be extracted from inline flow with normal text wrapping around, reading systems need not actually float elements other than img, object, and table. The possible values are:
| left |
| right |
| none |
Accepts a comma-separated list of family names, in order of preference. CSS defines five generic font family names, three of which reading systems must support :
| serif |
| sans-serif |
| monospace |
And two of which reading systems need not support:
| cursive |
| fantasy |
Reading systems must accept the seven named font-sizes, as well as the forms for stepping one size (among the seven) larger or smaller than surrounding text. As discussed under <font size="">, there is no requirement that any given reading device actually render using seven distinct sizes.
Reading devices may provide means to change the mapping between the 7 named font-sizes and physical font sizes. Font-sizes specified with absolute units are presumed not to change size during normal operation (although they may do so in modes focused on universal access for the vision impaired). Content authors should avoid specifying absolute physical font sizes; doing so deprives the user of one of the significant benefits of an electronic book—user control over relative font size.
The possible values are:
| xx-small |
| x-small |
| small |
| medium |
| large |
| x-large |
| xx-large |
| smaller |
| larger |
| [absolute size] |
Percentage values are relative to the parent element’s font size.
Reading systems require support for only two out of three standard values:
| normal |
| italic |
| oblique |
Reading systems are free to treat italic and oblique synonymously; if a system sees either, it may apply either form (many font families provide only one of the two).
This specification requires support for only two values:
| normal |
| bold |
and omits the others (reading systems may accept these values, and are free to render them more simply, such as using only two degrees of boldness):
| bolder |
| lighter |
| 100, 200, 300, 400, 500, 600, 700, 800, 900 |
Applies to block-level and replaced elements.
This property sets the distance between the baselines of two adjacent lines. It accepts the values “normal”, a number, or a length. Negative values are not allowed.
When “normal” is specified, CSS recommends that it function like a numeric value in the range of 1.0 to 1.2.
When a numerical value is specified, the line height is the font size of the current element multiplied by that value. This differs from a percentage value in the way it inherits: when a numerical value is specified, child elements will inherit the factor itself, not the resultant value (as is the case with percentage and other units).
Note also the following details from Section 4.4 of the CSS 1 specification:
If a line of text contains sections with different ‘line-height’ values (because there are inline elements on the line), then each of those sections has its own half-leading above and below. The height of the line-box is from the top of the highest section to the bottom of the lowest one. Note that the top and bottom do not necessarily correspond to the tallest element, since elements can be positioned vertically with the ‘vertical-align’ property. To form a paragraph, each line-box is stacked immediately below the previous line.
Note that any padding, border or margin above and below non-replaced inline elements does not influence the height of the line. In other words: if the ‘line-height’ is too small for the chosen padding or border, it will overlap with text on other lines.
Replaced elements (e.g. images) on the line can make the line-box bigger, if the top of the replaced element (i.e., including all of its padding, border and margin) is above the tallest text section, or if the bottom is below the lowest.
This property delivers the functionality of ordered and unordered lists, and their type attributes. CSS 2 introduces additional values beyond those listed below, none of which are currently supported by this specification.
The possible values are:
| decimal | |
| lower-roman | |
| upper-roman | |
| lower-alpha | |
| upper-alpha | |
| none | |
| disc | omitted for simplicity |
| circle | omitted for simplicity |
| square | omitted for simplicity |
Applies only to the predefined HTML 4.0 list types at this time, because the display:list-item value is not presently supported.
The value must be a length or a percentage. Percentage is relative to the width of the closest block-level ancestor. Reading systems are not required to support the value auto, which sets the value to that of the opposite margin.
The value must be a length or a percentage. Percentage is relative to the width of the closest block-level ancestor. Reading systems are not required to support the value auto, which sets the value to that of the opposite margin.
Note that adjacent top and bottom margins coalesce. If a paragraph with margin-bottom: m px is followed by another with margin-top: n px, then the resulting whitespace is the greater of m and n, as opposed to their sum.
Including this property eliminates the need for many uses of the align attribute. The possible values are:
| left |
| right |
| center |
| justify |
Applies to block-level elements.
The value must be a length or a percentage. Percentage is relative to the parent element’s width.
Applies to block-level elements.
Although CSS applies this to any inline elements reading systems need only support it for images to achieve the functionality of <img align="top" />, <img align="middle" />, and <img align="bottom" />.
The possible values are:
| top |
| middle |
| bottom |
| baseline |
| sub |
| super |
| text-top |
| text-bottom |
| [percentage] |
Applies to img and object.
The value must be a length or a percentage. Percentage is relative to the width of the parent element. Reading systems are not required to support the value auto.
Applies to block-level and replaced elements.
Reading systems are free to treat left and right as always. The possible values are:
| auto | |
| always | |
| left | Force one or two page breaks so that the following content begins on a left-hand page. |
| right | Force one or two page breaks so that the following content begins on a right-hand page. |
| avoid | |
| inherit |
Applies to block-level elements.
Note that this specification does not require support for the page-break-after: property.
Used to implement “keep-together” functionality. With page-break-inside:avoid, the entire element would be moved to a new page rather than broken across a page boundary. Explicit page breaks, as specified by page-break-before:always, take precedence over page-break-inside:avoid.
The possible values are:
| auto |
| avoid |
| inherit |
Applies to block-level elements.
Note that the page-break-inside property is not supported in all current HTML browsers.
This specification only requires support for the values:
| none | Particularly useful for suppressing special rendering of link anchors. |
| underline | |
| line-through |
Reading systems need not support:
| overline |
| blink |
| inherit |
This specification allows use of this special property pending development of a CSS solution. It is suggested that this feature be accessed solely through the use of external stylesheets (not inline) so that a future standard method for accessing this functionality can be easily substituted. The possible values are:
| auto | Reading device decides on optimal number of columns in which to render the text, considering available width, font sizes, or any other metrics it considers relevant for readability. |
| 1 | Reading device should render in one column, regardless of the amount of horizontal space available to display the text. |
Reading systems are free to support integer values other than 1, or may map them to 1.
Reading systems are not required to support column balancing.
Applies to block-level elements.
The following table lists all the relevant HTML element type names alphabetically, along with their status in HTML 4.0 and OEB 1.0. Information about HTML 4.0 is based on the HTML 4.0 element table (http://www.w3.org/TR/REC-html40/index/elements.html). The status is marked as follows:
| Empty: | “E” when end-tag is forbidden because of declared content “Empty”. |
| 4.0: | Blank for the Strict DTD, “F” for the Frameset DTD; “L” for the Loose DTD, “NOT” if not in HTML 4.0 at all (3.2 only); “D” when deprecated (all “L” cases except iframe). |
| OEB: | “+” when included, “-” when excluded, “D” when deprecated. |
| Element Type | Empty | 4.0 | OEB | Description |
|---|---|---|---|---|
| a | + | anchor | ||
| abbr | - | abbreviated form | ||
| acronym | - | acronym | ||
| address | - | information on author | ||
| applet | L, D | - | Java applet | |
| area | E | + | client-side image map area | |
| b | + | bold text style | ||
| base | E | + | document base URI | |
| basefont | E | L, D | - | base font size |
| bdo | - | I18N BiDi over-ride | ||
| big | + | large text style | ||
| blockquote | + | long quotation | ||
| body | + | document body | ||
| br | E | + | forced line break | |
| button | - | push button | ||
| caption | + | table caption | ||
| center | L, D | D | justification control | |
| cite | + | citation | ||
| code | + | computer code fragment | ||
| col | E | - | table column | |
| colgroup | - | table column group | ||
| dd | + | definition description | ||
| del | - | deleted text | ||
| dfn | + | instance definition | ||
| dir | L, D | - | directory list | |
| div | + | generic language/style container | ||
| dl | + | definition list | ||
| dt | + | definition term | ||
| em | + | emphasis | ||
| fieldset | - | form control group | ||
| font | L, D | D | local change to font | |
| form | - | interactive form | ||
| frame | E | F | - | subwindow |
| frameset | F | - | window subdivision | |
| h1 | + | heading | ||
| h2 | + | heading | ||
| h3 | + | heading | ||
| h4 | + | heading | ||
| h5 | + | heading | ||
| h6 | + | heading | ||
| head | + | document head | ||
| hr | E | + | horizontal rule | |
| html | + | document root element | ||
| i | + | italic text style | ||
| iframe | L | - | inline subwindow | |
| img | E | + | Embedded image | |
| input | E | - | form control | |
| ins | - | inserted text | ||
| isindex | E | L, D | - | single line prompt |
| kbd | + | text to be entered by the user | ||
| label | - | form field label text | ||
| legend | - | fieldset legend | ||
| li | + | list item | ||
| link | E | + | a media-independent link | |
| (listing) | NOT | - | (program listing, 3.2 only) | |
| map | + | client-side image map | ||
| menu | L, D | - | menu list | |
| meta | E | + | generic meta-information | |
| noframes | F | - | alternate content container for non frame-based rendering | |
| noscript | - | alternate content container for non script-based rendering | ||
| object | + | generic embedded object | ||
| ol | + | ordered list | ||
| optgroup | - | option group | ||
| option | - | selectable choice | ||
| p | + | paragraph | ||
| param | E | + | named property value | |
| (plaintext) | NOT | - | (plaintext, 3.2 only) | |
| pre | + | preformatted text | ||
| q | + | short inline quotation | ||
| s | L, D | D | strike-through text style | |
| samp | + | program output, scripts, etc. | ||
| script | + | script statements | ||
| select | - | option selector | ||
| small | + | small text style | ||
| span | + | generic language/style container | ||
| strike | L, D | D | strike-through text | |
| strong | + | strong emphasis | ||
| style | + | style info | ||
| sub | + | subscript | ||
| sup | + | superscript | ||
| table | + | |||
| tbody | - | table body | ||
| td | + | table data cell | ||
| textarea | - | multi-line text field | ||
| tfoot | - | table footer | ||
| th | + | table header cell | ||
| thead | - | table header | ||
| title | + | document title | ||
| tr | + | table row | ||
| tt | + | teletype or monospaced text | ||
| u | L, D | D | underlined text style | |
| ul | + | unordered list | ||
| var | + | instance of a variable or program argument | ||
| (xmp) | NOT | - | (example, 3.2 only) |
<!--
Document Type Definition for the Open eBook package version 1.0.1
Version: 1.0.1
Revision: 20010201-x
Authors: Steve DeRose <steven_derose@brown.edu>
Gunter Hille <hille@abc.de>
Ben Trafford <bent@exemplary.net>
Garret Wilson <garret@globalmentor.com>
Usage:
<?xml version="1.0"?>
<!DOCTYPE package
PUBLIC "+//ISBN 0-9673008-1-9//DTD OEB 1.0.1 Package//EN"
"http://openebook.org/dtds/oeb-1.0.1/oebpkg101.dtd">
<package unique-identifier="foo">
metadata
manifest
spine
tours
guide
</package>
References:
Transitional XHTML 1.0 DTD at http://www.w3.org/TR/xhtml1/DTD/transitional.dtd
-->
<!-- ******** Character Mnemonic Entities ******** -->
<!-- OEB supports all XHTML mnemonics, but uses only one entity file. -->
<!ENTITY % OEBEntities PUBLIC "+//ISBN 0-9673008-1-9//DTD OEB 1.0 Entities//EN" "oeb1.ent">
%OEBEntities;
<!-- ******** Attribute Types ******** -->
<!-- LanguageCode: An RFC1766 language code. -->
<!ENTITY % LanguageCode "NMTOKEN">
<!-- URI: An RFC2396 Uniform Resource Identifier. -->
<!ENTITY % URI "CDATA">
<!-- ******** Common Attributes ******** -->
<!-- InternationalAttributes: Attributes for internationalization.
xml:lang: XML language code.
-->
<!ENTITY % InternationalAttributes
"xml:lang %LanguageCode; #IMPLIED"
>
<!-- CoreAttributes: Most common attributes used by many elements.
id: ID unique to the entire document.
-->
<!ENTITY % CoreAttributes "id ID #IMPLIED">
<!-- CommonAttributes: Common attributes used by many elements.
CoreAttributes: Most common attributes.
InternationalAttributes: Internationalization attributes.
-->
<!ENTITY % CommonAttributes
"%CoreAttributes;
%InternationalAttributes;"
>
<!-- DCNamespaceAttribute: Attribute that declare the Dublin Core
namespace. Used mostly on each <dc:XXX> element to accomodate XML
parsers which require this unnecessarily. -->
<!ENTITY % DCNamespaceAttribute
"xmlns:dc %URI; #FIXED 'http://purl.org/dc/elements/1.0/'"
>
<!-- ******** OEB Package Elements ******** -->
<!-- A package must have metadata, a manifest, and a spine,
and optionally may include a tours and/or a guide section. -->
<!ELEMENT package (metadata, manifest, spine, tours?, guide?)>
<!ATTLIST package
%CommonAttributes;
unique-identifier IDREF #REQUIRED
xmlns %URI; #FIXED "http://openebook.org/namespaces/oeb-package/1.0/"
>
<!-- The metadata section must have dc-metadata but may or may not
include x-metadata. -->
<!ELEMENT metadata (dc-metadata, x-metadata?)>
<!-- These elements are optional in <dc-metadata>. -->
<!ENTITY % DCMetadataOptionalElements
"dc:Contributor | dc:Creator | dc:Subject | dc:Description
| dc:Publisher | dc:Date | dc:Type | dc:Format | dc:Source
| dc:Language | dc:Relation | dc:Coverage | dc:Rights"
>
<!-- These are the optional and required elements of <dc-metadata>. -->
<!ENTITY % DCMetadataGeneralElements
"%DCMetadataOptionalElements; | dc:Title |dc:Identifier"
>
<!-- A dc-metadata section must have a dc:Title and a
dc:Identifier, and optionally other dc:XXX elements, all in any
order. -->
<!ELEMENT dc-metadata ((%DCMetadataOptionalElements;)*,
((dc:Title, (%DCMetadataOptionalElements; | dc:Title)*,
(dc:Identifier, (%DCMetadataGeneralElements;)*)) |
(dc:Identifier, (%DCMetadataOptionalElements; | dc:Identifier)*,
(dc:Title, (%DCMetadataGeneralElements;)*))))
>
<!ATTLIST dc-metadata
%CommonAttributes;
%DCNamespaceAttribute;
xmlns:oebpackage %URI; #FIXED "http://openebook.org/namespaces/oeb-package/1.0/"
>
<!-- A dc:Contributor element may optionally have a role and/or a file-as
attribute. -->
<!ELEMENT dc:Contributor (#PCDATA)>
<!ATTLIST dc:Contributor
%CommonAttributes;
%DCNamespaceAttribute;
role NMTOKEN #IMPLIED
file-as CDATA #IMPLIED
>
<!ELEMENT dc:Title (#PCDATA)>
<!ATTLIST dc:Title
%CommonAttributes;
%DCNamespaceAttribute;
>
<!ELEMENT dc:Creator (#PCDATA)>
<!ATTLIST dc:Creator
%CommonAttributes;
%DCNamespaceAttribute;
role NMTOKEN #IMPLIED
file-as CDATA #IMPLIED
>
<!ELEMENT dc:Subject (#PCDATA)>
<!ATTLIST dc:Subject
%CommonAttributes;
%DCNamespaceAttribute;
>
<!ELEMENT dc:Description (#PCDATA)>
<!ATTLIST dc:Description
%CommonAttributes;
%DCNamespaceAttribute;
>
<!ELEMENT dc:Publisher (#PCDATA)>
<!ATTLIST dc:Publisher
%CommonAttributes;
%DCNamespaceAttribute;
>
<!ELEMENT dc:Date (#PCDATA)>
<!ATTLIST dc:Date
%CommonAttributes;
%DCNamespaceAttribute;
event NMTOKEN #IMPLIED
>
<!ELEMENT dc:Type (#PCDATA)>
<!ATTLIST dc:Type
%CommonAttributes;
%DCNamespaceAttribute;
>
<!ELEMENT dc:Format (#PCDATA)>
<!ATTLIST dc:Format
%CommonAttributes;
%DCNamespaceAttribute;
>
<!ELEMENT dc:Identifier (#PCDATA)>
<!ATTLIST dc:Identifier
%CommonAttributes;
%DCNamespaceAttribute;
scheme NMTOKEN #IMPLIED
>
<!ELEMENT dc:Source (#PCDATA)>
<!ATTLIST dc:Source
%CommonAttributes;
%DCNamespaceAttribute;
>
<!ELEMENT dc:Language (#PCDATA)>
<!ATTLIST dc:Language
%CommonAttributes;
%DCNamespaceAttribute;
>
<!ELEMENT dc:Relation (#PCDATA)>
<!ATTLIST dc:Relation
%CommonAttributes;
%DCNamespaceAttribute;
>
<!ELEMENT dc:Coverage (#PCDATA)>
<!ATTLIST dc:Coverage
%CommonAttributes;
%DCNamespaceAttribute;
>
<!ELEMENT dc:Rights (#PCDATA)>
<!ATTLIST dc:Rights
%CommonAttributes;
%DCNamespaceAttribute;
>
<!-- The <x-metadata> element must have at least one <meta> element. -->
<!ELEMENT x-metadata (meta+)>
<!ATTLIST x-metadata %CommonAttributes;>
<!ELEMENT meta EMPTY>
<!ATTLIST meta
%CommonAttributes;
name NMTOKEN #REQUIRED
content CDATA #REQUIRED
scheme CDATA #IMPLIED
>
<!-- The manifest must contain one or more items. -->
<!ELEMENT manifest (item+)>
<!ATTLIST manifest %CommonAttributes;>
<!-- The CommonAttributes entity is not used here because in this case
the "id" attribute is required. -->
<!ELEMENT item EMPTY>
<!ATTLIST item
%InternationalAttributes;
id ID #REQUIRED
href CDATA #REQUIRED
media-type CDATA #REQUIRED
fallback IDREF #IMPLIED
>
<!-- The spine must contain one or more itemrefs. -->
<!ELEMENT spine (itemref+)>
<!ATTLIST spine %CommonAttributes;>
<!ELEMENT itemref EMPTY>
<!ATTLIST itemref
%CommonAttributes;
idref IDREF #REQUIRED
>
<!-- The tours element must have one or more tour elements. -->
<!ELEMENT tours (tour+)>
<!ATTLIST tours %CommonAttributes;>
<!-- Each tour of the set must contain at least one site. -->
<!ELEMENT tour (site+)>
<!ATTLIST tour
%CommonAttributes;
title CDATA #REQUIRED
>
<!-- Each site in a tour must have a title and an href. -->
<!ELEMENT site EMPTY>
<!ATTLIST site
%CommonAttributes;
title CDATA #REQUIRED
href CDATA #REQUIRED
>
<!-- The guide element must have one or more reference elements. -->
<!ELEMENT guide (reference+)>
<!ATTLIST guide %CommonAttributes;>
<!ELEMENT reference EMPTY>
<!ATTLIST reference
%CommonAttributes;
type NMTOKEN #REQUIRED
title CDATA #REQUIRED
href CDATA #REQUIRED
>
<!--
Document Type Definition for the Open eBook document version 1.0.1
Version: 1.0.1
Revision: 20010625-x
Authors: Gunter Hille <hille@abc.de>
Ben Trafford <bent@exemplary.net>
Garret Wilson <garret@globalmentor.com>
Usage:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC
"+//ISBN 0-9673008-1-9//DTD OEB 1.0.1 Document//EN"
"http://openebook.org/dtds/oeb-1.0.1/oebdoc101.dtd">
<html>
...
</html>
References:
This DTD has been derived from XHTML 1.0 and HTML 4.0.
It is a pure subset of neither.
Transitional XHTML 1.0 DTD at http://www.w3.org/TR/xhtml1/DTD/transitional.dtd
-->
<!-- ******** Character Mnemonic Entities ******** -->
<!-- OEB supports all XHTML mnemonics, but uses only one entity file. -->
<!ENTITY % OEBEntities PUBLIC "+//ISBN 0-9673008-1-9//DTD OEB 1.0 Entities//EN" "oeb1.ent">
%OEBEntities;
<!-- ******** Attribute Types ******** -->
<!-- Color: A color specification. -->
<!ENTITY % Color "CDATA">
<!-- Coords: Comma-separated coordinates for image maps. -->
<!ENTITY % Coords "CDATA">
<!-- LanguageCode: An RFC1766 language code. -->
<!ENTITY % LanguageCode "NMTOKEN">
<!-- Length: Number of pixels or percentage in one dimension. -->
<!ENTITY % Length "CDATA">
<!-- LinkTypes: List of types of document link types, used by "rel" and "rev". -->
<!ENTITY % LinkTypes "CDATA">
<!-- MediaType: An RFC2045 media type. -->
<!ENTITY % MediaType "CDATA">
<!-- MediaDest: Intended media destination. -->
<!ENTITY % MediaDest "CDATA">
<!-- A string of one or more digits. -->
<!ENTITY % Number "CDATA">
<!-- ObjectAlign: Non-text multidirectional alignment options. -->
<!ENTITY % ObjectAlign "(top|middle|bottom|left|right)">
<!-- ObjectHAlign: Horizontal non-text alignment options. -->
<!ENTITY % ObjectHAlign "(left|center|right)">
<!-- Shape: Shapes available for image maps. -->
<!ENTITY % Shape "(rect|circle|poly|default)">
<!-- StyleData: Style data (e.g. CSS) -->
<!ENTITY % StyleData "CDATA">
<!-- Text: Character data for such attributes as "title" and "alt". -->
<!ENTITY % Text "CDATA">
<!-- TextHAlign: Horizontal text alignment options. -->
<!ENTITY % TextHAlign "(left|center|right|justify)">
<!-- TextVAlign: Vertical text alignment options. -->
<!ENTITY % TextVAlign "(top|middle|bottom)">
<!-- URI: An RFC2396 Uniform Resource Identifier. -->
<!ENTITY % URI "CDATA">
<!-- A list of URIs separated by spaces. -->
<!ENTITY % URIList "CDATA">
<!-- ******** Common Attributes ******** -->
<!-- InternationalAttributes: Attributes for internationalization.
xml:lang: XML language code.
-->
<!ENTITY % InternationalAttributes
"xml:lang %LanguageCode; #IMPLIED"
>
<!-- CoreAttributes: Most common attributes used by many elements.
id: ID unique to the entire document.
class: List of classes.
style: Style data.
title: Title or additional information.
-->
<!ENTITY % CoreAttributes
"id ID #IMPLIED
class CDATA #IMPLIED
style %StyleData; #IMPLIED
title %Text; #IMPLIED"
>
<!-- CommonAttributes: Common attributes used by many elements.
CoreAttributes: Most common attributes.
InternationalAttributes: Internationalization attributes.
-->
<!ENTITY % CommonAttributes
"%CoreAttributes;
%InternationalAttributes;"
>
<!-- ******** Common Elements ******** -->
<!-- HeadingElements: <h1>..<h6> -->
<!ENTITY % HeadingElements "h1|h2|h3|h4|h5|h6">
<!-- ListElements: Elements for lists. -->
<!ENTITY % ListElements "ul|ol|dl">
<!-- PhraseElements: Inline elements that contain a phrase of text.
Note that while in current HTML implementations many PhraseElements
are rendered identically to FontStyleElements counterparts (such as
<em> and <i>, the former do not connotate rendering styles.
-->
<!ENTITY % PhraseElements
"em | strong | dfn | code | q | sub | sup | samp | kbd | var | cite"
>
<!-- FontStyleElements: Inline font style elements.
Note that many FontStyleElements have been deprecated in favor of
their PhraseElements counterparts.
-->
<!ENTITY % FontStyleElements
"tt | i | b | big | small | u | s | strike |font"
>
<!-- BlockElements: Elements at the block level. -->
<!ENTITY % BlockElements
"%HeadingElements; | %ListElements; | p | pre | hr | blockquote
| center | div | table"
>
<!-- InlineElements: Elements that are inline. -->
<!ENTITY % InlineElements
"%PhraseElements; | %FontStyleElements; | a | br | span | img | object | map"
>
<!-- BlockOrInlineElements: Elements that can be either block or inline. -->
<!ENTITY % BlockOrInlineElements "script">
<!-- %FlowElements: Both block and inline elements, including those that can be both. -->
<!ENTITY % FlowElements "%BlockElements; | %InlineElements; | %BlockOrInlineElements;">
<!-- ******** OEB Document Elements ******** -->
<!ELEMENT br EMPTY>
<!ATTLIST br
%CoreAttributes;
clear (left|all|right|none) "none"
>
<!ELEMENT span (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST span %CommonAttributes;>
<!ELEMENT b (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST b %CommonAttributes;>
<!ELEMENT big (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST big %CommonAttributes;>
<!ELEMENT i (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST i %CommonAttributes;>
<!ELEMENT small (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST small %CommonAttributes;>
<!ELEMENT sub (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST sub %CommonAttributes;>
<!ELEMENT sup (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST sup %CommonAttributes;>
<!ELEMENT tt (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST tt %CommonAttributes;>
<!ELEMENT font (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST font
%CommonAttributes;
size CDATA #IMPLIED
color %Color; #IMPLIED
face CDATA #IMPLIED
>
<!ELEMENT s (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST s %CommonAttributes;>
<!ELEMENT strike (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST strike %CommonAttributes;>
<!ELEMENT u (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST u %CommonAttributes;>
<!ELEMENT cite (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST cite %CommonAttributes;>
<!ELEMENT code (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST code %CommonAttributes;>
<!ELEMENT dfn (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST dfn %CommonAttributes;>
<!ELEMENT em (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST em %CommonAttributes;>
<!ELEMENT kbd (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST kbd %CommonAttributes;>
<!ELEMENT q (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST q
%CommonAttributes;
cite %URI; #IMPLIED
>
<!ELEMENT samp (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST samp %CommonAttributes;>
<!ELEMENT strong (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST strong %CommonAttributes;>
<!ELEMENT var (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST var %CommonAttributes;>
<!ELEMENT div (#PCDATA | %FlowElements;)*>
<!ATTLIST div
%CommonAttributes;
align %TextHAlign; #IMPLIED
>
<!ELEMENT p (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST p
%CommonAttributes;
align %TextHAlign; #IMPLIED
>
<!ELEMENT hr EMPTY >
<!ATTLIST hr
%CommonAttributes;
align %ObjectHAlign; #IMPLIED
size CDATA #IMPLIED
width %Length; #IMPLIED
>
<!ELEMENT center (#PCDATA | %FlowElements;)*>
<!ATTLIST center %CommonAttributes;>
<!ELEMENT blockquote (#PCDATA | %FlowElements;)*>
<!ATTLIST blockquote
%CommonAttributes;
cite %URI; #IMPLIED
>
<!ELEMENT pre
(#PCDATA | %PhraseElements; | a | br | span | map | tt | i | b | u | s)*
>
<!ATTLIST pre
%CommonAttributes;
xml:space (preserve) #FIXED "preserve"
>
<!-- Heading Elements -->
<!ELEMENT h1 (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST h1
%CommonAttributes;
align %TextHAlign; #IMPLIED
>
<!ELEMENT h2 (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST h2
%CommonAttributes;
align %TextHAlign; #IMPLIED
>
<!ELEMENT h3 (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST h3
%CommonAttributes;
align %TextHAlign; #IMPLIED
>
<!ELEMENT h4 (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST h4
%CommonAttributes;
align %TextHAlign; #IMPLIED
>
<!ELEMENT h5 (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST h5
%CommonAttributes;
align %TextHAlign; #IMPLIED
>
<!ELEMENT h6 (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST h6
%CommonAttributes;
align %TextHAlign; #IMPLIED
>
<!ELEMENT script (#PCDATA)>
<!ATTLIST script
xml:space (preserve) #FIXED "preserve"
>
<!ELEMENT style (#PCDATA)>
<!ATTLIST style
%InternationalAttributes;
type %MediaType; #FIXED "text/x-oeb1-css"
title %Text; #IMPLIED
xml:space (preserve) #FIXED "preserve"
>
<!ELEMENT img EMPTY >
<!ATTLIST img
%CommonAttributes;
align %ObjectAlign; #IMPLIED
border CDATA #IMPLIED
hspace CDATA #IMPLIED
vspace CDATA #IMPLIED
src %URI; #REQUIRED
alt %Text; #REQUIRED
longdesc %URI; #IMPLIED
height %Length; #IMPLIED
width %Length; #IMPLIED
usemap %URI; #IMPLIED
>
<!ELEMENT a
(#PCDATA | %FontStyleElements; | %PhraseElements; | %BlockOrInlineElements;
| br | span | object | img | map)*
>
<!ATTLIST a
%CommonAttributes;
name NMTOKEN #IMPLIED
href %URI; #IMPLIED
rel %LinkTypes; #IMPLIED
rev %LinkTypes; #IMPLIED
>
<!ELEMENT base EMPTY>
<!ATTLIST base
href %URI; #REQUIRED
>
<!ELEMENT link EMPTY>
<!ATTLIST link
%CommonAttributes;
href %URI; #IMPLIED
type %MediaType; #REQUIRED
rel %LinkTypes; #IMPLIED
rev %LinkTypes; #IMPLIED
media %MediaDest; #IMPLIED
>
<!-- The CommonAttributes entity is not used here because in this case
the "id" attribute is required. -->
<!ELEMENT map ((%BlockElements; | %BlockOrInlineElements;)+ | area+)>
<!ATTLIST map
%InternationalAttributes;
id ID #REQUIRED
class CDATA #IMPLIED
style %StyleData; #IMPLIED
title %Text; #IMPLIED
name NMTOKEN #IMPLIED
>
<!ELEMENT area EMPTY>
<!ATTLIST area
%CommonAttributes;
href %URI; #IMPLIED
shape %Shape; "rect"
coords %Coords; #IMPLIED
nohref (nohref) #IMPLIED
alt %Text; #REQUIRED
>
<!ELEMENT object
(#PCDATA | %BlockElements; | %InlineElements; | %BlockOrInlineElements; | param)*
>
<!ATTLIST object
%CommonAttributes;
classid %URI; #IMPLIED
codebase %URI; #IMPLIED
data %URI; #IMPLIED
type %MediaType; #IMPLIED
codetype %MediaType; #IMPLIED
archive %URIList; #IMPLIED
height %Length; #IMPLIED
width %Length; #IMPLIED
usemap %URI; #IMPLIED
align %ObjectAlign; #IMPLIED
border CDATA #IMPLIED
hspace CDATA #IMPLIED
vspace CDATA #IMPLIED
>
<!ELEMENT param EMPTY >
<!ATTLIST param
id ID #IMPLIED
name CDATA #REQUIRED
value CDATA #IMPLIED
valuetype (data|ref|object) "data"
type %MediaType; #IMPLIED
>
<!ELEMENT dl (dt|dd)+ >
<!ATTLIST dl %CommonAttributes;>
<!ELEMENT dt (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST dt %CommonAttributes;>
<!ELEMENT dd (#PCDATA | %FlowElements;)*>
<!ATTLIST dd %CommonAttributes;>
<!ELEMENT ol (li)+ >
<!ATTLIST ol
%CommonAttributes;
type (1|a|A|i|I) #IMPLIED
>
<!ELEMENT ul (li)+>
<!ATTLIST ul %CommonAttributes;>
<!ELEMENT li (#PCDATA | %FlowElements;)*>
<!ATTLIST li
%CommonAttributes;
type (1|a|A|i|I) #IMPLIED
>
<!ELEMENT table (caption?, tr+) >
<!ATTLIST table
%CommonAttributes;
summary %Text; #IMPLIED
width %Length; #IMPLIED
border CDATA #IMPLIED
cellspacing %Length; #IMPLIED
cellpadding %Length; #IMPLIED
align %ObjectHAlign; #IMPLIED
bgcolor %Color; #IMPLIED
>
<!ELEMENT caption (#PCDATA | %InlineElements; | %BlockOrInlineElements;)*>
<!ATTLIST caption %CommonAttributes;>
<!ELEMENT tr ( th | td )+ >
<!ATTLIST tr
%CommonAttributes;
valign %TextVAlign; #IMPLIED
bgcolor %Color; #IMPLIED
>
<!ELEMENT th (#PCDATA | %FlowElements;)*>
<!ATTLIST th
%CommonAttributes;
abbr %Text; #IMPLIED
rowspan %Number; "1"
colspan %Number; "1"
align %TextHAlign; #IMPLIED
valign %TextVAlign; #IMPLIED
nowrap (nowrap) #IMPLIED
bgcolor %Color; #IMPLIED
width %Length; #IMPLIED
height %Length; #IMPLIED
>
<!ELEMENT td (#PCDATA | %FlowElements;)*>
<!ATTLIST td
%CommonAttributes;
abbr %Text; #IMPLIED
rowspan %Number; "1"
colspan %Number; "1"
align %TextHAlign; #IMPLIED
valign %TextVAlign; #IMPLIED
nowrap (nowrap) #IMPLIED
bgcolor %Color; #IMPLIED
width %Length; #IMPLIED
height %Length; #IMPLIED
>
<!ELEMENT title (#PCDATA)>
<!ATTLIST title %InternationalAttributes;>
<!ELEMENT meta EMPTY >
<!ATTLIST meta
%InternationalAttributes;
name NMTOKEN #IMPLIED
content CDATA #REQUIRED
scheme CDATA #IMPLIED
>
<!-- HeadElements: Elements that can appear many places within <head>.-->
<!ENTITY % HeadElements "script | style | meta | link | object">
<!-- <head> can have the common head elements (always optional),
with one <title> and an optional <base> interspersed.
-->
<!ELEMENT head ((%HeadElements;)*,
((title, (%HeadElements;)*, (base, (%HeadElements;)*)?)
| (base, (%HeadElements;)*, (title, (%HeadElements;)*))))
>
<!ATTLIST head %InternationalAttributes;>
<!ELEMENT body (#PCDATA | %FlowElements;)*>
<!ATTLIST body
%CommonAttributes;
bgcolor %Color; #IMPLIED
text %Color; #IMPLIED
>
<!ELEMENT html (head?, body)>
<!ATTLIST html
%InternationalAttributes;
xmlns %URI; #FIXED "http://openebook.org/namespaces/oeb-document/1.0/"
>
<!--
Character entities for the Open eBook publication structure version 1.0.1
Version: 1.0.1
Revision: 20001122-x
Authors: Gunter Hille <hille@abc.de>
Ben Trafford <bent@exemplary.net>
Garret Wilson <garret@globalmentor.com>
Usage:
<!ENTITY % OEBEntities PUBLIC "+//ISBN 0-9673008-1-9//DTD OEB 1.0 Entities//EN" "oeb1.ent">
%OEBEntities;
References:
This DTD fragment is merely a combination of the external entities included
with XHTML 1.0.
Transitional XHTML 1.0 DTD at http://www.w3.org/TR/xhtml1/DTD/transitional.dtd
http://www.w3.org/TR/xhtml1/DTD/HTMLlat1x.ent
http://www.w3.org/TR/xhtml1/DTD/HTMLspecialx.ent
http://www.w3.org/TR/xhtml1/DTD/HTMLsymbolx.ent
Portions (C) International Organization for Standardization 1986.
Permission to copy in any form is granted for use with
conforming SGML systems and applications as defined in
ISO 8879, provided this notice is included in all copies.
-->
<!ENTITY nbsp " " ><!-- no-break space = non-breaking space,
U+00A0 ISOnum -->
<!ENTITY iexcl "¡" ><!-- inverted exclamation mark,
U+00A1 ISOnum -->
<!ENTITY cent "¢" ><!-- cent sign,
U+00A2 ISOnum -->
<!ENTITY pound "£" ><!-- pound sign,
U+00A3 ISOnum -->
<!ENTITY curren "¤" ><!-- currency sign,
U+00A4 ISOnum -->
<!ENTITY yen "¥" ><!-- yen sign = yuan sign,
U+00A5 ISOnum -->
<!ENTITY brvbar "¦" ><!-- broken bar = broken vertical bar,
U+00A6 ISOnum -->
<!ENTITY sect "§" ><!-- section sign,
U+00A7 ISOnum -->
<!ENTITY uml "¨" ><!-- diaeresis = spacing diaeresis,
U+00A8 ISOdia -->
<!ENTITY copy "©" ><!-- copyright sign,
U+00A9 ISOnum -->
<!ENTITY ordf "ª" ><!-- feminine ordinal indicator,
U+00AA ISOnum -->
<!ENTITY laquo "«" ><!-- left-pointing double angle quotation mark
= left pointing guillemet,
U+00AB ISOnum -->
<!ENTITY not "¬" ><!-- not sign,
U+00AC ISOnum -->
<!ENTITY shy "­" ><!-- soft hyphen = discretionary hyphen,
U+00AD ISOnum -->
<!ENTITY reg "®" ><!-- registered sign = registered trade mark sign,
U+00AE ISOnum -->
<!ENTITY macr "¯" ><!-- macron = spacing macron = overline
= APL overbar,
U+00AF ISOdia -->
<!ENTITY deg "°" ><!-- degree sign,
U+00B0 ISOnum -->
<!ENTITY plusmn "±" ><!-- plus-minus sign = plus-or-minus sign,
U+00B1 ISOnum -->
<!ENTITY sup2 "²" ><!-- superscript two = superscript digit two
= squared,
U+00B2 ISOnum -->
<!ENTITY sup3 "³" ><!-- superscript three = superscript digit three
= cubed,
U+00B3 ISOnum -->
<!ENTITY acute "´" ><!-- acute accent = spacing acute,
U+00B4 ISOdia -->
<!ENTITY micro "µ" ><!-- micro sign,
U+00B5 ISOnum -->
<!ENTITY para "¶" ><!-- pilcrow sign = paragraph sign,
U+00B6 ISOnum -->
<!ENTITY middot "·" ><!-- middle dot = Georgian comma
= Greek middle dot,
U+00B7 ISOnum -->
<!ENTITY cedil "¸" ><!-- cedilla = spacing cedilla,
U+00B8 ISOdia -->
<!ENTITY sup1 "¹" ><!-- superscript one = superscript digit one,
U+00B9 ISOnum -->
<!ENTITY ordm "º" ><!-- masculine ordinal indicator,
U+00BA ISOnum -->
<!ENTITY raquo "»" ><!-- right-pointing double angle quotation mark
= right pointing guillemet,
U+00BB ISOnum -->
<!ENTITY frac14 "¼" ><!-- vulgar fraction one quarter
= fraction one quarter,
U+00BC ISOnum -->
<!ENTITY frac12 "½" ><!-- vulgar fraction one half
= fraction one half,
U+00BD ISOnum -->
<!ENTITY frac34 "¾" ><!-- vulgar fraction three quarters
= fraction three quarters,
U+00BE ISOnum -->
<!ENTITY iquest "¿" ><!-- inverted question mark
= turned question mark,
U+00BF ISOnum -->
<!ENTITY Agrave "À" ><!-- latin capital letter A with grave
= latin capital letter A grave,
U+00C0 ISOlat1 -->
<!ENTITY Aacute "Á" ><!-- latin capital letter A with acute,
U+00C1 ISOlat1 -->
<!ENTITY Acirc "Â" ><!-- latin capital letter A with circumflex,
U+00C2 ISOlat1 -->
<!ENTITY Atilde "Ã" ><!-- latin capital letter A with tilde,
U+00C3 ISOlat1 -->
<!ENTITY Auml "Ä" ><!-- latin capital letter A with diaeresis,
U+00C4 ISOlat1 -->
<!ENTITY Aring "Å" ><!-- latin capital letter A with ring above
= latin capital letter A ring,
U+00C5 ISOlat1 -->
<!ENTITY AElig "Æ" ><!-- latin capital letter AE
= latin capital ligature AE,
U+00C6 ISOlat1 -->
<!ENTITY Ccedil "Ç" ><!-- latin capital letter C with cedilla,
U+00C7 ISOlat1 -->
<!ENTITY Egrave "È" ><!-- latin capital letter E with grave,
U+00C8 ISOlat1 -->
<!ENTITY Eacute "É" ><!-- latin capital letter E with acute,
U+00C9 ISOlat1 -->
<!ENTITY Ecirc "Ê" ><!-- latin capital letter E with circumflex,
U+00CA ISOlat1 -->
<!ENTITY Euml "Ë" ><!-- latin capital letter E with diaeresis,
U+00CB ISOlat1 -->
<!ENTITY Igrave "Ì" ><!-- latin capital letter I with grave,
U+00CC ISOlat1 -->
<!ENTITY Iacute "Í" ><!-- latin capital letter I with acute,
U+00CD ISOlat1 -->
<!ENTITY Icirc "Î" ><!-- latin capital letter I with circumflex,
U+00CE ISOlat1 -->
<!ENTITY Iuml "Ï" ><!-- latin capital letter I with diaeresis,
U+00CF ISOlat1 -->
<!ENTITY ETH "Ð" ><!-- latin capital letter ETH,
U+00D0 ISOlat1 -->
<!ENTITY Ntilde "Ñ" ><!-- latin capital letter N with tilde,
U+00D1 ISOlat1 -->
<!ENTITY Ograve "Ò" ><!-- latin capital letter O with grave,
U+00D2 ISOlat1 -->
<!ENTITY Oacute "Ó" ><!-- latin capital letter O with acute,
U+00D3 ISOlat1 -->
<!ENTITY Ocirc "Ô" ><!-- latin capital letter O with circumflex,
U+00D4 ISOlat1 -->
<!ENTITY Otilde "Õ" ><!-- latin capital letter O with tilde,
U+00D5 ISOlat1 -->
<!ENTITY Ouml "Ö" ><!-- latin capital letter O with diaeresis,
U+00D6 ISOlat1 -->
<!ENTITY times "×" ><!-- multiplication sign,
U+00D7 ISOnum -->
<!ENTITY Oslash "Ø" ><!-- latin capital letter O with stroke
= latin capital letter O slash,
U+00D8 ISOlat1 -->
<!ENTITY Ugrave "Ù" ><!-- latin capital letter U with grave,
U+00D9 ISOlat1 -->
<!ENTITY Uacute "Ú" ><!-- latin capital letter U with acute,
U+00DA ISOlat1 -->
<!ENTITY Ucirc "Û" ><!-- latin capital letter U with circumflex,
U+00DB ISOlat1 -->
<!ENTITY Uuml "Ü" ><!-- latin capital letter U with diaeresis,
U+00DC ISOlat1 -->
<!ENTITY Yacute "Ý" ><!-- latin capital letter Y with acute,
U+00DD ISOlat1 -->
<!ENTITY THORN "Þ" ><!-- latin capital letter THORN,
U+00DE ISOlat1 -->
<!ENTITY szlig "ß" ><!-- latin small letter sharp s = ess-zed,
U+00DF ISOlat1 -->
<!ENTITY agrave "à" ><!-- latin small letter a with grave
= latin small letter a grave,
U+00E0 ISOlat1 -->
<!ENTITY aacute "á" ><!-- latin small letter a with acute,
U+00E1 ISOlat1 -->
<!ENTITY acirc "â" ><!-- latin small letter a with circumflex,
U+00E2 ISOlat1 -->
<!ENTITY atilde "ã" ><!-- latin small letter a with tilde,
U+00E3 ISOlat1 -->
<!ENTITY auml "ä" ><!-- latin small letter a with diaeresis,
U+00E4 ISOlat1 -->
<!ENTITY aring "å" ><!-- latin small letter a with ring above
= latin small letter a ring,
U+00E5 ISOlat1 -->
<!ENTITY aelig "æ" ><!-- latin small letter ae
= latin small ligature ae,
U+00E6 ISOlat1 -->
<!ENTITY ccedil "ç" ><!-- latin small letter c with cedilla,
U+00E7 ISOlat1 -->
<!ENTITY egrave "è" ><!-- latin small letter e with grave,
U+00E8 ISOlat1 -->
<!ENTITY eacute "é" ><!-- latin small letter e with acute,
U+00E9 ISOlat1 -->
<!ENTITY ecirc "ê" ><!-- latin small letter e with circumflex,
U+00EA ISOlat1 -->
<!ENTITY euml "ë" ><!-- latin small letter e with diaeresis,
U+00EB ISOlat1 -->
<!ENTITY igrave "ì" ><!-- latin small letter i with grave,
U+00EC ISOlat1 -->
<!ENTITY iacute "í" ><!-- latin small letter i with acute,
U+00ED ISOlat1 -->
<!ENTITY icirc "î" ><!-- latin small letter i with circumflex,
U+00EE ISOlat1 -->
<!ENTITY iuml "ï" ><!-- latin small letter i with diaeresis,
U+00EF ISOlat1 -->
<!ENTITY eth "ð" ><!-- latin small letter eth,
U+00F0 ISOlat1 -->
<!ENTITY ntilde "ñ" ><!-- latin small letter n with tilde,
U+00F1 ISOlat1 -->
<!ENTITY ograve "ò" ><!-- latin small letter o with grave,
U+00F2 ISOlat1 -->
<!ENTITY oacute "ó" ><!-- latin small letter o with acute,
U+00F3 ISOlat1 -->
<!ENTITY ocirc "ô" ><!-- latin small letter o with circumflex,
U+00F4 ISOlat1 -->
<!ENTITY otilde "õ" ><!-- latin small letter o with tilde,
U+00F5 ISOlat1 -->
<!ENTITY ouml "ö" ><!-- latin small letter o with diaeresis,
U+00F6 ISOlat1 -->
<!ENTITY divide "÷" ><!-- division sign,
U+00F7 ISOnum -->
<!ENTITY oslash "ø" ><!-- latin small letter o with stroke,
= latin small letter o slash,
U+00F8 ISOlat1 -->
<!ENTITY ugrave "ù" ><!-- latin small letter u with grave,
U+00F9 ISOlat1 -->
<!ENTITY uacute "ú" ><!-- latin small letter u with acute,
U+00FA ISOlat1 -->
<!ENTITY ucirc "û" ><!-- latin small letter u with circumflex,
U+00FB ISOlat1 -->
<!ENTITY uuml "ü" ><!-- latin small letter u with diaeresis,
U+00FC ISOlat1 -->
<!ENTITY yacute "ý" ><!-- latin small letter y with acute,
U+00FD ISOlat1 -->
<!ENTITY thorn "þ" ><!-- latin small letter thorn with,
U+00FE ISOlat1 -->
<!ENTITY yuml "ÿ" ><!-- latin small letter y with diaeresis,
U+00FF ISOlat1 -->
<!-- C0 Controls and Basic Latin -->
<!ENTITY apos "'">
<!-- Latin Extended-A -->
<!ENTITY OElig "Œ" ><!-- latin capital ligature OE, U+0152 ISOlat2 -->
<!ENTITY oelig "œ" ><!-- latin small ligature oe, U+0153 ISOlat2 -->
<!-- ligature is a misnomer, this is a separate character in some languages -->
<!ENTITY Scaron "Š" ><!-- latin capital letter S with caron,
U+0160 ISOlat2 -->
<!ENTITY scaron "š" ><!-- latin small letter s with caron,
U+0161 ISOlat2 -->
<!ENTITY Yuml "Ÿ" ><!-- latin capital letter Y with diaeresis,
U+0178 ISOlat2 -->
<!-- Spacing Modifier Letters -->
<!ENTITY circ "ˆ" ><!-- modifier letter circumflex accent,
U+02C6 ISOpub -->
<!ENTITY tilde "˜" ><!-- small tilde, U+02DC ISOdia -->
<!-- General Punctuation -->
<!ENTITY ensp " " ><!-- en space, U+2002 ISOpub -->
<!ENTITY emsp " " ><!-- em space, U+2003 ISOpub -->
<!ENTITY thinsp " " ><!-- thin space, U+2009 ISOpub -->
<!ENTITY zwnj "‌" ><!-- zero width non-joiner,
U+200C NEW RFC 2070 -->
<!ENTITY zwj "‍" ><!-- zero width joiner, U+200D NEW RFC 2070 -->
<!ENTITY lrm "‎" ><!-- left-to-right mark, U+200E NEW RFC 2070 -->
<!ENTITY rlm "‏" ><!-- right-to-left mark, U+200F NEW RFC 2070 -->
<!ENTITY ndash "–" ><!-- en dash, U+2013 ISOpub -->
<!ENTITY mdash "—" ><!-- em dash, U+2014 ISOpub -->
<!ENTITY lsquo "‘" ><!-- left single quotation mark,
U+2018 ISOnum -->
<!ENTITY rsquo "’" ><!-- right single quotation mark,
U+2019 ISOnum -->
<!ENTITY sbquo "‚" ><!-- single low-9 quotation mark, U+201A NEW -->
<!ENTITY ldquo "“" ><!-- left double quotation mark,
U+201C ISOnum -->
<!ENTITY rdquo "”" ><!-- right double quotation mark,
U+201D ISOnum -->
<!ENTITY bdquo "„" ><!-- double low-9 quotation mark, U+201E NEW -->
<!ENTITY dagger "†" ><!-- dagger, U+2020 ISOpub -->
<!ENTITY Dagger "‡" ><!-- double dagger, U+2021 ISOpub -->
<!ENTITY permil "‰" ><!-- per mille sign, U+2030 ISOtech -->
<!-- lsaquo is proposed but not yet ISO standardized -->
<!ENTITY lsaquo "‹" ><!-- single left-pointing angle quotation mark,
U+2039 ISO proposed -->
<!-- rsaquo is proposed but not yet ISO standardized -->
<!ENTITY rsaquo "›" ><!-- single right-pointing angle quotation mark,
U+203A ISO proposed -->
<!ENTITY euro "€" ><!-- euro sign, U+20AC NEW -->
<!-- Latin Extended-B -->
<!ENTITY fnof "ƒ" ><!-- latin small f with hook = function
= florin, U+0192 ISOtech -->
<!-- Greek -->
<!ENTITY Alpha "Α" ><!-- greek capital letter alpha, U+0391 -->
<!ENTITY Beta "Β" ><!-- greek capital letter beta, U+0392 -->
<!ENTITY Gamma "Γ" ><!-- greek capital letter gamma, U+0393 ISOgrk3 -->
<!ENTITY Delta "Δ" ><!-- greek capital letter delta, U+0394 ISOgrk3 -->
<!ENTITY Epsilon "Ε" ><!-- greek capital letter epsilon, U+0395 -->
<!ENTITY Zeta "Ζ" ><!-- greek capital letter zeta, U+0396 -->
<!ENTITY Eta "Η" ><!-- greek capital letter eta, U+0397 -->
<!ENTITY Theta "Θ" ><!-- greek capital letter theta, U+0398 ISOgrk3 -->
<!ENTITY Iota "Ι" ><!-- greek capital letter iota, U+0399 -->
<!ENTITY Kappa "Κ" ><!-- greek capital letter kappa, U+039A -->
<!ENTITY Lambda "Λ" ><!-- greek capital letter lambda, U+039B ISOgrk3 -->
<!ENTITY Mu "Μ" ><!-- greek capital letter mu, U+039C -->
<!ENTITY Nu "Ν" ><!-- greek capital letter nu, U+039D -->
<!ENTITY Xi "Ξ" ><!-- greek capital letter xi, U+039E ISOgrk3 -->
<!ENTITY Omicron "Ο" ><!-- greek capital letter omicron, U+039F -->
<!ENTITY Pi "Π" ><!-- greek capital letter pi, U+03A0 ISOgrk3 -->
<!ENTITY Rho "Ρ" ><!-- greek capital letter rho, U+03A1 -->
<!-- there is no Sigmaf, and no U+03A2 character either -->
<!ENTITY Sigma "Σ" ><!-- greek capital letter sigma, U+03A3 ISOgrk3 -->
<!ENTITY Tau "Τ" ><!-- greek capital letter tau, U+03A4 -->
<!ENTITY Upsilon "Υ" ><!-- greek capital letter upsilon,
U+03A5 ISOgrk3 -->
<!ENTITY Phi "Φ" ><!-- greek capital letter phi, U+03A6 ISOgrk3 -->
<!ENTITY Chi "Χ" ><!-- greek capital letter chi, U+03A7 -->
<!ENTITY Psi "Ψ" ><!-- greek capital letter psi, U+03A8 ISOgrk3 -->
<!ENTITY Omega "Ω" ><!-- greek capital letter omega, U+03A9 ISOgrk3 -->
<!ENTITY alpha "α" ><!-- greek small letter alpha, U+03B1 ISOgrk3 -->
<!ENTITY beta "β" ><!-- greek small letter beta, U+03B2 ISOgrk3 -->
<!ENTITY gamma "γ" ><!-- greek small letter gamma, U+03B3 ISOgrk3 -->
<!ENTITY delta "δ" ><!-- greek small letter delta, U+03B4 ISOgrk3 -->
<!ENTITY epsilon "ε" ><!-- greek small letter epsilon, U+03B5 ISOgrk3 -->
<!ENTITY zeta "ζ" ><!-- greek small letter zeta, U+03B6 ISOgrk3 -->
<!ENTITY eta "η" ><!-- greek small letter eta, U+03B7 ISOgrk3 -->
<!ENTITY theta "θ" ><!-- greek small letter theta, U+03B8 ISOgrk3 -->
<!ENTITY iota "ι" ><!-- greek small letter iota, U+03B9 ISOgrk3 -->
<!ENTITY kappa "κ" ><!-- greek small letter kappa, U+03BA ISOgrk3 -->
<!ENTITY lambda "λ" ><!-- greek small letter lambda, U+03BB ISOgrk3 -->
<!ENTITY mu "μ" ><!-- greek small letter mu, U+03BC ISOgrk3 -->
<!ENTITY nu "ν" ><!-- greek small letter nu, U+03BD ISOgrk3 -->
<!ENTITY xi "ξ" ><!-- greek small letter xi, U+03BE ISOgrk3 -->
<!ENTITY omicron "ο" ><!-- greek small letter omicron, U+03BF NEW -->
<!ENTITY pi "π" ><!-- greek small letter pi, U+03C0 ISOgrk3 -->
<!ENTITY rho "ρ" ><!-- greek small letter rho, U+03C1 ISOgrk3 -->
<!ENTITY sigmaf "ς" ><!-- greek small letter final sigma,
U+03C2 ISOgrk3 -->
<!ENTITY sigma "σ" ><!-- greek small letter sigma, U+03C3 ISOgrk3 -->
<!ENTITY tau "τ" ><!-- greek small letter tau, U+03C4 ISOgrk3 -->
<!ENTITY upsilon "υ" ><!-- greek small letter upsilon,
U+03C5 ISOgrk3 -->
<!ENTITY phi "φ" ><!-- greek small letter phi, U+03C6 ISOgrk3 -->
<!ENTITY chi "χ" ><!-- greek small letter chi, U+03C7 ISOgrk3 -->
<!ENTITY psi "ψ" ><!-- greek small letter psi, U+03C8 ISOgrk3 -->
<!ENTITY omega "ω" ><!-- greek small letter omega, U+03C9 ISOgrk3 -->
<!ENTITY thetasym "ϑ" ><!-- greek small letter theta symbol,
U+03D1 NEW -->
<!ENTITY upsih "ϒ" ><!-- greek upsilon with hook symbol,
U+03D2 NEW -->
<!ENTITY piv "ϖ" ><!-- greek pi symbol, U+03D6 ISOgrk3 -->
<!-- General Punctuation -->
<!ENTITY bull "•" ><!-- bullet = black small circle,
U+2022 ISOpub -->
<!-- bullet is NOT the same as bullet operator, U+2219 -->
<!ENTITY hellip "…" ><!-- horizontal ellipsis = three dot leader,
U+2026 ISOpub -->
<!ENTITY prime "′" ><!-- prime = minutes = feet, U+2032 ISOtech -->
<!ENTITY Prime "″" ><!-- double prime = seconds = inches,
U+2033 ISOtech -->
<!ENTITY oline "‾" ><!-- overline = spacing overscore,
U+203E NEW -->
<!ENTITY frasl "⁄" ><!-- fraction slash, U+2044 NEW -->
<!-- Letterlike Symbols -->
<!ENTITY weierp "℘" ><!-- script capital P = power set
= Weierstrass p, U+2118 ISOamso -->
<!ENTITY image "ℑ" ><!-- blackletter capital I = imaginary part,
U+2111 ISOamso -->
<!ENTITY real "ℜ" ><!-- blackletter capital R = real part symbol,
U+211C ISOamso -->
<!ENTITY trade "™" ><!-- trade mark sign, U+2122 ISOnum -->
<!ENTITY alefsym "ℵ" ><!-- alef symbol = first transfinite cardinal,
U+2135 NEW -->
<!-- alef symbol is NOT the same as hebrew letter alef,
U+05D0 although the same glyph could be used to depict both characters -->
<!-- Arrows -->
<!ENTITY larr "←" ><!-- leftwards arrow, U+2190 ISOnum -->
<!ENTITY uarr "↑" ><!-- upwards arrow, U+2191 ISOnum-->
<!ENTITY rarr "→" ><!-- rightwards arrow, U+2192 ISOnum -->
<!ENTITY darr "↓" ><!-- downwards arrow, U+2193 ISOnum -->
<!ENTITY harr "↔" ><!-- left right arrow, U+2194 ISOamsa -->
<!ENTITY crarr "↵" ><!-- downwards arrow with corner leftwards
= carriage return, U+21B5 NEW -->
<!ENTITY lArr "⇐" ><!-- leftwards double arrow, U+21D0 ISOtech -->
<!-- Unicode does not say that lArr is the same as the 'is implied by' arrow
but also does not have any other character for that function. So ? lArr can
be used for 'is implied by' as ISOtech suggests -->
<!ENTITY uArr "⇑" ><!-- upwards double arrow, U+21D1 ISOamsa -->
<!ENTITY rArr "⇒" ><!-- rightwards double arrow,
U+21D2 ISOtech -->
<!-- Unicode does not say this is the 'implies' character but does not have
another character with this function so ?
rArr can be used for 'implies' as ISOtech suggests -->
<!ENTITY dArr "⇓" ><!-- downwards double arrow, U+21D3 ISOamsa -->
<!ENTITY hArr "⇔" ><!-- left right double arrow,
U+21D4 ISOamsa -->
<!-- Mathematical Operators -->
<!ENTITY forall "∀" ><!-- for all, U+2200 ISOtech -->
<!ENTITY part "∂" ><!-- partial differential, U+2202 ISOtech -->
<!ENTITY exist "∃" ><!-- there exists, U+2203 ISOtech -->
<!ENTITY empty "∅" ><!-- empty set = null set = diameter,
U+2205 ISOamso -->
<!ENTITY nabla "∇" ><!-- nabla = backward difference,
U+2207 ISOtech -->
<!ENTITY isin "∈" ><!-- element of, U+2208 ISOtech -->
<!ENTITY notin "∉" ><!-- not an element of, U+2209 ISOtech -->
<!ENTITY ni "∋" ><!-- contains as member, U+220B ISOtech -->
<!-- should there be a more memorable name than 'ni'? -->
<!ENTITY prod "∏" ><!-- n-ary product = product sign,
U+220F ISOamsb -->
<!-- prod is NOT the same character as U+03A0 'greek capital letter pi' though
the same glyph might be used for both -->
<!ENTITY sum "∑" ><!-- n-ary sumation, U+2211 ISOamsb -->
<!-- sum is NOT the same character as U+03A3 'greek capital letter sigma'
though the same glyph might be used for both -->
<!ENTITY minus "−" ><!-- minus sign, U+2212 ISOtech -->
<!ENTITY lowast "∗" ><!-- asterisk operator, U+2217 ISOtech -->
<!ENTITY radic "√" ><!-- square root = radical sign,
U+221A ISOtech -->
<!ENTITY prop "∝" ><!-- proportional to, U+221D ISOtech -->
<!ENTITY infin "∞" ><!-- infinity, U+221E ISOtech -->
<!ENTITY ang "∠" ><!-- angle, U+2220 ISOamso -->
<!ENTITY and "∧" ><!-- logical and = wedge, U+2227 ISOtech -->
<!ENTITY or "∨" ><!-- logical or = vee, U+2228 ISOtech -->
<!ENTITY cap "∩" ><!-- intersection = cap, U+2229 ISOtech -->
<!ENTITY cup "∪" ><!-- union = cup, U+222A ISOtech -->
<!ENTITY int "∫" ><!-- integral, U+222B ISOtech -->
<!ENTITY there4 "∴" ><!-- therefore, U+2234 ISOtech -->
<!ENTITY sim "∼" ><!-- tilde operator = varies with = similar to,
U+223C ISOtech -->
<!-- tilde operator is NOT the same character as the tilde, U+007E,
although the same glyph might be used to represent both -->
<!ENTITY cong "≅" ><!-- approximately equal to, U+2245 ISOtech -->
<!ENTITY asymp "≈" ><!-- almost equal to = asymptotic to,
U+2248 ISOamsr -->
<!ENTITY ne "≠" ><!-- not equal to, U+2260 ISOtech -->
<!ENTITY equiv "≡" ><!-- identical to, U+2261 ISOtech -->
<!ENTITY le "≤" ><!-- less-than or equal to, U+2264 ISOtech -->
<!ENTITY ge "≥" ><!-- greater-than or equal to,
U+2265 ISOtech -->
<!ENTITY sub "⊂" ><!-- subset of, U+2282 ISOtech -->
<!ENTITY sup "⊃" ><!-- superset of, U+2283 ISOtech -->
<!-- note that nsup, 'not a superset of, U+2283' is not covered by the Symbol
font encoding and is not included. Should it be, for symmetry?
It is in ISOamsn -->
<!ENTITY nsub "⊄" ><!-- not a subset of, U+2284 ISOamsn -->
<!ENTITY sube "⊆" ><!-- subset of or equal to, U+2286 ISOtech -->
<!ENTITY supe "⊇" ><!-- superset of or equal to,
U+2287 ISOtech -->
<!ENTITY oplus "⊕" ><!-- circled plus = direct sum,
U+2295 ISOamsb -->
<!ENTITY otimes "⊗" ><!-- circled times = vector product,
U+2297 ISOamsb -->
<!ENTITY perp "⊥" ><!-- up tack = orthogonal to = perpendicular,
U+22A5 ISOtech -->
<!ENTITY sdot "⋅" ><!-- dot operator, U+22C5 ISOamsb -->
<!-- dot operator is NOT the same character as U+00B7 middle dot -->
<!-- Miscellaneous Technical -->
<!ENTITY lceil "⌈" ><!-- left ceiling = apl upstile,
U+2308 ISOamsc -->
<!ENTITY rceil "⌉" ><!-- right ceiling, U+2309 ISOamsc -->
<!ENTITY lfloor "⌊" ><!-- left floor = apl downstile,
U+230A ISOamsc -->
<!ENTITY rfloor "⌋" ><!-- right floor, U+230B ISOamsc -->
<!ENTITY lang "〈" ><!-- left-pointing angle bracket = bra,
U+2329 ISOtech -->
<!-- lang is NOT the same character as U+003C 'less than'
or U+2039 'single left-pointing angle quotation mark' -->
<!ENTITY rang "〉" ><!-- right-pointing angle bracket = ket,
U+232A ISOtech -->
<!-- rang is NOT the same character as U+003E 'greater than'
or U+203A 'single right-pointing angle quotation mark' -->
<!-- Geometric Shapes -->
<!ENTITY loz "◊" ><!-- lozenge, U+25CA ISOpub -->
<!-- Miscellaneous Symbols -->
<!ENTITY spades "♠" ><!-- black spade suit, U+2660 ISOpub -->
<!-- black here seems to mean filled as opposed to hollow -->
<!ENTITY clubs "♣" ><!-- black club suit = shamrock,
U+2663 ISOpub -->
<!ENTITY hearts "♥" ><!-- black heart suit = valentine,
U+2665 ISOpub -->
<!ENTITY diams "♦" ><!-- black diamond suit, U+2666 ISOpub -->
Version 1.0.1: