Quite an enjoyable post. I’m not sure how I feel about all the stuff surrounding TeX. It has incredible staying power (how much other software from the seventies is still being used for new projects?), but it is also deeply flawed in so many ways. Most users find it frustrating but put up with it because of the quality of its output, and no acceptable successor has really emerged.
But man, I can’t help but admire Knuth’s persistence on these programs. It was a massive side quest for his main project of TAOCP. I don’t think it was all a waste of time, but it’s a shame these programs are not used that much anymore.
Metafont specifically isn’t used much anymore, but the quality of digital typefaces is much, much higher now. Computer Modern is kind of an ugly font by comparison. The rest of the TeX stack is still heavily used in academia.
IMO many of the imperfections of TeX are optimizations that overfit 70s computers and predate a lot of programming language know-how. Knuth had to get his side quest done relatively expediently with the technologies that were available to him. The more you learn about the underpinnings of TeX, the more clear it is that it was driven by the limitations of the time. Also, my impression is that the way TeX was written (as a literate program) ensures that it is difficult to refactor into a new system, for the same reason it would be hard to rework a novel into a different novel of the same quality. I would expect that if you loved TeX enough to want to understand this and even maybe work on it, you would also appreciate that “novel” so much, you would be disinclined to mutilate it.
I think the lack of a compelling ground-up successor has a lot to do with the fact that the work is fairly tedious to do and nobody else has had the right combination of attention to detail, skill and need. A big impediment to adoption is that TeX documents are macro-driven and conflate “document” with “processing,” making it essentially impossible to have a successor that is both backwards compatible and a meaningful improvement. The majority of TeX users see it as a necessary but undesirable part of their workflow and have a high cost to switching to something else—for instance because the journals they publish to demand it and would need to support the successor as well as TeX. It would have to be at least a great deal easier to use, while also supporting their existing workflows somehow.
The real successor is probably actually HTML, in a “worse is better” kind of way.
A related paper is Meta-Font, Metamathematics, and Metaphysics: Comments on Donald Knuth’s “The Concept of a Meta-Font” Hofstadter, Douglas R Visible Language; Fall 1982; 16, 4; ProQuest pg. 309:
Aside, for KeenType, my modernization of the New Typesetting System, I tried using Knuth’s original Computer Modern (CM). I switched to BaKoMa because there was no simple way to extract the font metrics (tfm files) from CM. One of the stumbling blocks was how BaKoMa shifted code points away from Knuth’s CM.
I love what’s possible to do with metapost, the family of languages is quirky, bit also surprisingly powerful.
In my opinion its low popularity is also partly due to the fact that the language is based on macro expansion, which can make its behavior a bit tricky to debug. And (maybe that’s due to its age) the fact that variable scope is quite unpredictable does not make it easier to use. Nevertheless, the language design is really focused on making graphics and for that it can be a very concise format for describing it.
Current development of the potential successor to metapost is happening within the ConTeXt project; it’s called luametafun (PDF). It means that it can be controlled from the Lua side and has some interesting developments.
Another interesting program that diverges a bit from the metafont spirit is the racket library metapict. I think in general a scheme is more suitable to a macro-based program, but I haven’t really taken a serious look at it. Also since it’s much younger by comparison it simply has less documentation and examples available.
Finally, one thing I’d love to have is the ability to also have a pen stroke that can change while drawing a curve or line (so it has a time parameter). This would more accurately reflect how you actually draw something on paper, where you can e.g. rotate the pen while drawing a curve. Maybe that would make it possible to specify the letter S as a stroke instead of an outline.
Another thing that would be nice is support for three dimensional structures, but that would most likely make the equation solver much more complicated. (I know that there are some implementations but they all seem to diverge significantly from the metafont family.)
Finally, one thing I’d love to have is the ability to also have a pen stroke that can change while drawing a curve or line (so it has a time parameter)
Do you know how Chinese ideograms are drawn with metafont? Chinese and Japanese calligraphy makes very heavy use of varying pressure to narrow and widen the width of brush strokes. I can’t imagine a stroke-based font rendering system being able to render these characters well without the functionality that you describe. It’s easier with an outline-based encoding because you can use curves to describe the narrowing and widening of brush strokes.
METAFONT supports drawing an outline and filling it, so though variable width strokes are not supported natively, there are various macros (including one in the METAFONT base) which will take a path specification coupled with width information to produce the outline for you.
And here is post about a MetaPost library for drawing beautiful physics textbook illustrations, which uses offset bezier curves to vary the width of strokes: https://habr.com/en/articles/454376/
As far as I know that is exactly something that’s not possible with metafont and the likes. The system itself is not really used for rendering though, only for the creation of the font.
Quite an enjoyable post. I’m not sure how I feel about all the stuff surrounding TeX. It has incredible staying power (how much other software from the seventies is still being used for new projects?), but it is also deeply flawed in so many ways. Most users find it frustrating but put up with it because of the quality of its output, and no acceptable successor has really emerged.
But man, I can’t help but admire Knuth’s persistence on these programs. It was a massive side quest for his main project of TAOCP. I don’t think it was all a waste of time, but it’s a shame these programs are not used that much anymore.
Metafont specifically isn’t used much anymore, but the quality of digital typefaces is much, much higher now. Computer Modern is kind of an ugly font by comparison. The rest of the TeX stack is still heavily used in academia.
IMO many of the imperfections of TeX are optimizations that overfit 70s computers and predate a lot of programming language know-how. Knuth had to get his side quest done relatively expediently with the technologies that were available to him. The more you learn about the underpinnings of TeX, the more clear it is that it was driven by the limitations of the time. Also, my impression is that the way TeX was written (as a literate program) ensures that it is difficult to refactor into a new system, for the same reason it would be hard to rework a novel into a different novel of the same quality. I would expect that if you loved TeX enough to want to understand this and even maybe work on it, you would also appreciate that “novel” so much, you would be disinclined to mutilate it.
I think the lack of a compelling ground-up successor has a lot to do with the fact that the work is fairly tedious to do and nobody else has had the right combination of attention to detail, skill and need. A big impediment to adoption is that TeX documents are macro-driven and conflate “document” with “processing,” making it essentially impossible to have a successor that is both backwards compatible and a meaningful improvement. The majority of TeX users see it as a necessary but undesirable part of their workflow and have a high cost to switching to something else—for instance because the journals they publish to demand it and would need to support the successor as well as TeX. It would have to be at least a great deal easier to use, while also supporting their existing workflows somehow.
The real successor is probably actually HTML, in a “worse is better” kind of way.
Have you looked into SILE?
https://sile-typesetter.org/
I heard of it some time ago but I haven’t used it personally. I’ll check it out, thanks!
A related paper is Meta-Font, Metamathematics, and Metaphysics: Comments on Donald Knuth’s “The Concept of a Meta-Font” Hofstadter, Douglas R Visible Language; Fall 1982; 16, 4; ProQuest pg. 309:
https://www.m-u-l-t-i-p-l-i-c-i-t-y.org/media/pdf/Metafont-Metamathematics-and-Metaphysics.pdf
Aside, for KeenType, my modernization of the New Typesetting System, I tried using Knuth’s original Computer Modern (CM). I switched to BaKoMa because there was no simple way to extract the font metrics (tfm files) from CM. One of the stumbling blocks was how BaKoMa shifted code points away from Knuth’s CM.
I love what’s possible to do with metapost, the family of languages is quirky, bit also surprisingly powerful.
In my opinion its low popularity is also partly due to the fact that the language is based on macro expansion, which can make its behavior a bit tricky to debug. And (maybe that’s due to its age) the fact that variable scope is quite unpredictable does not make it easier to use. Nevertheless, the language design is really focused on making graphics and for that it can be a very concise format for describing it.
Current development of the potential successor to metapost is happening within the ConTeXt project; it’s called luametafun (PDF). It means that it can be controlled from the Lua side and has some interesting developments.
Another interesting program that diverges a bit from the metafont spirit is the racket library metapict. I think in general a scheme is more suitable to a macro-based program, but I haven’t really taken a serious look at it. Also since it’s much younger by comparison it simply has less documentation and examples available.
Finally, one thing I’d love to have is the ability to also have a pen stroke that can change while drawing a curve or line (so it has a time parameter). This would more accurately reflect how you actually draw something on paper, where you can e.g. rotate the pen while drawing a curve. Maybe that would make it possible to specify the letter S as a stroke instead of an outline.
Another thing that would be nice is support for three dimensional structures, but that would most likely make the equation solver much more complicated. (I know that there are some implementations but they all seem to diverge significantly from the metafont family.)
Do you know how Chinese ideograms are drawn with metafont? Chinese and Japanese calligraphy makes very heavy use of varying pressure to narrow and widen the width of brush strokes. I can’t imagine a stroke-based font rendering system being able to render these characters well without the functionality that you describe. It’s easier with an outline-based encoding because you can use curves to describe the narrowing and widening of brush strokes.
METAFONT supports drawing an outline and filling it, so though variable width strokes are not supported natively, there are various macros (including one in the METAFONT base) which will take a path specification coupled with width information to produce the outline for you.
Here is a brief description I found of the built in one: https://tex.stackexchange.com/questions/341495/change-rotation-of-metapost-pens-dynamically-while-drawing
And here is post about a MetaPost library for drawing beautiful physics textbook illustrations, which uses offset bezier curves to vary the width of strokes: https://habr.com/en/articles/454376/
The illustrations in that blog post are amazing. A shame the book never happened.
As far as I know that is exactly something that’s not possible with metafont and the likes. The system itself is not really used for rendering though, only for the creation of the font.