Papirus XApp Symbolic Icons is out: a drop-in set that gives the xsi-* icon names used by Linux Mint, Cinnamon, and the XApp projects proper Papirus artwork. Upstream draws its own Adwaita-derived versions and installs them into hicolor, so on a Papirus desktop every app asking for one of those names gets an icon that matches nothing around it. The set covers 628 of the 666 names, at 16, 22, and 24 pixels where upstream draws only 16, and installs into the Papirus theme so xsi-* lookups resolve there first. Nothing is hand-drawn: the whole set is generated from the Papirus and XSI sources, with no fuzzy matching anywhere.

Why These Icons Look Wrong⌗

XSI exists for a good reason. Adwaita is GNOME’s icon theme, and GNOME drops icons it no longer uses. An application targeting Cinnamon, Xfce, or MATE cannot build on a set that shrinks whenever GNOME reorganizes, so Mint started XSI: names that loosely follow Adwaita’s, under an xsi- prefix nobody else is going to remove.

What makes XSI dependable is exactly what makes it clash. Every one of those icons installs into hicolor, the theme every other icon theme falls back to. Icon lookup checks your theme first and hicolor last, so an xsi-* name always resolves, and in practice it resolves to XSI every time, because no theme provides those names. Not even Mint’s own: Mint-Y ships 45,316 icon files and still carries 21 of the older xapp-* names, but not a single xsi- one. Of every theme installed on my machine, hicolor is the only one that has them.

So on a Papirus desktop the artwork is already there, drawn and waiting. Papirus ships 1,436 symbolic icons across the sizes it actually draws. Nothing connects xsi-user-home-symbolic to the user-home-symbolic sitting right next to it, so your panel renders Adwaita-derived glyphs beside Papirus ones, and the seam shows.

That connection is the whole project. Same names, Papirus artwork, installed into the Papirus theme where lookup reaches it first.

Matching Names, Not Guessing⌗

The temptation with a job like this is fuzzy matching. Strip the prefix, compare strings, take the nearest hit, announce 100% coverage. What you actually ship is a set where xsi-gauge-symbolic quietly becomes some other dial, and nobody finds out until an applet shows the wrong thing.

So the generator does not guess. Every automatic match comes from data that upstream has already published:

Exact names. xsi-add-files-to-archive-symbolic.svg goes looking for add-files-to-archive-symbolic.svg. This does most of the work: 501 straight copies, plus 35 mirrored for right-to-left.

Upstream’s own rename table. XSI ships xsi-adwaita-symbolic.info, the Adwaita to XSI mapping its own migration script runs on. If Papirus has the old Adwaita name, upstream has already declared the two equivalent. That is 54 more icons, plus 3 RTL.

The old xapp-* names. XSI succeeded an earlier xapp- scheme that Papirus still draws, including the xapp-prefs-* icons used by XApp preference dialogs. 10 more.

Byte-identical aliases. Upstream ships some artwork under several names. Hash the files, group them, and any name whose twin is already mapped inherits the same source. 13 more.

That leaves 12 pairs matched by hand, each one verified by rendering both icons and looking at them. The text-direction icons show why that step is not optional. XSI names them by where the arrow points, so xsi-format-text-direction-left-symbolic is the left-pointing arrow. Papirus names the same two icons by text flow, where the ltr icon points right. Neither name matches the other, and the obvious shortcut, left to ltr, gets them backwards in both directions, with icons that still look plausible.

Right-to-left variants get one more piece of machinery. XSI has 64 of them, and Papirus draws real -rtl artwork for 26, which copy straight across like anything else. The rest get a mirrored copy, wrapping the artwork in a horizontal flip transform.

Adding up: 628 names, or 94% of the set. The other 38 have no Papirus equivalent I am willing to claim, and they are listed in mapping/unmapped.txt rather than hidden. Those keep resolving to stock XSI artwork in hicolor, so nothing breaks or goes missing. A handful of icons simply stay the way they are today.

