I didn't review this thoroughly, but the idea looks reasonable. GDK backend has been enabled for at least 6 years, and I guess raw X11 is not really needed anymore.

Still, I'd like to seek additional opinions for such a bold move.

@valadaptive, this is something that @iorsh and I have discussed doing in the future and shall likely happen, but it is going to require a little consultation with downstream parties and then a deprecation notice in order to limit disruption. Our limited market power means that changes that break somebody's packaging script can lead to the version getting pinned for a long time.

Which downstream packagers still enable the X11 backend?

Also, as @iorsh mentioned in #5611:

This wouldn't be a real fix though, as the new GTK window comes up and even works, but behaves rather erratically.

The latest master is already broken if the X11 backend is enabled. I definitely understand if you don't want this change being made by a new contributor though.

@frank-trampe Is the implication that #5546 either needs to be backed out or needs an X11-specific work-around?

@valadaptive, I was unable to reproduce the arbitrary zoom issue you encountered, but I guess it's reasonably common if you stumbled upon it.

@skef, a build fix for #5611 is possible. It would slowly degrade the user experience with X11 backend (with newer GTK windows working, but buggy) instead of shutting it off at once.

I remain skeptical of the inferences being made about the user base. What significant contact have we even had with the user base over the past, say, 4 years? How much script-level development has shifted to fontTools over the past, say, 7 years? What users who are relying on the X11 back-end specifically wouldn't be adequately served by simply sticking with an older version of the program?

What significant contact have we even had with the user base over the past, say, 4 years?

Perhaps relevant, I read this article on Hacker News, and it seems to show how people see FontForge nowadays.

I have no current specific information from downstream users/packagers, just memories of past large changes not going over very well. Having been a victim of a few abrupt removals of non-deprecated features in other products, I am sensitive to the general importance of giving notice of large changes.

FontForge has always been clunky, even when it had fewer features, and it was once a lot buggier than it is now. (Try a version from 2012.) Accordingly, evidence-based disdain for FontForge is nothing new. There are nonetheless a lot of people who still use FontForge, and it is important to avoid unnecessarily inconveniencing them.

I did some checks, and of all the major distros I could recall none seems to override the default option of ENABLE_X11=OFF

• Debian - https://salsa.debian.org/fonts-team/fontforge OK
• Homebrew - https://github.com/Homebrew/homebrew-core/blob/main/Formula/f/fontforge.rb OK
• MSYS2 - https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-fontforge OK
• Fedora - https://src.fedoraproject.org/rpms/fontforge/tree/rawhide OK
• FreeBSD - https://www.freshports.org/print/fontforge OK
• Ubuntu - adopts Debian package as is https://launchpad.net/~fontforge

Good. Our informal deprecation has been fruitful.

I've made the requested changes.

I've also noticed that cv->back_img_out_of_date and cv->backimgs seem to be completely unused by the Cairo version of the charview. I'll remove those in a follow-up PR; this one is big enough as-is.

I've removed those additional defines (seems like unifdef missed those _NO_LIBCAIROs for some reason) and FindX11.cmake.

I think the entire CMake backports folder can probably go away in another PR--even Debian oldoldstable ships cmake 3.18, and CMake prints a big ugly deprecation warning if we set cmake_minimum_required to anything less than 3.10. Would another PR for that be accepted? Not sure which CMake version to target.

I've removed those additional defines (seems like unifdef missed those _NO_LIBCAIROs for some reason) and FindX11.cmake.

I think the entire CMake backports folder can probably go away in another PR--even Debian oldoldstable ships cmake 3.18, and CMake prints a big ugly deprecation warning if we set cmake_minimum_required to anything less than 3.10. Would another PR for that be accepted? Not sure which CMake version to target.

CMake was introduced by @jtanx, and I don't know what were his considerations when adding local Find*.cmake files to the build system. My guess is that they were too divergent or just not available on all platforms. I recently tried to remove FindGDK3.cmake, but it didn't go smoothly, so I gave up.

@jtanx, would it be safe to remove these files and rely on the standard CMake distribution?

In any case, I'd prefer to defer such PR until after the official release. We've got enough risks for this release already.

I recently tried to remove FindGDK3.cmake, but it didn't go smoothly, so I gave up.

FindGDK3 is not part of the backports folder. Everything in here should be provided by newer versions of CMake--I tried removing the entire folder on my end and it builds just fine (Fedora 42).

Let's also leave any libfontforge changes for a future pull request.

Let's also leave any libfontforge changes for a future pull request.

As far as I could understand, this was the issue with #5610. Do we have libfontforge headers here too? I see that the library defines two sets of headers: FONTFORGE_NOINST_HEADERS and FONTFORGE_INST_HEADERS, but they end up in the same list without any differentiation.

@frank-trampe, do you have specific changes in mind?

Also, it looks like @jtanx explicitly killed libfontforge in #3855:

The only major exclusion compared to autotools is it does not install headers and pkgconfig details. While it is certainly possible to mimic the old behaviour, I'm not seeing much reason to make libfontforge something that can be developed against. As seen in #3823, FontForge isn't well designed to be used in external projects, and we provide no stability guarantees over what is effectively internal interfaces. I doubt that we even export all required headers at the moment.

It was noticed by downstream maintainers - e.g. https://bugs.archlinux.org/task/65877.html, but some of them probably chose to keep maintaining it internally, hence the versioning libfontforge2, libfontforge3, libfontforge4 etc.

Ubuntu, for example, slowly pushes out the 2019 version - https://launchpad.net/ubuntu/focal/amd64/libfontforge-dev

I somehow missed that at the time. It is certainly a problem that we need to fix at some point.

Ubuntu, for example, slowly pushes out the 2019 version - https://launchpad.net/ubuntu/focal/amd64/libfontforge-dev

Ubuntu 20.04 will always ship the 2019 version though. That won't change no matter what we do here because any Debian-based distro release will (AFAIK) ship the same major versions of packages for its entire lifecycle, backporting fixes from newer versions if enterprise customers pay them to do so. In 22.04 onwards, libfontforge-dev has been completely dropped. So it's not as if distros are foregoing newer versions of FontForge in order to maintain support for libfontforge--Ubuntu 20.04 still has libfontforge because it ships old versions of all software as a matter of policy.

@iorsh, I was originally proposing to leave out the struct linelist changes for a future pull request, but it seems pretty clear that no outside product would use it and that we can make those changes without a separate discussion.

Any volunteers to check for valgrind regressions?

Any volunteers to check for valgrind regressions?

I valground some simple actions, like opening font, opening char view, copy-paste. The logs appear similar, I couldn't see any new issues.

I sent the following message to the FontForge users mailing list last Saturday. There are no responses so far. Are there any other checks or adjustments that we need to make before merging?

Hello, all.

FontForge has supported GDK for some time, and there are considerable difficulties in maintaining the legacy X11 interface. We are considering removing it and mandating GDK and Cairo. FontForge can still run in X11 through GDK even without the direct X11 interface. Downstream packagers and distributors may need to adjust scripts and other packaging. Discussion is currently on pull request #5612 on GitHub. We would normally offer a lengthy deprecation window, and we will do so if there is a compelling reason, but a lot of the work is already done, and we would like to move quickly if there are no deal-breakers.

Best wishes,

Frank

I'm clear with the merge. There is an unrelated CI failure on master (https://github.com/fontforge/fontforge/actions/runs/17700511538) due to recent OS upgrade to Microsoft Windows Server 2025, but I don't want it to delay this PR any further.

Okay. It sounds like everybody is satisfied. Let's squash and merge.