Every Fedora desktop eventually meets the same Monday morning problem. Someone sends a DOCX with tracked changes, a spreadsheet full of merged cells, or a slide deck built around fonts you have never heard of. LibreOffice opens it, mostly. “Mostly” is the issue. Column widths drift, a table jumps to the next page, and a client asks why the proposal looks broken.

That is why many admins and office users want WPS Office on Fedora. The interface feels close to Microsoft Office, and its rendering of .docx, .xlsx and .pptx files is often closer to what the sender intended. Getting it onto Fedora 44 is not a simple dnf install wps-office, though. The suite is not in Fedora’s repositories, and the vendor RPM trips over DNF5’s package checks. The workaround is quick, but it should be done with some care.

This guide covers the whole job. You get the official RPM method, the Flatpak alternative, how to decide between them, and what to do about the first-launch problems that show up on a clean Fedora 44 box. It also covers updates, security trade-offs, clean removal and a few notes for fleets of machines. The commands are written for Fedora 44, with notes where the same ideas apply to AlmaLinux, Rocky and other RPM-based systems.

What You Are Actually Installing

WPS Office is a proprietary suite from Kingsoft. It has Writer for documents, Spreadsheets, Presentation and a PDF reader. On Linux, WPS publishes a DEB package for Debian-family systems and an RPM for Fedora, openSUSE and RHEL-compatible distributions such as Rocky and Alma.

Fedora’s own repositories do not package it. So you have two realistic options.

Flathub states plainly that its package is community-provided and not verified by, affiliated with, or supported by Kingsoft. Read that before you pick the convenient option on a machine that handles sensitive documents.

One more point on versions. Different sources show different version strings for the Linux build. The RPM metadata used in a recent Fedora 44 walkthrough resolved to 11.1.0.11723, while WPS’s own update log lists a 2023-branch Linux release numbered 12.1.2.29182. Treat any version number in a tutorial, this one included, as a snapshot. Check what the download page serves on the day you install.

Before You Touch the Terminal

A few minutes of prep saves a lot of guessing later.

Check your architecture and session type

The vendor RPM is built for x86_64. Confirm that before you download anything:

uname -m
cat /etc/fedora-release
echo "$XDG_SESSION_TYPE"

On an aarch64 machine, such as an Asahi Fedora laptop or an ARM VM, the x86_64 RPM will not install. Fedora 44 desktops default to Wayland, and WPS runs through XWayland on most setups. That works, but you may see slightly soft text on fractional-scaling displays. More on that in the tuning section.

Make sure the system is current

Stale metadata causes odd dependency errors. Refresh first:

sudo dnf upgrade --refresh

If a kernel or glibc update comes through, reboot before continuing. It is boring advice, but it removes a whole category of “it worked yesterday” confusion.

Check disk space

The WPS RPM is large. The package inspected in the Fedora 44 walkthrough reported an installed size of roughly 1.4 GB. Check free space on / and /usr:

df -h / /usr /var

On a small root partition, such as a 20 GB VM with a default Fedora layout, that is a meaningful bite. Plan for it.

Method 1: Install the Official RPM

This is the path for people who want the vendor’s own package. It takes four steps: get the download URL, fetch the file, inspect it, and install it with the right flags.

Step 1: Get the current download URL

Hard-coded URLs in old blog posts go stale quickly. Older tutorials point at version 11.1.0.11723 on the WPS CDN, and newer versions have shipped since then. The most reliable approach is to download from the official Linux page and let your browser save the RPM into ~/Downloads.

If you prefer to script it, the Fedora 44 guide from LinuxCapable reads the metadata endpoint that the WPS Linux page itself uses and extracts the RPM link with Python. That is useful on a headless workstation or in a provisioning script:

