It's a lot harder to add something, versus deleting stuff.
Some code works okay, but more would be needed later. Someone with an itch to scratch may come along, and may look at it - if it ain't there, it won't get solved. I'd vote for leaving it as-is, or as a TODO.

It's a lot harder to add something, versus deleting stuff. Some code works okay, but more would be needed later. Someone with an itch to scratch may come along, and may look at it - if it ain't there, it won't get solved. I'd vote for leaving it as-is, or as a TODO.

It's also a lot harder to add something when you need to support a ton of edge cases--for instance, if you want to write image-related code, and have to make sure you properly handle the case where you're passed an animated image. I'm pretty sure there are a lot of places in the codebase that already blindly assume they'll never be passed an animated image and just unconditionally accessed the image field of the union anyway.

If one were to add support for animated images, in whatever form that would take, they would pretty much need to start from scratch anyway. All existing code, as I said, just takes the first frame. GIF files' framerates are never loaded, and that's pretty important for displaying animations. A lot of code also uses GImage as a "pixmap" type, which serves a pretty distinct role from "displayable potentially animated thing", so for proper animation support, you'd need to disentangle which parts of the codebase need which type. I'm not even sure why animation support would be needed--are animated fonts a thing?

Every additional feature adds complexity that makes it harder to modify the codebase, and FontForge is a pretty big ball of spaghetti code as-is. In my opinion, removing API surface that has gone entirely unused will make it overall easier to add to the codebase.

I generally favor the removal of this code, for the reasons @valadaptive already mentioned. I would hardly expect someone to do anything with a 13-years old code probably never touched by anyone but GWW, especially given the lack of clear use case.

From my coding experience, if Prince Charming were to come, it would be easier for them to write something from scratch. than to reuse some theoretical foundation which never served a real purpose.

On the other hand, as we are gradually moving towards GTKMM, it could be also reasonable to just let GImage gradually fall out of use in favor of Gdk::Pixbuf, without moving it around much.

I hope we can reach a consensus on it, to me any change is better than stagnation :)

I would prefer to spend review time on something else given the limited upside. This is a big change, and the risk of it causing latent problems is non-zero even with review. People do reportedly link against libfontforge.

FontForge has a stable ABI? 😱

People do reportedly link against libfontforge.

Forgot to ask, but just out of curiosity, do you remember who the API consumers are? I know of MFEK but I think that project is dormant/abandoned.

Forgot to ask, but just out of curiosity, do you remember who the API consumers are? I know of MFEK but I think that project is dormant/abandoned.

One example I found from casual digging is https://github.com/coolwanglu/pdf2htmlEX. You can search the entire GitHub for libfontforge, and perhaps there are more.

Thinking again about it, probably Gdk::Pixbuf is the way to go. If the proposed changes to GImage are intended as a preliminary step for something deeper, please feel free to discuss that.

@valadaptive, to answer your earlier question, there is no official policy, but we do try to keep libfontforge templates stable, and, where that fails, to add new features to the end of the struct in question.

FontForge has a stable ABI? 😱

Up to about 20120731-b, fontForge was versioned.
Examples: 1.0.0, 3.2.0, 1.3.0, 1.0.0.

A new configure/make was introduced shortly after release, and this sort of detail got missed in the process. There was an attempt to try re-introduce versioning later, but it didn't stick.

As @frank-trampe mentions, there is effort to try keep some stability, but the size of the codebase does present a challenge, and then there are other things that happen around you. for example GIMP-2.x pretty much made it necessary to keep GTK2 and python-2.x around, but now that GIMP finally migrated to 3.x, GTK3, python-3.x means FontForge can't really ride along on GTK2/python2.x much longer, so, to that point, I applaud the effort being done right now by the main developers for this.

People do reportedly link against libfontforge.

Forgot to ask, but just out of curiosity, do you remember who the API consumers are? I know of MFEK but I think that project is dormant/abandoned.

Difficult to give a good answer to this question....but...

Distrowatch has a list of top linux distros, but in a way, this is really just a list of most popular distros visiting the website. If you don't visit, or have reason to visit, you won't get counted. Similarly, with FontForge 20120731-b, spiro was pretty horrible and there were many places where FontForge "just vanished" from your desktop. There were lots of issues around these sort of bugs - when these sort of things get fixed, those issues eventually go quiet. I recall working on some of the grassroot functions early after 20120731-b release, and then I got tagged for breaking spiro, that caused some panic with users running HEAD (before 20140101). Spiro turned into a priority, so, getting into the code, got it to run more stable, and further digging into libspiro more problems to fix. Basically, fixing grassroot functions exposed problems and pushed the problems upstream. Issues concerning spiro disappeared, and I though nobody is really using spiro.
Then MFEK came along later in time to help with FontForge, and I understand he loved spiro, and had been using it for a while.

There was talk about deprecating basic scripting. You'd probably think that lack of issues meant nobody really uses it. Turns-out it was a big deal important enough to cause a developer to fork FontForge, so he could maintain a stable copy running with Basic scripting.

In summary, few to no issues could mean nobody uses it, or maybe it's working okay, and therefore no issues to report.

If you look at the early Pull Requests and content creation in designwithfontforge, you'll get some idea of some people and users that have/had interest in FontForge.

I've noted and found success in keeping the smaller projects stable, and even improving them, but the codebase of FontForge itself is large, with emphasis on "very" large. If you attempt improvement from high-up, you eventually get down into the weeds and spread yourself thin trying to fix or improve stuff. I had found some success in trying to fix some of the grassroots stuff and working upwards. That helped developers working from high-up working down with some more stable functions. If you look at libuninameslist and libspiro, there are many issues in the begining, but as they became more stable, there are no issues to report now.

Trying to gauge who are users of libfontforge is similar, lack of issues doesn't necessarily mean noboy uses it.