-
Notifications
You must be signed in to change notification settings - Fork 696
Defunct or Removed features from FontForge
This page documents features or ideas that were integrated, but have since (or are being) been removed.
The background on this is described by George here.
Nominally, it allowed FontForge to interact with files directly over http/ftp.
- It's a large attack surface to be exposing FontForge to, and FontForge already has enough of those
- HTTPS is becoming the norm, making this implementation obsolete
- It's buggy - attempting to open a URL leads to a segfault
- Let's not re-implement a HTTP/FTP client in FontForge. Use a library that specialises in that where necessary.
This feature was removed in this pull request: https://github.com/fontforge/fontforge/pull/3181
This was released with the 20190413 release.
Little to none
As with the HTTP support, the reason why this was introduced is documented by George here.
It would have allowed third-party extensions to integrate into FontForge.
- It ultimately went unused - the only plugin created was written by GWW, being the gb12345 encoding plugin. The feature that provided is easily replaced by loading a custom encoding, which FontForge already supports.
- It created a dependency on libltdl, which in turn, creates a dependency on the autotools build system. Not impossible to solve, but not worth the effort, considering it went unused.
- FontForge doesn't really expose a stable API/ABI, making it difficult to write plugins against
This feature was removed by this pull request: https://github.com/fontforge/fontforge/pull/3635
This was released with the 20190413 release.
- It's nice to be able to extend FontForge - but this is in part, already possible via Python scripting
This was introduced with this pull request. The idea was to add a garbage collector, making it possible to handball off memory management to it.
- Nice in theory, but it didn't work out (1, 2, 3, 4).
- Memory usage increased significantly in some cases
- Caused weird crashes when the GC ran
- It wasn't 'free' - you ended up NULL'ing variables in the hope that the GC would free it
- It created a stronger dependency on Gnulib (see below)
The bulk of the garbage collector changes were reverted with this pull request, with some later follow-ups.
It's nice not to have to worry about freeing memory. But that code has already been written, and it (more or less) works.
Gnulib is an in-source 'portability' library, that aims to make it possible to just use POSIX/stdlib functions and have it work everywhere.
As best I can tell, it was introduced with this commit (no PR!), with multiple PRs after that to move things over to use it.
- Using Gnulib strongly ties FontForge to the autotools build chain. Reasons for why this is bad have been summarised in this issue.
- Gnulib slows the build - on Windows, quite significantly; on other platforms to a lesser degree
- There's nothing in FontForge that creates a strong dependency on Gnulib - for whatever compatibility fixes it provides, there's either pre-existing solutions in Glib, or it's not difficult to roll our own fix.
Gnulib is in the process of being removed with this pull request.
It does provide some nice portability benefits. But there are equally other ways and means of achieving this.
Collab refers to a set of tools and integrations that would have allowed real-time interaction on editing a font in FontForge. To do this, it hooked into the undo/redo system, and used ZeroMQ to broadcast these out to interested parties.
It was first introduced with this pull request, although there were subsequent pull requests to build on it.
- The collab code has been unmaintained for a number of years, and remains buggy when used
- It has a dependency on an old, unmaintained version of ZeroMQ/CZMQ
- It has never been compiled to work on Windows
- As with the HTTP/FTP code, the networking code is a security risk
- The implementation 'leaked' a lot into many parts of FontForge; although some is inevitable, it would have been nicer if there was a clearer separation
- No one uses it
This is in the process of being removed with this pull request.
This is a feature that could actually be useful if it was maintained and looked after. The hooks into the undo/redo system in particular are of worthy note.
There were a set of changes and Python scripts that made to make it possible to hook into GDraw (the X11 version/GXDraw).
- It's unlikely that anyone will be using it at this point
- GDraw (like all FontForge DLLs) doesn't really provide a stable ABI
- How it's been implemented is fragile
- We're in the process of moving away from GXDraw
The issue to remove this is covered here and the pull request is here.
Being able to extend the GUI is a nice idea. How this is done will need to change, as we shift towards using GDK/GTK.
This was a partial, unfinished re-implementation of FontForge to work under GTK2, written by George.
- It's unmaintained and unfinished
- When bulk changes are done, they often touch the gtkui folder, with no guarantee that it hasn't broken something (else) in it. It also results in wasted effort whenever someone ends up touching it because of that.
- If this were to be done, there's no point targeting GTK2 any more
This has been removed with this pull request.
There are many reasons why we should move off GDraw, and use a standard UI toolkit. If/when that happens, this may serve to be of some benefit, but there's no reason to keep it around just for that (and it's easy enough to pull out of git history).
This added an interactive python shell activated from the tools menu. This is a potentially useful addition, but:
- It relies on a fragile gxdraw interface not applicable to GGDKDraw
- The version of
ipython_view.pyis very old, and the updated Accercizer version of this file is still somewhat out of date with IPython - Its implementation is based on the old pygtk GTK 2 interface, rather than the current PyGObject interfaces.
Is has been removed with this pull request.
It would be nice to support this via an updated ipython_view.py and different interfaces. However, it will either need to be added as a "core" function or based off some other graphics extension convention. The most likely means for the latter is some kind of GTK-based convention, used with GGDKDraw or some successor to that.