scribus: an open source desktop publisher kept in Subversion

The GitHub repository is a mirror, not the source of truth

The first thing the README does is set expectations, and it does it in the status section. This README is geared toward the Scribus GitHub repository, which serves as a mirror for the Scribus Subversion repository at svn://scribus.net/trunk/Scribus. The development team prefer svn over git, and they recommend you also use the public Subversion repository.

The important sentence is the one about support: the mirror is updated manually and is not supported by the Scribus team. For any issue, the project will ask you to get the source from Subversion before submitting a bug.

That is unusual for a repository with an active last push, dated 2026-10-19, and it changes what the repository is for. It is a convenience for people who prefer to browse or clone from GitHub, not a place to contribute. The contributing section is explicit: for bugs and patches, send them to the Scribus Bugtracker at bugs.scribus.net to be evaluated. If you do send a pull request here, someone will either ask you to do the same or submit the pull request as a patch to the bugtracker for you.

For a project that has kept the same version control system for years, that is a defensible choice, but it does mean a GitHub-first contributor will lose time before their first patch lands.

Text layout for scripts that break other tools

Scribus is described in one line as open source desktop publishing, and the feature list is where it distinguishes itself from word processors and simple layout tools.

The list of complex text layout features available right now covers right to left languages, naming Arabic, Persian, Urdu and Hebrew, bidirectional text, Indic scripts and languages, and more than 500 languages in total. It also includes support for OpenType font features and the ability to customise the hyphenation character.

Two of those entries are less obvious. Bidirectional text handling and 500 language support are the reason a publisher working in Arabic or Indic scripts would choose this over a generic word processor, and they are the features that take the most work to get right. The customisable hyphenation character sounds trivial and is not, since the default hyphen does not suit every script, and the same goes for the OpenType font features, which is where typographic detail such as proper figures or stylistic sets live.

The last two entries are about workflow rather than typography: the ability to link selected text frames directly, and faster loading and rendering of long documents. Both are the kind of thing that only matters once a document stops being a single page, which is exactly where a layout application has to earn its place.

The audience is therefore people producing print-ready documents, with the patience to work in a page layout model rather than a flowing text one.

Build files for CMake, qmake, KDE and the older autotools path

The repository top level is large, and the build files tell you how many build systems the project still carries.

CMake is the modern path, with a top level CMakeLists.txt and a family of included files beside it: CMakeLists_Apple.cmake, CMakeLists_Dependencies.cmake, CMakeLists_Directories.cmake, ConfigureChecks.cmake, a cmake/ directory, a config.h.cmake template and cmake_uninstall.cmake.in. The configure checks and the generated config header are the two parts worth knowing about, since they are where feature detection for optional libraries happens.

Alongside that there is a configure script at the root, which is the older autotools entry point, and a set of qmake project files, Scribus.pro and ScribusDesignerPlugins.pro, plus Scribus.kdev4 and a .kdev4/ directory for the KDE development environment.

The platform specific build instructions are separate documents: BUILDING for the general case, BUILDING_win32_cmake.txt for Windows with CMake and BUILDING_win32_msvc.txt for Windows with Visual Studio.

Continuous integration is configured in more than one place, with a .travis.yml at the root and a .gitlab-ci.yml beside it, and the README still carries a Travis CI build badge along with a Coverity Scan badge for static analysis.

The practical consequence for a new contributor is that the build documentation is spread across several files, and the CMake route is the one the project is still investing in.

Packaging artefacts for Linux, macOS and Windows

The repository contains the packaging inputs alongside the source, which is unusual and useful.

There is an AppImage-package/ directory for Linux, an OSX-package/ directory for macOS, a Scribus.app/ bundle directory, and a win32/ directory for Windows. On the desktop integration side there are scribus.desktop.in and scribus.appdata.xml.in, both templates with an .in suffix because they are processed at build time, and scribus.install.targets for installation rules.

The build system can produce a .lsm file, with scribus.lsm at the root, which is the Linux Software Metadata description used for package listings. There is also a scribus.xml file at the top level, which is the XSLT stylesheet for generating the HTML documentation from the DocBook sources, alongside the doc/ directory that holds those sources and devel-doc/ for developer documentation.

The dtd/ directory holds document type definitions, and the codegen/ directory holds code generation helpers, which is what a project that ships both an application and file format definitions needs.

The resources/ directory holds the data the application loads at runtime, from templates to translations, and TRANSLATION at the top level collects the notes on how localisation is handled. Everything else in the root is project documentation and history: AUTHORS, ChangeLog, NEWS, TODO, LINKS and fparser.txt, which describes the format of the font parser.

Where a bug actually has to go

The links table in the README is the reference for anyone who wants to work on the project, and it shows how much of the community infrastructure still lives outside GitHub.

The website is scribus.net, the wiki is wiki.scribus.net, the mailing lists are at lists.scribus.net, the forums at forums.scribus.net, and there is a WebSVN browser at scribus.net/websvn. The Subversion repository is svn://scribus.net/trunk/Scribus, and the IRC channel is on Libera Chat at irc://[email protected].

The bugtracker is the one that matters for contributors, at bugs.scribus.net, and the contributing section points every bug and patch there first.

That arrangement has a cost worth naming. A contributor who expects a GitHub issue, a pull request and a CI badge to be the whole loop will spend time before they understand that the loop is a tracker ticket and a patch against Subversion. It also means the mirror on GitHub is best treated as a read-only convenience, and the question of whether a change landed is answered on the bugtracker rather than in a commit feed.

For an end user none of this matters much. The application is the product, and the packaging directories show that it is built for Linux, macOS and Windows from the same tree.

Licence and release mechanics

The licence field for the repository is one GitHub cannot classify, and the terms live in the COPYING file at the root rather than in a standard identifier the tooling can read.

For a desktop publishing application, the licence question matters more than it does for a library, because the application is what ships to a user's desktop and the file formats are how documents move between tools. The licence is a custom one in the sense that GitHub's classifier does not recognise it, which usually means the project uses a well known licence with modifications or additional clauses, so the COPYING file is the text to read rather than the badge.

The release mechanics are also not on GitHub. The repository has no GitHub releases, and the version history lives in the ChangeLog and NEWS files at the top level, which is consistent with a Subversion project that has never moved its tagging to git.

So the two practical takeaways for a reader are these. First, check the COPYING file for the actual terms before you redistribute the application or build on its document formats. Second, if you want to know what changed in a given version, the ChangeLog and NEWS files in the repository are where the project records it, not a releases page.

Editorial conclusion

Adopt Scribus if you lay out print documents and need a DTP application that handles right to left scripts, Indic scripts and bidirectional text without a paid licence, and you are willing to work with the Subversion workflow the project prefers. Skip it if you need collaborative editing on the document itself, since the format and the tooling around it are built for a single author finishing a file. Before you file anything, read the status section of the README, because the GitHub repository is a mirror that the Scribus team does not support, and send bugs and patches to the bugtracker at bugs.scribus.net. The last push was on 2026-10-19 and the licence is the one in the COPYING file.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. scribusproject/scribus on GitHub