Two of them are refusals rather than gaps. xsi-network-vpn-disabled has exactly one plausible Papirus candidate, and xsi-network-vpn-disconnected already uses it. Mapping both would draw two different VPN states identically, which is worse than one unthemed icon. xsi-preferences is a set of sliders; Papirus offers gears. Close enough to map, different enough to be wrong, and the gears are already spoken for by xsi-cog.

There is a fuzzy matcher in the repo, but it only ever prints suggestions for me to review. Nothing it says reaches the icon set without a human agreeing first.

Three Sizes Instead of One⌗

Upstream XSI ships one drawing per icon, and every one is drawn at 16 pixels. Put one in a 24 pixel slot and it gets scaled up. Symbolic artwork does not take that well: strokes drawn to sit on pixel boundaries land between them instead, and what was crisp goes soft.

Papirus draws each icon again at each size. This is not one file resized. Pull user-home-symbolic out of the 16 and the 24 directories and the path data is different, because it was redrawn for that grid.

So the set is generated at every size Papirus draws symbolic icons: 16, 22, and 24. A panel rendering at 24 pixels gets artwork made for 24 pixels.

Nine icons are the exception, all of them emotes. Papirus draws face-smile-symbolic and its neighbors at 16 only, so that is where they go, and it is why the set is 628 icons at 16 and 619 at each of the other two.

Upstream also files every icon into a single directory, hicolor/scalable/actions, whether it is a folder, a battery, or a smiley. The generated set puts each one in the context Papirus files it under, across all nine: actions, apps, categories, devices, emblems, emotes, mimetypes, places, and status.

The Stale Cache⌗

Only one directory gets written: Papirus. The dark and light variants do not need a copy, because Papirus-Dark/16x16/symbolic is a symlink pointing straight back into Papirus/16x16/symbolic, and symbolic icons carry a color scheme class that gets recolored when they are drawn. One set of files, all three variants covered.

That is the tidy part. Here is the part that caught me off guard.

Each variant keeps its own icon-theme.cache, roughly 3 MB apiece. Drop new files into Papirus and nothing inside Papirus-Dark has changed, so its cache still looks current. GTK goes on trusting it, and a cache built before the new icons existed does not know they exist. The files sit right there, reachable through the symlink, and lookups miss them anyway.

The fix is to refresh all three roots, not only the one you wrote to. make install does that.

Arch has a second version of the same trap. Pacman ships a hook that rebuilds icon caches after a transaction, but it only fires for theme roots the package itself contains, and this package contains exactly one: Papirus. Dark and light would sit there stale. So the PKGBUILD carries an install scriptlet that refreshes them on install, upgrade, and remove.

Install⌗

Papirus itself needs to be installed first. This set merges into it rather than replacing it.

sudo make install

Or per user, if you would rather leave /usr alone:

make install-user

That writes to ~/.local/share/icons/Papirus, which icon lookup merges with the system theme. sudo make uninstall and make uninstall-user take it back out, and all four refresh the caches on the way through.

Arch users get a PKGBUILD in dist/, and it will be on the AUR as papirus-xapp-symbolic-icons-git.

To build the set yourself, the Papirus and XSI sources come in as submodules:

git submodule update --init --depth 1
make icons

Nothing under icons/ is hand edited, so keeping up with new upstream releases means updating the submodules and running that again.

Conclusion⌗

Papirus is the icon theme I recommend to anyone who asks, and it has been my default for years. The one place it fell short was never really its fault: a set of icon names it had no reason to know about, sitting in the fallback theme where every lookup eventually lands.

628 of those names now land on Papirus instead. The other 38 are written down in a file anyone can read rather than rounded away, and if Papirus ever draws one of them under a matching name, regenerating the set picks it up without me doing anything.

The seam is gone from my panel. If you run Papirus on Mint or Cinnamon, or XApp applications anywhere else, install it and it should disappear from yours too. Issues and pull requests are welcome, especially on the 38.