XPS to JPG
Nothing you choose here leaves your browser, and nothing is downloaded to make it work. An XPS is a ZIP of XML — the same shape as a DOCX — and the drawing commands inside are all but SVG's already.
The same, where a JPEG is what is being asked for.
A page of text and flat shapes is close to the worst thing to put through JPEG compression: hard edges are exactly what it smears, and you will see grey fringing around every letter. PNG is the better target and is one click away. This exists because sometimes the thing at the other end only takes JPEGs.
An XPS is Microsoft's answer to PDF, and almost nobody opens one
Windows used to offer Microsoft XPS Document Writer alongside the printers, and a great many people printed to it by accident and were left with a file nothing they own will open. That is usually why somebody is on this page. It is a real format, well specified, and it lost.
.oxps is the same thing under a later
name — the standardised version, which Windows 8 onwards writes by
default. Both are read here, and the difference does
not matter for anything this page does.
The coordinates come across untouched
An XPS page is measured in ninety-sixths of an inch, with the origin at the top left and y increasing downward. That is exactly an SVG user unit at the usual 96 DPI, and the corner and direction match too — so a shape at 100, 100 in the document is a shape at 100, 100 in the result. There is no scale factor anywhere in this conversion.
Measured rather than assumed: a
page declaring Width="192" is reported by MuPDF as 144
points across. 144 points is two inches, and two inches is 192
ninety-sixths.
The colours put the alpha first
XPS writes a colour as #AARRGGBB. CSS and
SVG write it as #RRGGBBAA. The transparency is at
the opposite end, and copying the eight characters straight
across does not fail — it draws the wrong colour.
| In the XPS | #FF3366CC |
|---|---|
| Rendered | (51, 102, 204) — an opaque blue, measured by rendering it |
| Read as CSS | (255, 51, 102) at 80% — a pink-red |
And the fill rule is the other way round
Path data in an XPS may begin with F0 or
F1, choosing even-odd or nonzero filling. Two things follow
and both bite.
First, that prefix is not a path command.
Hand it to an SVG parser and it stops at the F, so the
shape does not draw wrongly — it does not draw at all. It has to
come off the front and become an attribute.
Second, the defaults disagree.
Measured on a square with a square hole in it: with F0 the
hole is open, with F1 it is filled, and with no prefix at
all it is open. So XPS defaults to even-odd — and SVG defaults to
nonzero. Leave the rule off and every hole in every letter, washer and
ring quietly fills in. This page writes the rule out on every single
path, even where the file agreed with it.
What it will not do
- It will not use the document's own fonts. XPS embeds them obfuscated, and nothing here unpicks that. Text is placed at its own position and its own size in a standard face — words sit where they sat, letters within a word will not, exactly. XPS to TXT gets the words themselves, which is unaffected.
- Images placed on a page, and anything painted with a gradient or a tiled brush rather than a flat colour, are not drawn. They are counted and named on screen rather than left out silently.
- It reads the drawing, not the print job. An XPS is a spool format, and what comes out is the page as a picture.