cd ~/Downloads
RPM_URL=$(python3 - <<'PY'
import base64, json, urllib.request

meta = "https://params.wps.com/api/map/web/newwpsapk?pttoken=newlinuxpackages"
with urllib.request.urlopen(meta, timeout=30) as r:
    payload = json.load(r)

blob = payload["staticjs"]["website"]["wpsnewpackages"]["downloads"]
print(json.loads(base64.b64decode(blob))["linux_rpm"])
PY
)
RPM_FILE=${RPM_URL##*/}
echo "$RPM_URL"

Treat that endpoint as unofficial and undocumented. It can change without notice. If the script fails, fall back to the browser download.

Step 2: Download the package

curl -fL -o "$RPM_FILE" "$RPM_URL"

The -f flag makes curl fail on HTTP errors instead of quietly saving an error page as your “RPM”. The -L flag follows redirects. Small flags, but they save real time when a CDN returns a 403 and you end up debugging a 2 KB HTML file.

Step 3: Inspect before you install

Never feed an unknown package to rpm as root without looking at it first. Check the metadata:

rpm -qpi "$RPM_FILE" | sed -n '1,10p'

You should see the package name wps-office, an x86_64 architecture and a proprietary license. The Fedora 44 walkthrough also reports Signature : (none). That matters for the next step.

Now check the digest state:

rpm -K "$RPM_FILE" || true

The same walkthrough shows DIGESTS NOT OK for the current WPS RPM. That output is not a sign of tampering. It reflects how the vendor builds the package. It does mean you cannot cryptographically prove that the file is what Kingsoft intended to ship. Your only assurance is the HTTPS connection to their servers and whatever hash you compare out of band.

Step 4: Install the dependency, then the RPM

Fedora’s DNF5 refuses the package through the normal local-install route. The failure looks like this:

Transaction failed: Rpm transaction failed.
  - package wps-office-11.1.0.11723.XA-1.x86_64 does not verify: no digest

That exact error is documented for Fedora 44. The workable sequence is to pull the missing dependency with DNF, then install the RPM directly with rpm:

sudo dnf install libXScrnSaver -y
sudo rpm -ivh --nodigest --nofiledigest "$RPM_FILE"

libXScrnSaver comes from Fedora’s standard repositories and is the dependency the current build needs. Note also that old dnf localinstall habits no longer apply, since DNF5 on Fedora 44 dropped that subcommand.

Why rpm and not dnf? DNF5 enforces digest verification on local files. RPM itself lets you bypass that with explicit flags. Those flags are --nodigest and --nofiledigest. Use them for this single package and nowhere else. Do not paste them into a general-purpose install alias. They remove a safety net, and you want that to be a conscious, one-off choice.

Step 5: Verify

rpm -q wps-office
command -v wps wpp et wpspdf

You should get the package string and four launchers: wps for Writer, et for Spreadsheets, wpp for Presentation and wpspdf for the PDF reader. There is no combined wps-office command, which trips up people who expect one.

Launch it from the Activities overview by searching for “WPS”. On first start, accept the license prompt. If a sign-in window appears and you only need local editing, close it. Nothing forces you into a cloud account for offline documents.

Method 2: Install the Flatpak

Flatpak avoids the digest argument entirely, and it fits Fedora Workstation well, since Flatpak is already there. The catch is the trust model described earlier.

sudo dnf install flatpak -y
sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
sudo flatpak install flathub com.wps.Office
flatpak run com.wps.Office

The first install is bigger than you might expect because it pulls the Freedesktop runtime along with the application.

What the sandbox really gives you

Do not assume Flatpak means strong isolation here. The permission set reported for this package includes network access, X11 and PulseAudio sockets, DRI devices, and filesystem access to Documents, Downloads, Pictures, Videos and removable media paths. An office suite that can reach the network and read your Documents folder is not meaningfully contained. The real benefit is packaging and update flow, not a security boundary.

You can inspect or tighten permissions yourself:

flatpak info --show-permissions com.wps.Office
sudo flatpak override com.wps.Office --nofilesystem=xdg-pictures

Or use Flatseal for a graphical editor. A reasonable hardening step on shared machines is to cut the filesystem scope down to the one directory where people keep work files.

RPM or Flatpak: How To Choose

Neither is universally better. A few real-world situations help.

A freelance writer on a personal laptop who wants painless updates will be happier with Flatpak. Updates arrive with everything else in GNOME Software or through one terminal command.

A small business with ten Fedora workstations and a compliance checklist has a harder call. The RPM comes from the vendor, but it is unsigned and installs with a bypass flag. The Flatpak is signed through Flathub’s infrastructure but is a third-party repackage. Neither wins on trust. Many shops pick one and document the reason, which is the actual requirement.

If a server-style admin wants repeatability, the RPM is easier to mirror internally. You can download it once, store it in an artifact repository, record its SHA-256 and push that exact file to every machine. That gives you a known-good copy even if the vendor changes the file later.

If you want to avoid proprietary software altogether, LibreOffice is in Fedora’s repositories and is the closest in-repo alternative.

First Launch: What To Check Right Away

Do not trust an empty blank document as a test. It tells you nothing. Open real files.

Pick one DOCX with tables, comments and an embedded image, one XLSX with formulas and a chart, and one PPTX with a corporate template. Look for font substitution, shifted line breaks and broken date formats. These are the compatibility problems that will cost you hours later, and they appear in the first five minutes if you look.

Also review file associations. WPS may offer to claim DOCX, XLSX and PPTX. If another editor is already set up for your team, decline.

Fonts: The Real Source of Layout Problems

Most “WPS looks wrong on Linux” complaints are font complaints. Windows documents expect Calibri, Cambria and Arial. Without metric-compatible replacements, text reflows and page breaks drift. Missing CJK fonts also produce empty boxes in Chinese templates.

Install metric-compatible families from Fedora’s repositories:

sudo dnf install google-carlito-fonts google-crosextra-caladea-fonts liberation-fonts -y
fc-cache -f

Carlito matches Calibri’s metrics and Caladea matches Cambria’s, while Liberation covers Arial, Times New Roman and Courier New. That covers most business documents. Fedora does not ship Microsoft’s own fonts, and licensing is the reason. If you are licensed to use them, install them from your own Windows media or from a legitimately obtained source.

A separate font problem affects WPS itself. A common community report is that WPS shows a “missing fonts” warning at startup. The community fix is to copy a set of WPS-specific fonts into /usr/share/fonts and rebuild the font cache. That repository is third-party and unverified. Check what you copy, since fonts are binary files parsed by privileged libraries. Many people dismiss the warning and carry on, and since the Carlito and Liberation set handles real documents, that is usually fine.

After any font change, quit WPS fully and restart it. Check with:

fc-match Calibri
fc-match Cambria

You should see Carlito and Caladea respectively.

Troubleshooting: Errors You Will Likely Hit

“does not verify: no digest”

This is the DNF5 refusal covered above. The fix is sudo dnf install libXScrnSaver -y followed by the rpm -ivh --nodigest --nofiledigest install.

Missing library errors on launch

If a launcher exits immediately, run it from a terminal and read the final lines:

wps 2>&1 | tail -n 20

A message about a missing .so file tells you which library to find. Search Fedora for the package that provides it:

dnf provides '*/libXss.so.1'
ldd /opt/kingsoft/wps-office/office6/wps | grep "not found"

The ldd check lists every unresolved dependency in one pass. One frequent report from older guides is a hint about libpng12. Fedora has dropped that old library, so do not hunt for it first. Check whether the binary actually fails or whether the message is just noise from an older install log.

PDF export fails

The classic error is “WPS Writer encountered an error while trying to export to PDF”. Reports tie it to a missing libtiff.so.5, because modern distributions ship libtiff 6. The suggested workaround is a symbolic link, and on Fedora the library directory is /usr/lib64.

First confirm what you have:

ls -l /usr/lib64/libtiff.so*

Then, if only version 6 is present, add the link:

sudo ln -s /usr/lib64/libtiff.so.6 /usr/lib64/libtiff.so.5

Be honest about what this does. You are telling the loader that a newer library satisfies an older soname request. It usually works because the ABI used by WPS is narrow, but it is not guaranteed. It also lives outside RPM’s tracking, so a future libtiff update or a WPS removal can leave a stray link. Note it in your documentation. If font substitution is the real cause, fixing fonts first is the cleaner path, and the same source suggests that as a second check.

Before you reach for the link, try exporting a plain document with only common fonts. If that works, the issue is a font and not libtiff.

Blurry text or tiny UI on HiDPI

This is mostly an XWayland scaling issue. Try launching with an explicit scale factor:

QT_SCALE_FACTOR=1.25 wps

If that helps, make it permanent by copying the desktop file locally and editing the Exec= line. Do this in ~/.local/share/applications/, not in /usr/share/applications/, so package updates do not overwrite it.

SELinux denials

Fedora enforces SELinux by default, and the right response to a denial is to read it, not to disable SELinux. Check recent AVC messages:

sudo ausearch -m avc -ts recent
sudo journalctl -t setroubleshoot --since "30 min ago"

WPS installs under /opt, and most normal operation works without custom policy. If you do find a legitimate denial, generate a narrow module for that one rule rather than flipping to permissive mode.

Cloud sign-in or AI feature prompts

Recent update notes for the Linux build mention international account and cloud service support and new AI capabilities. If your organization restricts data leaving the network, decide up front whether those features are allowed, then enforce it at the firewall or proxy level and not by trusting users to click “No”.