@skef, if I understand correctly, WOFF2 support is determined at compile time, so the user who installed an official package without WOFF2 has no choice but to recompile it locally if they want this capability. That is the case in Ubuntu 22, for example.

What do you think about replacing the current mechanism with dynamic library loading, so that the user will just have to install libwoff, and then FontForge would detect it and enable the support? Or maybe I'm missing some point there...

What do you think about replacing the current mechanism with dynamic library loading

Not impossible, but also not easy to do in a cross-platform way and potentially fragile.

Also - most Linux users probably get FontForge via their distro, and users who compile it for themselves can usually be considered "experts", who shouldn't be phased by having to recompile after adding a library to their system.

That's exactly the problem with distro packages. The package comes without WOFF2 support (in Ubuntu or Debian for example), and 90% of users would be just frustrated by grayed-out option which they have no knowledge to enable.

Regarding cross-platform loading, libltdl (https://www.gnu.org/software/libtool/manual/html_node/Using-libltdl.html) looks promising. It wouldn't even need a new dependency, as it's a part of libtool which is already a dependency.

But anyway, that's for another PR.

If that's true it's a documentation problem (which is entirely plausible).

The way it's supposed to work is that the distros build with all the core features enabled and then use package dependencies to ensure the needed libraries are present. We just aren't currently making it clear what the core libraries are. We probably just need to add a readme at the top clearly labeled for distros to look at indicating what features should be enabled if possible and then note that addition in the changelog. They're usually pretty good about taking care of that stuff if they have the relevant information.

Found distribution-specific package scripts, hopefully that would be enough.

We could go this direction, but it seems kind of mysterious and different from how the rest of the exports work (other than WOFF, but that was a short-lived thing in terms of use).

Might it be preferable to just have WOFF2 TTF and WOFF2 CFF options in the UI, with corresponding separate enum values?

Do you mean options in outline drop-down list:

• Web Open Font (WOFF TrueType)
• Web Open Font (WOFF OpenType)
• Web Open Font (WOFF2 TrueType)
• Web Open Font (WOFF2 OpenType)

Sounds good to me.

Yes, but only bother with WOFF if you feel like it. There's very little use of WOFF (1) at this point.

Found distribution-specific package scripts, hopefully that would be enough.

I would recommend to avoid distro specific if you can.
Back in 20120731, there was package specific directories, and even then, it was troublesome to get distros to pickup. Going to 2014, we had an entirely new build system and it took a bit of effort for distros to pick-up. We probably went through a couple of patch improvements and releases before some of the base distros were able to pick-up and follow. If you can get the build to run on a plain vanilla Debian, or Fedora, then you have a pretty good chance that other distros can pick-up the ball and run with it too.

@skef, if I understand correctly, WOFF2 support is determined at compile time, so the user who installed an official package without WOFF2 has no choice but to recompile it locally if they want this capability. That is the case in Ubuntu 22, for example.

What do you think about replacing the current mechanism with dynamic library loading, so that the user will just have to install libwoff, and then FontForge would detect it and enable the support? Or maybe I'm missing some point there...

There is a lot of code you can look at in 20120731 that implements dynamic load. You can look at startnoui.c, gif, png, jpg, spiro for code that loads or grays-out features.

I see this question as a bit of a yo-yo we are going through (it came out, it comes back in). George Williams had it in his original code, then we came along and there were those that wanted to simplify and pull-out that code, and pretty much lock-in the code during the build, so the code as you see it, the dynamic load code isn't here anymore. - from a linux, or distro point of view, it does help reduce the problem questions of: It's grayed-out, I can't do gif, I can't do png, I can't do WOFF, etc. This was the main benefit of removing the code.
If the build is too difficult, force/requesting things that don't exist (example asking Debian to load python2.7 when everyone else was at 2.7, but Debian was at 2.6, and similar issues for Centos), or running into problems, then, is it better to leave that option off the table for now.
There's benefits and arguments for whatever direction you choose to go. ;-P

If the build system advertises what's loaded or missing, it could help the distro builder.

Using Debian as a core distro, it can also be useful to look at what's happening here:
https://packages.qa.debian.org/f/fontforge.html
particularly, the outstanding bugs, and also the build "logs".
Looking at https://packages.debian.org/sid/fontforge gives you a quick thermometer of the various packages too, and if some processors are running into issues.

@JoesCat I think mostly what happened here was that we have lists of needed dependencies in various places and we weren't including woff2 in those lists because it was niche at that time. Now it's not niche and @iorsh added it to the various lists that appear in scripts and documentation, and if we say something in the release notes as well (I forgot that we don't really have a changelog) the distros will probably pick it up just fine.