XPS v0.85 Coming Changes – Part II

So we’ve finalized the content for v0.85 of both XPS and the Open Packaging Conventions. We’re working on the publication process now. In the meanwhile, here’s the delta of XPS changes since the previous post…

Chapter 2. Parts and Relationships

  • Added a RECOMMENDATION to avoid using JPEG for CMYK images, but rather use TIFF or Windows Media Photo CMYK images (
  • Added description of ancillary PNG chunks that are supported in XPS Documents (
  • Added details for grayscale TIFF image tags (
  • Added Compression tag value 5 for bilevel, palette-color, RGB, and CMYK images. Added Compression tag value 6 for RGB and CMYK images (
  • Added BitsPerSample tag values of 1 and 4 for palette-color images (
  • Expanded details of supported TIFF features, specifically all of baseline TIFF with the exception of tags CellLength, CellWidth, GrayResponseCurve, GrayResponseUnit, MaxSampleValue, MinSampleValue, Orientation, and Thresholding; CCIT bilevel encodings; details of associated alpha data; details of JPEG compression; and ICC profiles (
  • Added a note about the diversity of TIFF images in circulation and recommendations for handling and correcting common errors in TIFF images (
  • Added recommendation on handling the default color space of Windows Media Photo images (
  • Clarified that XPS Document consumers SHOULD process thumbnails attached to the package root or to a FixedPage part, even though the Open Packaging Conventions indicates that thumbnails MAY be attached to any part (2.1.6).
  • Added cross-reference to help clarify the meaning of “Unicode-encoded fonts” (5.1.7).
  • Clarified that consumers MUST display XPS Documents containing any combination of font embedding and obfuscation, even if the XPS Document does not conform to the guidelines for a properly obfuscated and embedded font (
  • Clarified the exact algorithm for obfuscating and de-obfuscating fonts to address confusion around Endian byte-encoding (
  • Clarified that editing consumers to check Print and Preview font flags and presence of Restricted Font relationships refers to when editing functionality is invoked. Clarified that printing and display-only consumers MUST treat XPS Documents as valid, regardless of whether the producer correctly set the Restricted Font relationship (
  • Added details on cmap table selection order for purposes of processing the UnicodeString property and clarified consumer responsibility for converting to the appropriate cmap codepoint encoding prior to lookup (
  • Added requirement: “The XML 1.0 specification allows for the usage of Data Type Definitions (DTDs), which enable Denial of Service attacks, typically through the use of an internal entity expansion technique. As mitigation for this potential threat, DTD content MUST NOT be used in the XML markup defined in this specification, and consumers MUST treat the presence of DTD content as an error.” (2.3.2)
  • Added requirement: “If the XML content contains the Markup Compatibility namespace, as described in the Markup Compatibility specification, it MUST be processed to remove Markup Compatibility elements and attributes and ignorable namespaces before applying further validation rules.” (2.3.2)
  • Added requirement: “XML content MUST be valid against the corresponding XSD schema defined in this specification. In particular, the XML content MUST NOT contain namespaces that are not explicitly defined in the corresponding XSD unless the XSD allows any namespace to be present in particular locations in the XML markup.” (2.3.2)
  • Added requirement: “XML content MUST NOT contain “xml” or “xsi” namespaces unless they are explicitly defined in the XSD schema or by other means in the specification.” (2.3.2)

Chapter 3. Documents

  • Clarified that the RenderOptions.EdgeMode property applies to all contents, including brushes, brush contents, and content included via resource dictionary references (3.4).

Chapter 5. Text

  • Corrected requirement to produce an error if both the UnicodeString and Indices attributes are empty or not specified (5.1).
  • Cleaned up ABNF description of the Indices attribute to match XSD (5.1.3).
  • Added the requirement: “The Indices attribute MUST NOT contain more GlyphMapping entries than there are UTF-16 code units in the UnicodeString attribute.” (5.1.3)
  • Added the requirement: “If the Indices attribute specifies a GlyphIndex that does not exist in the font, the consumer MUST generate an error.” (5.1.3)
  • Changed the recommendations around Unicode control marks in the UnicodeString attribute. Producers MAY include these control marks. Producers SHOULD provide an Indices attribute to specify glyph indices and/or character-to-glyph mapping information. In the absence of this information, consumers treat Unicode control marks like ordinary characters, which might produce an inappropriate rendering of the UnicodeString value (5.1.4).
  • Added the requirement: “If the UnicodeString attribute contains a Unicode code unit that cannot be mapped to a glyph index via a cmap table in the font and there is no corresponding GlyphIndex entry in the Indices attribute, the consumer MUST display the .notdef glyph.” (5.1.4)
  • Clarified that device manufacturers define the values for the DeviceFontName attribute and removed open issue (5.1.7).
  • Recommended that producers SHOULD NOT produce markup that will result in different rendering between consumers using the embedded font to render and consumers using the device font to render (5.1.7)
  • Clarified that, if the Indices attribute includes a cluster mapping the consumer MUST NOT use the device font and MUST render the embedded version of the font (5.1.7).

Chapter 8. Color

  • Removed restriction on gray color space raster images; these may be specified using any supported raster image format (8.1.3).
  • Clarified that ICC profiles in raster images SHOULD be used, when present; although scRGB images still conform to the scRGB gamut definition (8.1.8).
  • Added the following note: “Some consumers do not correctly apply ICC profiles to grayscale images. If consistency of appearance is important, the producer SHOULD adjust the gray tone response curve of the image before adding it to the XPS Document.” (8.1.8)
  • Added requirement that ICC profiles must be Input, Output, or Monitor (RGB) profiles (8.1.8).
  • WcsProfilesTag signature changed to ‘MS00’ (8.1.8, 8.1.9).
  • Updated the WcsProfilesTagType structure to match the latest tag design (8.1.9).
  • Clarified that N-Channel syntax refers to channels 0 through N-1 (8.1.11, 8.1.15).
  • Added clarification on alpha values: “Although alpha values smaller than 0.0 and larger than 1.0 can be specified, they MUST be clamped to the valid range from 0.0 to 1.0 before any further processing.” (8.1.13, 8.1.14, 8.1.15, 8.1.16)
  • Added TIFF and JPEG to supported grayscale formats for raster images (8.2.3).
  • Added new section “Color Space Pixel Formats for Raster Images” describing the default pixel formats used by each color space (8.2.9).
  • Added handling requirements regarding the DocumentImpositionColor PrintTicket setting for color separations: “The color name specified by the DocumentImpositionColor PrintTicket setting MUST be matched only to profiles containing exactly one non-zero-length colorant name in the profile’s colorantTable. The color name specified by the DocumentImpositionColor setting serves as a label for that color only and MUST NOT be matched against any Named Colors known by the consumer. The comparison of the color name specified by the DocumentImpositionColor PrintTicket setting with the colorant name in the profile’s colorantTable MUST be performed as a case-sensitive ASCII comparison after trimming leading and trailing whitespace from each string.” (8.3)
  • Removed description of TIFF CMYK tags, as this duplicated the information already in (
  • Added section on JPEG CMYK raster images, to detail that they SHOULD NOT be used (

Chapter 9. Document Structure and Interactivity

  • Softened MUST requirement to SHOULD for consumers to merge content structure across fragment boundaries, thereby allowing for implementations with enforced content structure breaks at page boundaries (9.1.2).

Chapter 10. Package-Wide Features

  • Removed duplicative information on interleaving of the Content Types stream and simply referred to the Open Packaging Conventions specification (10.1).
  • Added the following clarifications to DiscardControl part usage: “DiscardControl parts that are not well-formed SHOULD NOT be processed and an error SHOULD NOT be reported. The consumer MAY decide to ignore the malformed DiscardControl part in its entirety or from the first malformed node onward.” (
  • Added new sub-sections illustrating the DiscardControl elements (,
  • Added the following clarification on the <Discard> element: “If either the Target attribute or the SentinelPage attribute contain an invalid reference (refer outside the package), the respective <Discard> element MUST be ignored. If a <Discard> element is encountered where either or both of the Target attribute and SentinelPage attribute identify a part which has not been processed yet (is still unknown), the <Discard> element SHOULD be retained until both parts identified by the Target attribute and SentinelPage attribute have been processed or until the end of the package is reached.” (
  • Updated the various tables for SignatureDefinition elements to use the standard table style for other XML elements throughout the specification (10.2.2,
  • Added xml:lang as an optional attribute for the <SignatureDefinition> element (
  • Added requirement that the <SignBy> date and time MUST be specified as a complete date and time (hours, minutes, and seconds) in UTC format, per the W3C Note on “Date and Time Formats” (

Chapter 11. Rendering Rules

  • Added further discussion of the rendering implications of the Note for blending colors on certain radial gradients and provided a RECOMMENDED behavior for producers to avoid producing these gradients (
  • Removed negative integers N from consideration when rendering radial gradients, i.e. gradients with a GradientOrigin outside the defined Ellipse; this area is treated identically with that outside the shape defined by all combinations of N (now non-negative) and t (11.3.3).
  • Clarified that the color used for drawing areas outside the boundary of the radial gradient are the color/alpha defined in Offset 0.0 for SpreadMethod Reflect and Offset 1.0 for SpreadMethod Repeat or Pad (11.3.3).
  • Added new section “Pre-Multiplied Alpha and Superluminous Colors” and updated 11.4 “Opacity Computations” in accordance with this text (11.4.1).
  • Clarified the color value of transparent surfaces for purposes of composition and blending (11.5).
  • Softened the requirement to SHOULD for avoiding degenerate line segments in computations: “If the current render transform is an invertible matrix, consumers SHOULD perform computations on poly line segments and poly Bézier segments with sufficient accuracy to avoid producing zero-length segments.” (11.6.8).

Chapter 12. Elements

  • Updated all elements affected by changes described in chapters 1-11.
  • Added digital signature element tables.
  • Added discard control element tables.

Appendix A. Glossary

  • Added glossary entries for compliant digital signature, incompliant digital signature, valid digital signature, broken digital signature, questionable digital signature, and signing rules.

Appendix B. Signature Definitions Schema

  • Flagged SpotID attribute of <SignatureDefinition> element as required.

Appendix I. Standard Namespaces and Content Types

  • Added the following conformance requirement: “The content types in the tables below MUST NOT include parameters. A consumer MUST treat the presence of parameters on these content types when the affected part is accessed.” (I.2)

Appendix J. Conformance Requirements

  • Clarified validity rules with regard to languages for which the page reading order is back-to-front (reversed from Western language page reading order); this was in chapter 2.

Comments (5)

  1. yao says:

    CtrlView is a fast, compact, powerful viewer/converter for different 2D/3D raster/vector file formats with the format recognition system.

    It means that CtrlView analyses content of the file and determines its format. If file format is among supported file types, CtrlView will visualize this file in a correct form. If file type is unknown for CtrlView, it will be visualized in ASCII file form or in binary file form. Any file also can be opened manually as ASCII or binary so you have an ability to look inside the file at any time.


  2. Dating says:

    So we’ve finalized the content for v0.85 of both XPS and the Open Packaging Conventions. We’re working on the publication process now. In the meanwhile, here’s the delta of XPS changes since the previous post… Chapter 2. Parts and Relationships Adde

  3. Weddings says:

    So we’ve finalized the content for v0.85 of both XPS and the Open Packaging Conventions. We’re working on the publication process now. In the meanwhile, here’s the delta of XPS changes since the previous post… Chapter 2. Parts and Relationships Adde