What’s happening with FontBakery? Is Fontspector the future?

Typedesigner
Typedesigner Posts: 67
in Type Design Software

Hello everyone,

I recently came across a note on GitHub mentioning that FontBakery is gradually being phased out, and that Fontspector is the future of font quality assurance. It’s recommended to migrate to Fontspector, as FontBakery seems to no longer be actively maintained.

Currently, there also seem to be issues with installing FontBakery, particularly under Python 3.13.7, which has caused frustration for many users. This raises some important questions for me and others:

  1. Is FontBakery still being developed? Will there be any updates or official support for newer Python versions? Or can we assume that FontBakery is being gradually phased out?

  2. Fontspector as the new solution: What steps are needed to install and use Fontspector on personal systems? Is there a detailed guide for installation and integration of Fontspector into workflows? How does Fontspector differ from FontBakery in terms of usage and functionality?

I’m sure many of us who rely on FontBakery share these questions. Any answers or further information would be very helpful, especially as we may soon need to transition to Fontspector.

Looking forward to your thoughts and experiences!

Tagged:

Comments

  • John Hudson
    John Hudson Posts: 3,500
    There’s a web version of Fontspector that is probably the easiest way to work with it. If you want to install it locally, you can either grab binaries from the project release page or install using cargo-binstall. Depending on your platform, you may need some dependencies preinstalled, as explained in the repo readme.
  • Typedesigner
    Typedesigner Posts: 67
    edited September 6
    Thank you very much for this information.

    Does anyone know who owns or operates the website https://fonttools.github.io/fontspector/ ?
  • mitradranirban
    mitradranirban Posts: 99
    Typedesigner said:
    Thank you very much for this information.

    Does anyone know who owns or operates the website https://fonttools.github.io/fontspector/ ?


    It is run by developer team of fontspector themselves
  • Thomas Phinney
    Thomas Phinney Posts: 3,082
    Specifically, Simon Cozens is the lead developer of Fontspector, and Felipe Sanches was long the lead for Fontbakery.

    Development of both was primarily funded by Google, though many other folks have contributed, either as work for an employer, or on their own.
  • Typedesigner
    Typedesigner Posts: 67
    edited September 7

    The description of how to install Fontspector is difficult to understand. The target audience of this guide must be very familiar with Rust and possibly programming. However, this is not the case for users of FontLab 8 and Glyphs 3 – i.e., type designers – unless they are font engineers.
    https://github.com/fonttools/fontspector?tab=readme-ov-file#running-the-cli-tool

    It would therefore be desirable to have a detailed step-by-step guide, similar to FontBakery, explaining how to install Fontspector.
    https://fontbakery.readthedocs.io/en/latest/user/installation/install-windows.html 


  • Simon Cozens
    Simon Cozens Posts: 804
    John Hudson said:
    There’s a web version of Fontspector that is probably the easiest way to work with it. If you want to install it locally, you can either grab binaries from the project release page or install using cargo-binstall. Depending on your platform, you may need some dependencies preinstalled, as explained in the repo readme.
  • mitradranirban
    mitradranirban Posts: 99
    fTypedesigner said:

    The description of how to install Fontspector is difficult to understand. 

    It is a two step process 

    First install Rust and Cargo as per instruction given in https://doc.rust-lang.org/cargo/getting-started/installation.html

    Next go to a terminal and run 

     cargo install fontspector

  • Typedesigner
    Typedesigner Posts: 67
    edited September 7
    Unfortunately, this description of how to install Fontspector is incomplete and leads to an error. How can this be fixed?
  • Simon Cozens
    Simon Cozens Posts: 804
    I'm not quite sure why you're double-posting your comments both here and on the fontspector issue tracker; it isn't helpful.

    The first step in the install instructions reads:
    You wanted a way to install that's similar to Glyphs and Fontlab - well, there you go! Just download the software and run it; I'm not sure why you've got yourself in a position where you're trying to compile it. If you found that step hard to understand I would appreciate suggestions as to how to make it clearer.

    And as mentioned twice above, for non-technical people who don't want to be messing around with command line software, the easiest way to use fontspector is through the web interface.
  • Typedesigner
    Typedesigner Posts: 67
    edited September 7
    Simon Cozens said:
    I'm not quite sure why you're double-posting your comments both here and on the fontspector issue tracker; it isn't helpful.

    The first step in the install instructions reads:
    You wanted a way to install that's similar to Glyphs and Fontlab - well, there you go! Just download the software and run it; I'm not sure why you've got yourself in a position where you're trying to compile it. If you found that step hard to understand I would appreciate suggestions as to how to make it clearer.

    And as mentioned twice above, for non-technical people who don't want to be messing around with command line software, the easiest way to use fontspector is through the web interface.

    Unfortunately, fontspector.exe cannot be installed on Windows 11. When you click on it, a window briefly opens and then immediately disappears. The software is simply unusable.

    I recently attempted to use the web version of Fontspector (https://fonttools.github.io/fontspector/) but noticed several concerns regarding transparency and data protection. Specifically, I observed that there is no imprint or privacy policy on the site that complies with the requirements of the General Data Protection Regulation (GDPR).

    In this context, I have a few questions regarding data processing and potential tracking mechanisms:

    1. Data Collection: What data is collected by the web version of Fontspector? For example, is the IP address of users recorded during their visit to the website?

    2. Cookies and Tracking: Does the website use cookies or other tracking technologies? If so, what information is collected through these, and how is it used?

    3. Data Sharing: Are any collected data, especially font metadata, shared with third parties or used for other purposes?

    Since the website does not provide clear information on privacy matters, I would appreciate a detailed response to the above questions. Specifically, I am interested in how the website complies with EU data protection requirements (GDPR).

  • Simon Cozens
    Simon Cozens Posts: 804
    The reason there is no privacy policy or data processing statement is that no data is gathered or retained at all.
  • mitradranirban
    mitradranirban Posts: 99
    edited September 7
    Actually in the fontspector website nothing is uploaded, the whole program runs in your local browser, your font file is not uploaded anywhere and stays in your computers memory. The tests run in your browser to give you the result so no privacy concern at all 
  • John Savard
    John Savard Posts: 1,189
    edited September 8
    Although, as noted above, FontSpector is far superior to FontBakery in every way... I take it that it was easier to install FontBakery on a Windows system. If, however, FontSpector runs "entirely in your browser", it would seem like it ought to be possible to locally host the web version of the program on any operating system.
    But in that case, how could the web version of FontSpector still be compiled Rust as opposed to JavaScript (or ECMAScript)?
    EDIT: Pardon my ignorance. I did a brief web search, and I now see that something called WebAssembly is involved.
  • Typedesigner
    Typedesigner Posts: 67
    edited September 8
    Universal (community best practices) - Can you explain who set this profile on Fontspector? How does it differ from other profiles?
  • Thomas Phinney
    Thomas Phinney Posts: 3,082
    Same set of tests as Fontbakery. Same profiles. (Modulo perhaps a VERY few brand new tests since Fontbakery has been winding down.)

    Basically, everything that all the major players doing profiles, wants in their profile? Those are in the universal profile. So things that Google, Adobe, Microsoft, Dalton Maag, etcetera all wanted.

    Stuff that at least some major players disagree on whether it should be universally checked in normal fonts? Not in the universal profile.

    Overall, the process is managed by Google; they are funding the tool. But there are serious and genuine efforts made to “keep everybody happy,” and (for example) when Adobe split off to do an “openbakery” tool instead of Fontbakery, many folks involved viewed that as a failure of process and/or communication.

    And not EVERY font is expected to pass every test. For example, with Vassil Kateliev I do the fontification of Google’s icons as variable fonts, public version is called Material Symbols. There are a few standard checks in the Google profile that it won’t ever pass, and that is OK!
  • Typedesigner
    Typedesigner Posts: 67
    edited September 9

    A few years ago, there were promising discussions about integrating Font Bakery directly into applications like Glyphs or FontLab via a dedicated interface. This would have brought its powerful, but for some technically demanding, validation tools into the familiar GUI environments many type designers already use — lowering the barrier to systematic font QA and broadening its reach.

    The idea has not yet been implemented, but it still holds strong potential to improve accessibility in the future.

  • mitradranirban
    mitradranirban Posts: 99
    Most Font editors have some inbuilt checks. Even Fontforge's Validate tools removes most obvious error. But Fontbakery's profiles help in fulfilling exact requirements of font vendors like adobe, googlefonts etc 
  • John Hudson
    John Hudson Posts: 3,500
    @Simon Cozens

    Is there a way to define a custom profile for FontSpector? I presume something like that would need to be run locally, and that there wouldn’t be a way to plug it into the web version?
  • Jens Kutilek
    Jens Kutilek Posts: 382
    John Hudson said:
    @Simon Cozens

    Is there a way to define a custom profile for FontSpector? I presume something like that would need to be run locally, and that there wouldn’t be a way to plug it into the web version?
    That's something I'm also interested in. We have a dozen of our own checks in Fontbakery which are very specific to LucasFonts, so it wouldn't make sense to publish our profile.

    I guess this is the way to go about it, but I haven't really looked into it.
  • Simon Cozens
    Simon Cozens Posts: 804
    There are various ways to do this and I should write it up in the documentation.

    • If you just want to define your own collection of existing checks to run in a particular order, you can write a profile in TOML (e.g. https://github.com/fonttools/fontspector/blob/main/profiles/fontbureau.toml) and run fontspector --profile fontbureau.toml
    • If you want to define your own checks in Rust, you make a Rust crate like https://github.com/fonttools/fontspector/tree/main/profile-microsoft ; it doesn't need to be in the fontspector repository, you just need to be able to compile it as a shared library and it can be loaded into fontspector at runtime. (I think some people have struggled with this and I'm not quite sure why; it Works For Me™.)
    • If you want to define your own checks in Python, this is in theory possible through a crate called fontbakery-bridge. The concept is good and I have used it to run Fontbakery checks before they were ported to Rust. However, I think it probably needs some refinement to work in practice as I'm not sure I implemented a way to load arbitrary Python files.

  • Typedesigner
    Typedesigner Posts: 67
    edited September 13

    Why wasn't FontBakery simply rewritten in Rust?
    FontBakery is already well-established within the type design community. The "cupcake" symbol at the end of the test, crafted from letters by Tony de Marco, is not only a clever touch but also a strong marketing asset. It is memorable and gives the command-line tool a distinctive identity. Additionally, FontBakery's website is informative and user-friendly, with comprehensive help features that make it easy for users to get the most out of the tool.

    On the other hand, the name FontSpector still needs to be made known to the existing FontBakery users, which will likely take some time. Furthermore, FontSpector could be confused with Font Inspector by some users:
    Font Inspector Chrome Extension

  • mitradranirban
    mitradranirban Posts: 99
    Yes, atleast fontbakery.com, readthedocs.io and GitHub site for fontbakery should mention the fact that fontbakery is no longer being updated and is being replaced by fontspector. 
  • Thomas Phinney
    Thomas Phinney Posts: 3,082
    Fontbakery WAS “simply” rewritten in Rust — just under a new name.

    The thing is, that “simply” (hah!) rewritten in Rust means that (unavoidably!) the installation is radically different and there are massive changes in dependencies and installation, and the docs needed to be redone. People are still pointing out legitimate bumps that still need to be smoothed out to make it ~ equally easy to install and use.

    These factors mean, to me at least, there are strong reasons to keep the “Python version” of the tool around and available, and to make the change as strong and clear as having two different names. I still have both installed.

    I suppose they could have called it “Fontbakery 2” in a parallel to what Simon did with his Diffenator tool. But giving it a different name seems entirely reasonable to me.
  • John Savard
    John Savard Posts: 1,189
    edited 1:29AM
    Thomas Phinney said:
    People are still pointing out legitimate bumps that still need to be smoothed out to make it ~ equally easy to install and use.

    From what I've seen in this thread, that's the whole problem with FontSpector, and so once it's fixed, presumably everyone should be happy, given that, otherwise, it's vastly superior in every way.
    I guess it's unfortunate that the functionality of FontBakery is so urgently needed by so many that having to wait for this to happen... or, more precisely, having support for FontBakery dropped before this has happened... has made the transition intolerably bumpy for some. Given that open-source projects don't have huge resources of money and manpower to draw on, though, I don't see how this could have been avoided.
    Although, if the two projects don't entirely rely on the same people, then a way to avoid it probably would exist, by making the FontSpector project do without most of the help it gets from people who worked with FontBakery - the result would be to slow the development of FontSpector down, though, and I presume there are more people who are willing to use FontSpector as it is than there are those who insist on it being as easy to install and use as FontBakery before they're interested, which is why that road wasn't taken.
    EDIT: I should mention that there's one other (theoretically) possible solution, although in my opinion it hardly even bears mentioning.
    An open-source license such as the GPL places restrictions on what people other than the writer of the software can do with the copyrighted software, which they can only use because of the permissions granted to them by that license.
    So there are examples of software available for free use under the GPL, but also available for embedding in commercial products if the fee for a commercial license is paid. And there are also cases where a program, formerly available under the GPL, has changed to being commercial software for its future releases.
    So making FontBakery paid instead of free in its future releases could, conceivably, generate the revenue to allow both FontBakery and FontSpector to be developed at the same time.
    Since FontSpector is available free as a generally superior alternative, though, I suspect the potential user base is much too small to allow that to work.
    EDIT: Although I've proposed two "solutions" to the impasse above that obviously can't work, in fairness I should mention the kind of painless technical solution to the issue that people spoiled by all the open-source software out there were probably hoping for.
    Instead of writing FontSpector from the ground up in Rust, what if instead what was written was a new release of FontBakery where the user interface was the old one, in Python, but its grunt work was done by an engine written in Rust?
    The assumption being that if they did it this way, they could have packaged the result so that the addition of whatever run-time Rust might need (and I saw a statement in this thread that Rust doesn't even need a run-time) would not make installation more difficult.
    I assume this was considered, and there were valid technical reasons that made it infeasible.
  • Thomas Phinney
    Thomas Phinney Posts: 3,082
    @John Savard You wrote “the writer of the software” when you probably should have written “the owner of the software.” If you check the FontBakery copyright notice, you will see that the primary authors are not the copyright holders. The copyrights are mixed, but the biggest holder is Google.

    > Instead of writing FontSpector from the ground up in Rust, what if instead what was written was a new release of FontBakery where the user interface was the old one, in Python, but its grunt work was done by an engine written in Rust?

    Fontspector actually already offers the option to use a Python front end in the way you describe! But it does not remove any of the issues… in fact it ADDS complexity. And it does not solve a usability problem, it is there for other reasons. The Fontspector “user interface” (command line) is not much different. The problem is, Rust and Python are different. The way you install these apps is different. They have different dependencies. These are all due to the initial difference in how they work.
  • Typedesigner
    Typedesigner Posts: 67
    edited 7:42AM
    Thomas Phinney said:
    Fontbakery WAS “simply” rewritten in Rust — just under a new name.

    The thing is, that “simply” (hah!) rewritten in Rust means that (unavoidably!) the installation is radically different and there are massive changes in dependencies and installation, and the docs needed to be redone. People are still pointing out legitimate bumps that still need to be smoothed out to make it ~ equally easy to install and use.

    These factors mean, to me at least, there are strong reasons to keep the “Python version” of the tool around and available, and to make the change as strong and clear as having two different names. I still have both installed.

    I suppose they could have called it “Fontbakery 2” in a parallel to what Simon did with his Diffenator tool. But giving it a different name seems entirely reasonable to me.

    I understand that these substantial technical changes are important for maintainers and users with a technical background. However, a complete rebrand is not warranted by these changes alone if the tool’s purpose and core functionality remain unchanged.

    Retaining the original name would have been the stronger choice for the following reasons:

    Consistent user experience: For most users, the key measure is whether the tool still validates and analyses fonts effectively. If the CLI/GUI workflow and output remain familiar, the underlying programming language is largely irrelevant to their day-to-day use.

    Continuity across versions: Many users still rely on the Python release. A new name could imply a functional fork or incompatibility that does not exist, which would make it harder for users to recognise the connection between the two versions.

    Preserving brand equity: Fontbakery is a recognised name in the type design and font development community. This recognition has been built up over many years and changing it would dilute the brand and reduce its discoverability.

    Implementation details are secondary to purpose. The programming language is an internal detail. The core deliverables — validation rules, quality checks and reporting — remain unchanged, and the name reflects the tool’s purpose rather than its codebase.

    Clear, proactive communication of the rewrite, supported by updated documentation, would have distinguished the Rust version while preserving the identity and trust associated with the original name.


Categories