A FontForge plug-in to harmonize or tunnify (balance) or add inflection points to the selected part

Linus Romer

I have published a new version of the Curvatura plugin and updated the documentation heavily.

The new (and old) abilities are described in the documentation:

Linus Romer

Raph Levien said at https://raphlinus.github.io/curves/2021/03/11/bezier-fitting.html:

an area-preserving curve fit means that the amount of ink in a stroke is exactly preserved even if the shape is slightly distorted

This quote caused me to work on a area-preserving Tunnify-algorithm (my old algorithm basically just averaged the ratios of the handle lengths with respect to the intersection point - and so does also https://github.com/mekkablue/Glyphs-Scripts/blob/master/Paths/Tunnify.py). The maths for the new algorithm are as follows:

I have implemented this algorithm at https://github.com/linusromer/curvatura. (The python implementation is not very elegant because I intend to implement it later in C for direct use in Fontforge.) You are free to use this algorithm as well.

(Just in case you are curious which of the two solutions for h you should use: take the smaller h as long as it is positive, because the greater h is probably making a loop with a negative area.)

AbrahamLee

Question for you @Linus Romer. In your images that show the curvature comb, how are you plotting those? Are those done in FF or overlaid using another app? I did figure out how to plot something like this, but yours look so much nicer that it got me curious.

Great work on curvatura!

Linus Romer

@AbrahamLee I will try to explain the plotting of the curvature combs with help of the files in the attached zip-file: I put the splines that I want to plot inside a *.sfd-file, which is the standard format of FontForge (this is curves.sfd in the example). Then I apply a Python script that I have written for this purpose, like

python sfd2tikz.py curves.sfd

(this needs the fontforge module of python). This produces tikz-files for each defined glyph, like curves-zero.tikz, curves-one.tikz, curves-two.tikzbecause I have used exactely the three slots for "zero", "one" and "two". Then I run a TeX-file with pdflatex like

pdflatex document.tex

that takes reference to the corresponding tikz-file. The output is a pdf file:

You may as well automate the whole process inside the python script (such that it writes a tex-file itself and also runs pdflatex). I am not sure how familiar you are with the TeX world but there are plenty of possibilities as soon as you have a tikz-file. You could for example use the documentclass "standalone" and then produce postscript files for each glyph.

The advantage of my method is the output of combs as vector graphics. Currently, the python-script calculates the curvature at 101 points of the curve which are connected with lines. I once used to calculate less points per curve and use the Hobby smoothing for the tikz coordinates (see https://www.ctan.org/pkg/hobby for more info on that). But when it comes to curvature change (the derivative of the curvature) the Hobby algorithm is a bad friend because the curvature change at the connecting nodes is visually notably different.

I don't think that I have published sfd2tikz.py until now but feel free to use it under the GPL3 license.

AbrahamLee

Ok, got it. That's along the lines of what I figured. I wish FF's python library was more open to other graphic libraries the way that Glyphs and Fontlab are. Would be nice to do the in-app eye candy graphics that some of the great plugins for those apps can do like Speedpunk.

Alas, when I was deep in the thick of discovering how to write more involved plugins for FF, I resorted to cooking up a more primitive way of doing it, but hey, it gets the job done and it's fast. Here's an example:



You can't change the color since the lines are real geometry, just in another layer. Like the note says, the plot is generated on-demand rather than dynamically since FF plugins are limited that way. With my plugin, you can select any number of curves/points and it will plot based on what's selected. If nothing is selected, then it creates a plot for all curves in the foreground. Since the "Curvature" layer is like a background layer, it's just a snapshot of whenever you last created the comb plots. So, if you move something around and want to see what the new curvature looks like, you have to re-run the command. A small price to pay to have the functionality in-app.

Franz Gratzer

It looks you both spent quite some time digging into getting those functions. Thank you for that. Since FF is free: Are you aware if your contributions are considered to be included into the mainline project?

AbrahamLee

That sounds good, in theory, but I wouldn't dare propose including what I've done on the plotting side since it's handled 100% manually right now and the casual user will most certainly use it wrong.

It's not the right thing to do anyway. It really needs to be added as a visualizer, something you can turn on or off at will. A number of people have already requested this feature in their backlog of issues, but I guess they have other priorities. I've also pushed them to improve the python connection and make it more open for non-Linux distributions, but all I can hope for is "maybe someday". In the meantime, I'm happy to keep doing things the way I've figured out how to do them.

Thomas Phinney

AbrahamLee said:

... I wish FF's python library was more open to other graphic libraries the way that Glyphs and Fontlab are. Would be nice to do the in-app eye candy graphics that some of the great plugins for those apps can do like Speedpunk.

That is actually a built-in function in FontLab 6+

I have heard from people who have worked on/with FontForge that the codebase is truly horrendously old and very hard to modify, indeed. Adding new features to it is a bit of a nightmare.

I won’t claim FF is dead (yet), but I am sure that eventually one of the many pretenders to the open-source font editor crown will claim its throne. How many years this will take is an open question. And in the meantime, FontForge continues to be its old clunky self.

One of the last people to be involved with FontForge, Fredrick Brennan, is nowadays working on “MFEK” (Modular Font Editor K). There are others as well, in varying degrees of not-quite-thereness. A really good font editor just has so many features!

Linus Romer

@Franz Gratzer The FontForge team once discussed whether they should revive the contrib directory. I guess that this would be the place where such scripts should be published. As long as this place does not exist there is probably not much interest of rewriting the personal scripts for a broader audience. At least, this is true for me.

@Thomas Phinney Your statement "One of the last people to be involved with FontForge, Fredrick Brennan" could imply that nearly nobody develops FontForge anymore. Looking at the commit-activity on github I would consider such an implication as wrong. E.g. Jeremy Tan, Skef Iterum, Frank Trampe, Andreas Stefl, David Corbett and Khaled Hosny contributed besides Fredrick Brennan last month to FontForge (and others of course).

I have heard from people who have worked on/with FontForge that the codebase is truly horrendously old and very hard to modify, indeed. Adding new features to it is a bit of a nightmare.

This is at least the impression one could get after reading this typedrawers thread. However, I would consider most of the data structures and the core algorithms as efficient and stable. The math behind the algorithms proves to be correct and sometimes even innovative.

I see the lack of ease adding a visual feature like Speedpunk. But then again I would say that it is rather easy to implement new algorithms restricted to the given visual constraints. I am experimenting with various curve optimization algorithms and FontForge is quite nice for this because it is open source and has many charming numerical implementations such as solving a quartic equation fast and stable.

Linus Romer

The next issue of TUGBoat (the journal of the TeX User Group) will come with an article that I have written on curvature combs and harmonization. Besides a reference implementation in MetaPost it contains a mathematical derivation of the harmonization formula that is currently used in FontForge. 

I have attached here an excerpt of the mathematical relevant part. There are two things that I have not been aware of last year and may be interesting for you as well:

• Since my first implementations in 2019 I have used a formula that may not be numerically stable for some very specific situations. This is corrected in the article and a pull request at github is pending for changing it in FontForge as well.
• The algorithm that is described at https://gist.github.com/simoncozens/3c5d304ae2c14894393c6284df91be5b has been published in 1990 by Robert L. Roach
  John R. Forrest. My algorithm is slightly more general but for the overlapping cases it is equivalent.