Bug#1133966: papers: Please reintroduce XPS viewing support (regression from Evince)

[Albert Nash]

Package: papers
Version: 48.3-1
Severity: wishlist
Tags: upstream

Background

With the transition from Evince to Papers in Debian Trixie/Forky, support for opening XPS (XML Paper Specification) documents has been removed. Attempting to open .xps files now results in an “unsupported file type” error.

This is a clear regression: Evince in previous Debian releases supported XPS reliably via libgxps. Users upgrading their systems lose the ability to open documents that previously worked out of the box.

XPS was the default print-to-file format on Windows Vista, 7, 8, and early Windows 10 systems via the Microsoft XPS Document Writer. As a result, a substantial corpus of real-world documents exists in XPS format, including financial records, administrative documents, invoices, and archived correspondence. These documents remain in active use.

Arguments for reintroduction

1. User-visible regression in a core application
Papers replaces Evince as the default GNOME document viewer in Debian, yet it no longer supports a format that Evince handled transparently. This breaks existing user workflows and violates expectations of continuity across upgrades.

2. Continued real-world relevance of XPS
XPS is not merely a legacy curiosity. It was widely deployed as a default system component on Windows for over a decade. Many users still maintain archives created through “Print to XPS”. These files are part of long-term records and must remain accessible without requiring additional tools.

3. Minimal implementation and maintenance cost
XPS rendering is handled by libgxps (already packaged in Debian as libgxps2t64). The format is standardized (ECMA-388) and effectively frozen. Reintroducing support primarily involves reconnecting an existing, mature backend. The long-term maintenance burden is negligible compared to supporting evolving formats.

4. Debian interoperability expectations
Other viewers in Debian (e.g., Okular, Atril, MuPDF) continue to support XPS. The default GNOME viewer lacking this capability creates unnecessary fragmentation and forces users to install alternative applications for a previously supported format.

5. Conversion to PDF is not a reliable substitute
XPS to PDF conversion is not guaranteed to be lossless. Depending on the document and the converter used, it may:
• rasterize vector content
• substitute or incorrectly embed fonts
• alter transparency or compositing
• degrade document structure or text semantics
Some XPS features do not map exactly to PDF, so differences in rendering are unavoidable in certain cases. Native viewing support is therefore required for faithful access to existing documents.

6. Availability of comprehensive test material
Well-structured test files are readily available, including real-world output from Microsoft’s XPS printer:
  • Microsoft sample set:
    https://github.com/HiraokaHyperTools/SampleXpsDocuments_1_0
    (archived original: http://web.archive.org/web/20100911214740/http://download.microsoft.com/download/1/6/a/16acc601-1b7a-42ad-8d4e-4f0aa156ec3e/SampleXpsDocuments_1_0.exe)
  • Debian-bug attachment:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1133865;filename=xps_test.xps;msg=24
  • Additional examples:
    https://example-files.online-convert.com/document/xps/example.xps and
    http://www.xpsdev.com/content/files/xps-document-example.xps
These include both synthetic samples and realistic Print-to-XPS output, which is particularly important for regression testing.

7. Stable and open specification
The final XPS was standardized as ECMA-388. The specification is complete and no longer evolving, making it a low-risk format to support long-term.

Related references

• Debian bug: https://bugs.debian.org/1133865
• Upstream discussions:
   https://gitlab.gnome.org/GNOME/papers/issues/77
   https://gitlab.gnome.org/GNOME/papers/issues/347

Request

Please consider restoring XPS support in the Debian build of Papers, either by re-enabling the backend if available or carrying a downstream patch using libgxps.

This would resolve a clear regression, restore compatibility with existing user data, and align with Debian’s goal of providing broad and reliable document accessibility.

Thank you for your consideration.

Kind regards,
Albert