Sustainability of Digital Formats: Planning for Library of Congress Collections
Sustainability of Digital Formats: Planning for Library of Congress Collections |
|
|
|
| Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact | |
| Full name | Microsoft XML Paper Specification, (XPS) |
|---|---|
| Description |
The XPS (XML Paper Specification) format, developed by Microsoft, serves as a fixed-page document format, a spool file format, and a page description language (PDL) for printers. The XPS format was designed as a "paginated representation of electronic paper that is based on XML," developed to be an important component of printer support in Windows Vista (released for distribution in January 2007) but also to be a platform-independent format that could be viewed and printed without the application used to create it. In September 2007, Microsoft submitted a re-organized version of its XPS specification to Ecma International for approval as an international standard. See XML Paper Specification: Working draft 1.0.1. After a few further modifications, ECMA-388: Open XML Paper Specification (OpenXPS) was published in June 2009. See OpenXPS. The XPS document format represents a set of related pages with fixed layout, which are organized as one or more documents to be printed together. A file in this format must include everything necessary to fully render its content on a display device or physical medium (for example, paper). This includes all resources such as fonts and images that might be required to render individual pages. See Notes below for details of the formats permitted for such embedded resources. To implement the fixed layout of a page, the location of every visual element on the page is precisely sized and positioned. The format offers no capability to adjust layout or reflow text content. The XML markup used in XPS bears little relationship to the markup used in XML-based word-processing formats such as DOCX/OOXML or ODF_text (.odt) or in XML-based publication formats such as JATS or EPUB, all of which represent the logical structure of a document, for example, identifying headings and paragraphs. The XPS format simply identifies runs of characters in the same font, size, and weight and locates the starting point for each run and the relative position for each character/glyph in the run. Each page has a corresponding FixedPage "part," which describes all of the visual elements to be rendered on the page. A page has a fixed size and orientation, defined by height and width attributes that specify the rectangular print area. The position of every visual element on a page is determined by co-ordinates relative to the origin (typically the top left corner) of that fixed rectangle. Markup in the FixedPage part employs Glyphs elements for runs of text and Path and Brush elements for vector graphics. A Canvas element can be used to group Glyphs and Path elements into a structure that can treated as a unit. Raster images and fonts are stored as individual parts (in specified widely supported formats) and can be referred to by many pages in the same document. An annotated example of XPS markup for a fixed page follows. This is based on the sample page used in the MSDN Magazine article A First Look at APIs For Creating XML Paper Specification Documents from January 2006: <FixedPage Width="800" Height="500"> The logical form of an XPS document is a hierarchy of "parts" in an Open Packaging Conventions (OPC) package, using Version 6.2.0 of the ZIP format as physical container. The normative reference in the XPS specification for OPC is to ECMA-376, Edition 1: Part 2, Open Packaging Conventions (December 2006), but an XPS file will also conform to the successor OPC/OOXML as described on this website. The parts in an XPS file represent a fixed payload, which has at its root a FixedDocumentSequence part, allowing one or more documents to be stored in the same XPS package, each in a FixedDocument part. A FixedDocument part is an easily indexed root for all pages within the document, identifying a sequence of FixedPage parts and an optional DocumentStructure part (which can support an outline, table of contents, and internal links). In addition to the markup illustrated above, a FixedPage part can also incorporate chunks of text and graphics stored in a separate StoryFragments part. The hierarchy of parts is shown in one form as Figure 1: Logical Hierarchy of an XPS Document, a diagram in A First Look at APIs For Creating XML Paper Specification Documents. Figure 2 on page 10 of the Ecma OpenXPS Whitepaper (TC46) shows a more complete set of possible parts in the package for an XPS document. In the OPC package, the relationships between parts are defined through links from source parts to named target parts using a URI syntax for the names. There are no constraints in the XPS specification or schemas on the naming of parts beyond those relating to characters allowed by the OPC specification. However, the section 2.2 Part Naming Recommendations in the XPS specification recommends a well-defined, human-readable naming convention for parts, so that the package is easier to browse when unzipped and specific parts are more easily located. Following this convention, the parts in an example XPS file containing two documents might be named as follows: /FixedDocSeq.fdseq
The compilers of this resource have made no attempt to determine the degree to which this naming convention is followed when XPS files are created in contexts other than Microsoft Windows or whether viewers for XPS documents can handle files in which this naming convention is not followed. Comments welcome. Note that parts with "_PT" in their names in the example above are associated with "print tickets" that are optional instructions for printing. The XPS specification incorporates a Print Schema that specifies markup for PrintTicket parts and specifies how such parts should be associated with FixedDocumentSequence, FixedDocument, and FixedPage parts. |
| Production phase | Microsoft's XPS format was designed as a final-state format, for printing and distribution to end users for viewing. |
| Relationship to other formats | |
| Subtype of | XPS is a subtype of ECMA-376, Edition 1: Part 2, Open Packaging Conventions (December 2006), which is a predecessor to OPC/OOXML as described on this website. Edition 1 of ECMA-376 has not been described separately on this website. See Notes below for information on the version of OPC that is the basis for MS-XPS and minor differences between that version and OPC/OOXML_2012. |
| Subtype of | ZIP_6_2_0, ZIP File Format, Version 6.2.0 (PKWARE). Various features of the ZIP File Format are not permitted in OPC and thus not in XPS. Details on the use of ZIP in OPC are in section 9 and Annex C of ECMA-376, Edition 1: Part 2, Open Packaging Conventions. |
| May contain | MCE/OOXML_2012, Markup Compatibility and Extensibility (Office Open XML). Formally, an XPS document may employ markup from the Markup Compatibility and Extensibility (MCE) schema defined in ECMA-376 1st edition Part 5 (December 2006). Edition 1 of ECMA-376 has not been described separately on this website. Between 2006 and 2015, there was no change in the MCE format significant to the XPS format. All editions of ECMA-376 and ISO/IEC 29500-3 through 2015 use the same namespace for MCE: http://schemas.openxmlformats.org/markup-compatibility/2006. |
| Has later version | OpenXPS, Open XML Paper Specification, ECMA-388 (.oxps) |
| LC experience or existing holdings | The Library of Congress has acquired a small number of files with the .xps extension, probably through web crawling. In early 2020, ~200 files had been stored among its digital collections. |
|---|---|
| LC preference | See the Library of Congress Recommended Formats Statement for format preferences for textual works and still image works. |
| Disclosure | The XPS format specification is proprietary to Microsoft, but made available under royalty-free copyright and patent licenses and was openly published starting in 2005, when Microsoft made a preliminary specification available to developers under the codename Metro. See, for example, Printing - Architecture and Driver Support (from October 2005) from Microsoft's Windows Hardware and Driver Central (WHDC). |
|---|---|
| Documentation |
Version 1.0 of the XPS specification was available via the following web pages between 2006 and 2014
All the links above led to the same download file: http://download.microsoft.com/download/1/6/a/16acc601-1b7a-42ad-8d4e-4f0aa156ec3e/XPS_1_0.exe, which runs to produce a copy of the XPS specification in the .xps format. The compilers of this resource have not located any updated Microsoft specification for XPS. Comments welcome. Microsoft XML Paper Specification Essentials Pack Version 1.2 (12/2/2012) includes tools for developers. |
| Adoption |
Windows Vista, Microsoft Office 2007, and .NET Framework 3.0 all employed XPS and were released together in January 2007. Microsoft included a free XPS Viewer in Windows Vista and provided viewers and other tools to support the format's use in Windows 2000, Windows XP (released in 2001) and Windows Server 2003. Support for creating XPS documents in Windows has continued in later versions of Windows. For example, Word 2016 for Windows offers the option to Save As an XPS (.xps) file. Some companies producing software for the commercial printing industry worked closely with Microsoft in the development of XPS technology. These included Global Graphics and Software Imaging; see Global Graphics and Software Imaging announce compatibility across print solutions for Microsoft's XPS document format from January 2006. Many printer manufacturers developed XPS drivers or integrated Microsoft's driver into their products. Mentioned in Metro Document Technologies Fact Sheet from April 25, 2005 are vendors developing or evaluating early versions of XPS-based products, including Xerox, Brother Information and Document Co., Canon Inc., HP, Monotype Imaging Inc., Peerless Systems Corp., Ricoh Company Ltd., Seiko Epson Corp., and Zoran Corp. All the mainstream printer manufacturers began to support use of XPS. The expectations for XPS as a fixed-layout document format for sharing with end users was less successful. Support for the XPS format was never integrated into Apple's operating systems. For Mac OS X 10.0, released in March 2001, Apple had chosen to develop its own code associated with PDF (based on PDF version 1.3 which was documented by Adobe in July 2000) and to support creation of PDF files from any application. Apple chose this version of PDF as its basis for using the same imaging model and language to describe layout and graphics on the screen and for printers. See PDF Document Creation, Viewing, and Transforming in the Quartz 2D Programming Guide and the description of the Core Graphics framework for Mac OS X and iOS. The Core Graphics framework is based on Quartz 2D, a two-dimensional drawing engine accessible in the iOS environment and from all Mac OS X application environments since 2001. Mac OS X came with the Preview application, which was a PDF Viewer, and users could print to PDF. See Mac OS X and PDF: The Real Story by Leonard Rosenthol. Although XPS viewers were developed for Mac OS X by third parties, there was little reason for Mac users to acquire them. As a result, PDF continued as the de facto standard for sharing documents for viewing and review in contexts where it was important to reach a wide audience. The compilers of this resource have not investigated the degree to which XPS may have been used for archiving documents for internal use in corporate settings. Comments welcome. A number of tools have been developed for viewing and converting XPS documents. See Useful References below. In 2018, support for OpenXPS and XPS was dropped in some contexts where the formats were supported previously. Features and functionality removed in Windows 10 indicates that starting with the April 2018 release, the XPS Viewer utility would require special action for installation in Windows. Adobe's Acrobat Pro (for Windows) used to import XPS files, but has withdrawn default support. As of early 2020, an Adobe help file, entitled Unable to convert XPS files to PDFs, states that "With December 2018 release of Acrobat, converting XPS files to PDFs is disabled" and that support can be re-enabled using the Windows Registry Editor. It appears to the compilers of this resource that the availability of well-supported tools for viewing XPS files in the future cannot be guaranteed. Comments welcome. |
| Licensing and patents |
By early 2006, Microsoft offered a royalty-free copyright license to copy and distribute the XPS specification and a royalty-free patent license to implement and use XPS technology. See XML Paper Specification Licensing Overview (from 2006) and XML Paper Specification Licensing Overview (as online in early 2020). |
| Transparency |
Very good. At the container level, transparency corresponds to that of ZIP_PK. Many tools exist to permit browsing and extraction of the files contained in ZIP archives. The parts/files that represent the structure of an OPC package and the XPS document text, layout, and vector graphics are all in XML and thus both human readable and easily machine processable. Transparency also depends on non-XML resources that can be embedded, including fonts and raster images in widely used formats. See Notes below on formats allowed for embedded resources. Embedded fonts may be obfuscated. Embedded font obfuscation is a means of preventing casual misappropriation of embedded fonts. It is not considered a strong encryption of the font data. An algorithm is provided in the specification for reversing the obfuscation. |
| Self-documentation | Document-level descriptive metadata is optional. An XPS document may contain the OPC part with the name Core Properties. This part has fifteen elements, all optional and all non-repeatable. Six are selected from the main Dublin Core Metadata Initiative (DCMI) set (title; creator; description; subject; identifier; language) and two from the supplementary dcterms vocabulary (created; modified). Compilers of this resource have used Word 2016 to Save As an XPS file. This created an XPS file with a Core Properties part with values derived from properties of the source DOCX file. Comments welcome. |
| External dependencies | All content to be rendered must be contained in the XPS Document, including images and fonts. The payload of an XPS file includes the full set of parts required for processing the file starting at the root FixedDocumentSequence part. |
| Technical protection considerations | The XPS specification does not have internal support for encryption, or other forms of content protection, other than obfuscation of embedded fonts, which is required for fonts that are not freely licensed. An algorithm is provided in the specification for reversing the obfuscation. |
| Still Image | |
|---|---|
| Normal rendering | An XPS file may consist of a single image or have images positioned on fixed pages. Formats permitted are: JPEG in JFIF or EXIF containers; PNG; TIFF (compressed and uncompressed); and Windows Media Photo (WMP), later known as HD Photo and JPEG XR. See specific formats for additional detail on image quality factors. |
| Clarity (high image resolution) | High-quality color for printing, including the printing of photographs, was an important objective for XPS. Excellent support for high spatial resolution and high bit-depth for colors, depending on the image format used. See XPS and Color Printing Enhancements in Windows Vista (September 2005). |
| Color maintenance | XPS producers and consumers must support sRGB, scRGB, and CMYK color data and provide color management using ICC Version 2.1.0 profiles. See ICC Profile Format Specification, Version 3.4 (August 15, 1997), which is a normative reference for the XPS 1.0 specification. |
| Support for vector graphics, including graphic effects and typography | XPS has rich support for 2D vector graphics, using markup defined in the XPS specification, which is compatible with the markup used for graphics to be rendered on the screen in the Windows Presentation Foundation, also introduced with Windows Vista. Drawing operations supported include line, horizontal line, vertical line, cubic Bézier curve, quadratic Bézier curve, smooth cubic Bézier curve, and elliptical arc. A region can be filled with a solid color, a raster image, a drawing, or color gradients (linear or radial). |
| Text | |
| Normal rendering |
The XPS format is not designed to support wordprocessing or document design. The expectation is that an XPS file will be created by an automated process to produce a document with fixed pagination and layout. For example, Windows Vista offered a virtual printer, Microsoft XPS Document Writer, which created a file in the XPS format. Although not intended as a word-processing format, the XPS format was designed to support convenient full text indexing and text selection and extraction. Textual data is represented internally as Unicode strings. [Note: There is no reason why an XPS file should not be composed of page images, for example, images output by a scanner. However, the compilers of this resource have not attempted to determine whether this is common practice. Comments welcome.] A Unicode value in a UnicodeString is typically represented by a single UTF-16 code unit and has a single corresponding glyph representation in a font. A mapping mechanism is available to support more complex situations, such as those required for ligatures and in many non-Latin scripts. |
| Integrity of document structure | An XPS document does not represent the structure of a document with tags representing the logical/semantic structure. The format does support named anchors for pages or for locations on pages. These can be used by the software creating the file to assemble a table of contents or internal links within the document that matches the functionality of a source word-processing document. The degree to which the XPS file will represent the creator's intent for document structure will depend on the capabilities of the software (e.g., a virtual printer) that transforms the document in the format for the software used by the creator into the XPS format. |
| Integrity of layout and display |
The XPS format is designed to represent a page-oriented document with fixed layout. The degree to which the XPS file will represent the creator's intent for layout will depend on the capabilities of the software (e.g., a virtual printer) that transforms the document in the format for the software used by the creator into the XPS format. XPS requires that fonts be embedded, in order to avoid the need for font substitution, which can interfere with layout integrity when the correct font is not available. XPS took advantage of recent developments in font formats, by requiring use of the latest OpenType Font Format, from OpenType Specification, Version 1.4 (2004). This version of OpenType was a Microsoft specification, but incorporated TrueType (developed by Apple) and was based on collaboration with Adobe. This version of OpenType had been adopted by MPEG by reference and submitted in August 2005 by Microsoft and Adobe for formal approval by ISO as an international standard. The next version of OpenType was published as ISO/IEC 14496-22: 2007. |
| Support for mathematics, formulae, etc. | Can be represented visually by embedded graphics. |
| Functionality beyond normal rendering | The XPS specification provides recommendations for creating documents that address accessibility requirements and also provides guidance for screen readers. |
| Tag | Value | Note |
|---|---|---|
| Filename extension | xps |
See IANA registration for XPS from 2006. |
| Internet Media Type | application/vnd.ms-xpsdocument |
See IANA registration for XPS from 2006. |
| Magic numbers | Hex: 50 4B 03 04 ASCII: P K etx eot |
This 4-byte magic number applies to all formats based on the ZIP-PK format. |
| XML namespace declaration | http://schemas.microsoft.com/xps/2005/06 |
This namespace declaration occurs in the mandatory FixedDocumentSequence part that serves as the root of the content in a Microsoft XPS file (package). In the specification, the extension fdseq is recommended but not mandated for this part. |
| Other | Type="http://schemas.microsoft.com/xps/2005/06/fixedrepresentation" |
This type declaration will occur in the top-level Relationships part (\_rels\.rels) in the OPC package representing a Microsoft XPS document, as an attribute of a <Relationship> element within the <Relationships> element. In a document that follows the naming scheme recommended in the specification, the target of this relationship will have the extension fdseq. |
| Pronom PUID | See note. | PRONOM does not include an entry for Microsoft's XPS format. |
| Wikidata Title ID | Q977900 |
See https://www.wikidata.org/wiki/Q977900 which covers XPS and OpenXPS. |
| General |
XPS enhancements for color printing and graphics in Windows Vista: XPS was designed to address increasing demand for color laser printing and color fidelity and increasing use of advanced graphics and color in documents. XPS introduced 16-bits-per-channel color printing, twice the existing standard at the time, and integrated support for the wide color gamut scRGB color space. XPS printing provided more faithful rendering of graphics attributes such as gradients and transparency though native support of these attributes in the XPS spool file format. For vector graphics, XPS specifies markup for graphics primitives compatible with the Windows Presentation Foundation markup introduced for screen display in Windows Vista (e.g., Path, Brush, and Glyphs). Version of OPC on which OpenXPS is based: OpenXPS and Microsoft's XPS formats are subtypes of the Open Packaging Conventions (OPC) as specified in ECMA-376, Part 2, 1st edition (December 2006). The only significant difference between this and later versions of OPC, including ISO/IEC 29500-2 versions through OPC/OOXML_2012, is an expansion of characters permitted in names for parts in a package. In contrast to ECMA-376, Part 2, 1st edition, later editions permit part names in the package to be IRIs (Internationalized Resource Identifiers) as defined in RFC 3987, not simply URIs as defined in RFC 3986. Since this was an extension to OPC rather than a restriction, XPS files are also subtypes of OPC/OOXML_2012. [Note: Editions of OPC published since 2008 as ISO/IEC 29500-2 and ECMA-376 Part 2 describe the same format, with textual changes representing corrections and clarifications. The same namespaces and package-wide relationships defined in ECMA-376 Part 2 are valid in ISO/IEC 29500-2: 2012, the most recent published version of this part of ISO/IEC 29500 as of late 2019.] Formats allowed for embedded resources: The raster image formats that can be embedded in an XPS document were selected for their wide support: JPEG in JFIF or EXIF containers; PNG; TIFF (compressed and uncompressed); and Windows Media Photo (WMP), later known as HD Photo and JPEG XR. Fonts are stored in font parts. All fonts used in XPS documents must adhere to the OpenType font format. As normative references, the XPS specification cites version 1.4 of Microsoft's OpenType Specification and Microsoft's OpenType Font File specification from 2001. The OpenType specification incorporates TrueType and CFF font formats. To support portability, Unicode-encoded fonts are recommended. Fonts may be subsetted based on usage in the document. Although a subsetted font does not contain all the glyphs in the original font, it must be a valid OpenType font file according to the specifications listed above. Fonts that may not be legally embedded may be obfuscated as a means of preventing casual misappropriation of embedded fonts. The specification specifies a method for obfuscation and recommends that the extension of an obfuscated Font part name be “.odttf” for TrueType fonts and “.odttc” for TrueType collections. |
|---|---|
| History |
XPS was deployed for public use in January 2007 as part of Windows Vista. Many of the components of Vista had been made available to developers, using the codename Longhorn, over the previous few years. At the Windows Hardware Engineering Conference (WinHEC) in May 2004, Microsoft introduced the "Longhorn NextGen Printing Architecture." See Printing - Architecture and Driver Support from WHDC in June 2004. By early 2005 the printing architecture was known as Metro and a preliminary specification (version 0.7) was available for the document format specification. By October 2005, Metro had been renamed as XPS (XML Paper Specification). Microsoft encouraged the use of XPS by others, making a preliminary specification for XPS available under the codename Metro (as version 0.7) for download by developers in May 2005. Metro Document Technologies: Fact Sheet (April 25, 2005) indicated that Microsoft planned to offer a royalty-free license for Metro when the specification and documentation were final. By October 2005, version 0.75 of the specification was available under a royalty-free license. The XPS page as of December 2006 made version 1.0 of the specification available. This openness was in keeping with a general move by Microsoft at the time towards platform-independent interoperability for its most widely used products. For example, in December 2005, a Technical Committee of the Ecma International standards organization (TC45) was established to review documentation for the proposed Office Open XML (OOXML) specification submitted by Microsoft. OOXML was approved as an international standard (ECMA-376, 1st edition) in December 2006. The container format used by XPS is the Open Packaging Conventions (OPC) format, published as Part 2 of ECMA 376, 1st edition. Windows Vista included a redesigned print architecture, built around Windows Presentation Foundation (WPF). See WPF: Printing Overview. Through the use of XPS, the new print architecture provided high-fidelity color printing through improved use of color management, removed limitations of the previous print subsystem, and added support for printing advanced effects such as gradients, transparency layers, etc. The print subsystem in Windows Vista implemented a new print path based on XPS. The XPS Print Path used XPS files as the print spooler format and implemented high quality 16-bit color printing. Applications using WPF for the user interface display (which included Office 2007 applications) could print directly to the XPS print path without the need for image or colorspace conversion. The Microsoft XPS Document Writer was introduced as a "print-to-file converter" (a virtual printer) that allowed users to create XPS Document files. When Microsoft announced the Metro format in April 2005, as pointed out in Microsoft gunning for Adobe's PDF format? from C|Net, some analysts were quick to see the format as intended to be a "PDF killer." However, unlike PDF, Microsoft was not trying to create a multimedia format or a format that allowed users to fill in a form. It was trying to address increased expectations of efficiency, quality, and fidelity associated with printing by (a) using the same methodology and compatible markup for sending data to a printer that it uses for displaying data on screen and (b) using the same format for spooling to the printer as for the viewable document. For more on these topics and informal introductions to the format, see A First Look at APIs For Creating XML Paper Specification Documents from MSDN Magazine (January 2006), a video interview about XPS with Jerry Dunietz from August 2005 and Document Workflow Advances in Windows Vista (January 2006). When XPS was released for public use with Windows Vista in January 2007, it was also the basis for printer support in .NET Framework 3.0 and Microsoft Office 2007. See the May 2007 Intro from a Microsoft blog on XPS et cetera. In September 2007, Microsoft submitted a version of the XPS specification to Ecma International as an initial draft for a neutral international standard. This version and several intermediate drafts are available at TC46 - Open XML Paper Specification (OpenXPS): Documents. The OpenXPS standard, ECMA-388, was officially adopted by the Ecma General Assembly in June 2009. |
|
|
