Flatpak GIMP: Accessing System Fonts and Scanners

This article examines how Flatpak's sandboxing mechanism impacts GIMP's ability to detect system fonts and interface with hardware scanners. Running GIMP inside an isolated environment alters traditional file paths and device-level communications, which can lead to missing typography or undetected scanning devices. The following sections explain the technical reasons behind these restrictions and provide straightforward methods for restoring full functionality.

How Flatpak Sandboxing Impacts System Fonts

Flatpak packages isolate applications from the host filesystem to improve security and dependency management. Under standard configurations, GIMP cannot read arbitrary files on your system, which includes fonts stored in non-standard directories.

To ensure typical fonts still work, the Flatpak runtime automatically mounts standard host font locations as read-only directories. These typically include:

  • /usr/share/fonts
  • /usr/local/share/fonts
  • ~/.local/share/fonts
  • ~/.fonts (legacy directory)

Flatpak also mirrors the host's font cache configurations using Fontconfig. As long as fonts reside within these conventional paths, GIMP detects them seamlessly.

However, font discovery fails when users store fonts in custom partitions, external drives, or directories managed by third-party font managers. Because the sandbox restricts access outside the allowed paths, GIMP cannot index these assets.

To grant GIMP access to a custom font directory, you must explicitly expose the path using the command line or a permissions manager like Flatseal:

flatpak override --user --filesystem=/path/to/custom/fonts org.gimp.GIMP

After updating filesystem permissions, GIMP's internal font cache must be refreshed via the Fonts dialog within the application.

How Sandboxing Affects Hardware Scanner Detection

Scanner integration poses a significantly higher challenge inside a Flatpak container than font detection. Traditionally, GIMP relies on the SANE (Scanner Access Now Easy) backend—often through the XSane plugin—to communicate directly with connected scanners via USB or local networks.

Flatpak breaks this traditional model in two distinct ways:

1. Restricted Hardware Access

Flatpak containers do not have automatic access to host device nodes, such as /dev/bus/usb. Without raw access to the USB subsystem, the SANE libraries bundled inside the Flatpak cannot query or control physical scanner hardware plugged into the computer.

2. Absence of a Dedicated Scanning Portal

Modern desktop integration in Flatpak relies on XDG Desktop Portals (which safely handle printing, file opening, and screen recording). Currently, there is no standardized XDG Desktop Portal for document scanners. Consequently, GIMP cannot request scanner access through a secure host prompt like it does when saving files or printing.

Workarounds for Scanner Access in Flatpak GIMP

Because direct scanning from within the Flatpak sandbox is inherently restricted, users generally rely on three methods to acquire scanned images:

  • Use SANE Over the Network: Configure the host machine to run the SANE daemon (saned) listening on localhost. Grant the GIMP Flatpak network access permissions, allowing the internal SANE client to communicate with the host's scanner service over the local network stack.

  • Grant Broad Device Permissions: You can lower sandbox restrictions by granting GIMP access to host devices using Flatseal or the terminal:

    flatpak override --user --device=all org.gimp.GIMP

    Note: This compromises some security benefits of the sandbox and may still fail if the GIMP Flatpak runtime lacks the specific drivers required by your scanner model.

  • Scan Externally and Import: The most stable workaround is using a native host application (such as Simple Scan/Document Scanner or native XSane) to capture the image, save it to a standard directory, and then open it in GIMP.