Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 3.2K All Categories
- 5 Introductions
- 2.5K Typeface Design
- 417 Font Technology
- 814 Technique and Theory
- 339 Type Business
- 317 Type Design Critiques
- 426 Type Design Software
- 29 Punchcutting
- 65 Lettering and Calligraphy
- 41 Technique and Theory
- 24 Lettering Critiques
- 253 Typography
- 179 History of Typography
- 74 Education
- 365 Announcements
- 60 Events
- 76 Job Postings
- 107 Type Releases
- 121 Miscellaneous News
- 186 About TypeDrawers
- 41 TypeDrawers Announcements
- 80 Suggestions and Bug Reports
Introducing Trufont, World’s First Native UFO3 Font Editor (& fully cross-platform)
Dave Crossland
Posts: 1,049
Comments
But it seems you found it, John. Thanks for your interest.
The website will pack this information when I get back to working on that.
Congratulations! It must have been a busy 5 months of development, I reckon, and it must be great to see the first edition officially released now. Just curious: did you write all the code in Python (using for instance Trolltech's QT Designer or so)? And because Dave started this topic: will Google finance the further development of your tool?
F.
Thanks!
Yes indeed.
All the code is written in Python as you can see in the repository. I used a text editor (Notepad++ and then GitHub Atom) and a Python interpreter to write it.
Trolltech does not exist anymore. Since the split from Nokia in 2012, the company that develops Qt is Digia Plc (under its subsidiary The Qt Company).
Not that I know of. Note that, as a student, I cannot work on this fulltime.
If there are people out there willing to hand me money, it is greatly appreciated. I don't have any payment infrastructure setup just yet though.
This is what it takes to add a dropdown with a new attributes stored in the files and fonts. This includes a couple hours research to figure out where all of this is happening and a couple of following patches to fix what does not work.
With the current tool, it takes just a couple of lines and a couple of minutes to do this.
The core problem of FontForge is tha it was developed in C, which is not an object-oriented language. George Williams indicated on his website that he found object-oriented too cumbersome and that C++ was badly specified – the latter is true but not even a large company would make a 220kLOC app entirely in C (robofont is 100kLOC according to Frederik's talk, trufont is 15kLOC at the moment), or it would at least require a very strict code styling and review process, which FontForge doesn't. It all works with large structs that were patched and extended as the program goes – this just shows how you're shooting yourself in the foot when doing such an app without OO. Also, C is extremely low-level and gives you little abstractions. A C code is full of NULL checks, it doesn't have destructors so it's full of memory leaks as well, then FontForge is doing things like carrying function pointers in structs which makes debugging extremely hard. Mind you that in its 12 years of presence, FontForge was maintained daily by George Williams. Almost every day, someone would report a bug/crash that George would fix pretty much immediately. For us today we're not working at all regularly on it and we have to figure out, in an often-crufty code, what is happening! Also, the 220kLOC of FontForge include e.g. a Unicode and http implementation that are a bit hackish just to get the things running, a custom-written GUI toolkit that is also (besides being non-native on Windows and OSX) "badly"-written and full of crashes and does not have nice APIs. All of this was supporting code that he wrote to get his program running so they don't have nice APIs and all like a library written for its own sake. All of this we have to maintain.
Often in the beginning, I thought most of the crashes I was fixing were caused by code changes in the 2012–2014 period but no! doing a git blame it was often a whole section that hadn't been modified since 2003 to 2007! How come it worked is the question you're asking to yourself when you're working with a C/C++ compiler that permits any sort of unchecked memory access (when you mix all that with the bad code style, the code not properly architectured with objects and all it all just becomes toxic).
Imagine that, every part of the code is prone to errors that were never noticed before and every code that very code calls is also located in the tree and might also be part of the error you are getting!
I'm not bashing the developer as the work done is giant and impressive, but as far a lessons to take go I'd say just don't do it as it was in FontForge, it is impossible to maintain especially in an open-source environment.
The software I am making uses an externally made/maintained GUI toolkit with greatly thought-out APIs, the language I am programming on has a huge standard libraries with many things I can rely on, I have a clear and simple code-style (I would say you have to try hard to have a bad code style in Python) and that's it. The things that work in my program, I can reasonably say they won't break unless I do a code change that packs regressions, and even if that happens, the faulty code would be rather self-contained (object!) and very easy to locate.
The goal is to make a font editor. But it's also open-source and people are free to make pull requests, though I'd like to leave advanced features/design aids to extensions or separate programs and have only the core in the font editor (incl. kerning). So adding extension support is one goal as well.
By the way I don't really know what feature-parity with FontForge means. FontForge does so many things, not all of which are needed in 2015 or in a UFO editor given the software ecosystem there is. It also doesn't do things that modern font editors do.
I recall that around the time Dave’s been pushing collaborative mode in FontForge, there was this interesting Typophile thread on the issues with the whole project and its future directions. It would give a nice background to why those forks happened (there was another fork around that time by Matthew Skala, FontAnvil), but as you all know the site is ‘temporarily’ down.
My guess is that the Trufont 1.0.0 release will not only be more or less feature-complete compared to RoboFont, but will go beyond that with its 'batteries included' or 'core' extensions (that may live in github.com/trufont) so that it isn't offensively barebones to designers.
My personal goal is to provide the world with libre font editing tools that are suitable for producing high quality fonts.
I presented "Goodbye FontForge" at the Libre Graphics Meeting in Toronto earlier this year, citing the reasons Adrien has given above for moving on from that project.
Well no, I think this saga is very relevant to explaining why Trufont is now before us
In the 2006-2009 period I learned and used FontForge as a user, and contributed with bug reports and feature suggestions; I graduated from the MATD using only libre software; mainly FontForge.
In 2010-2012 I did not use FontForge much, and George Williams more-or-less moved on to other hobbies, and development slowed. You can see this gource visualisation video.
In 2012 I co-founded the Crafting Type workshops project, and in preparation for the first workshop I contributed to FontForge in a 'product manager' role, doing fund-raising and hiring freelance software developers to make the improvements that I saw as 'low hanging fruit' to make it more useful for typical type designers - new installation packages for Mac OS X and Windows, better toolbar icons, better layers palette, and other things requested by workshop participants.
I was advised in 2007 by Raph Levien, and again in 2012, not to bother enhancing FontForge and to start something new and clean; Raph had made a few attempts at this, I guess around 12, 8 and 2 years earlier, with GNOME Font Editor
ppedit (the initial Spiro editor)
and then fontly (the web based font editor he demo'd at ATypI 2011 in Iceland (liveblog notes, sadly no screenshots as it was never seen again.)
Around this time I was also aware that Lasse Fister had added a iPython console to FontForge to make developing python extensions for it easier; but he had given up on FF. He'd then begun to make a web based font editor by writing the foundational ufoJS library, but never started work on a full web-based font editor.
I assume the author of BirdFont was also a FontForge refugee, as that is written initially for libre desktops, and I know that the FontClod guys were for sure; but all these other libre font editor initiations didn't lead far. Also at this time Matt LaGrandeur was working privately on what is now http://glyphrstudio.com - a full web-based font editor.
BirdFont and Glyphr as about as complete as trufont is today, but trufont is the only one made by a type designer with a "turning pro" attitude.
All these attempts that had fizzled out contributed to my view, at the time, that working incrementally on FontForge was more likely to result in being able to produce high quality fonts using only libre software than starting yet another one.
After 14 months at the end of 2013, I published 15-things-that-improved-in-fontforge-this-year with an overview of these improvements. One of the bigger low-hanging-fruit was to re-organize the pull down menus - a pretty small code change, but a huge improvement in ease of use - and I regret not pushing harder to complete this at that stage. Instead I moved on to adding a couple of larger improvements, real time collaboration, Glyphs-like multi-glyph editing, and UFO support. For exactly the reasons Adrien has described, adding bigger features took a long time and was not a good experience.
As you can see in the gource video, my efforts to improve FontForge in this period were successful at bringing together an active developer community, of which Adrien was one of the most active members. There was also some failure on the flip side of this, as 2 of the most active contributors in the 2007-2012 period, Barry Schwartz and Khaled Hosny, very soon had irreconcilable disagreements with me about what to change, and so they forked the project into sortsmill-tools; they expressly did not want anyone else to contribute to their project, and did not want to spend time discussing what to do or if work submitted for inclusion should be included now or later or never.
So after the bad experience with making bigger changes, by the end of 2013, I figured that a new font editor was unavoidable. I thought it ought to be a web app rather than a desktop app.
However, I was also not keen to work on a basic font editor. We have plenty of those, including FontForge, and with UFO we are able to somewhat easily move between tools. So I wanted instead to attempt to attempt something really new.
In early 2013 I'd met Simon Egli, who later that year made an initial PHP prototype for a successor to metaflop, and then a second prototype with Python called mfg. This led in early 2014 to a third project, with Simon and Lasse and Peter Sikking: Metapolator.
Today I'm sad to say that I'm not all that happy with how Metapolator turned out; for myself, I think I was too ambitious, and tried to make the project go fast. By the end of 2014 we had a lot of pieces, but not a joined up product: a lot of great ideas from Simon and the other designers he invited (Wei and Nicolas) that went into a detailed UX design from Peter; and a powerful CPS engine led by Lasse all up and running, entirely web based; but not a product useful for type designers. So over this year, that product has been taking shape, mainly thanks to the implementation efforts of Jeroen Breen, and now there's a demo online. But the demo is not (yet) compelling... and I'm not sure when it will be. Maybe never.
So I think my idea to "start at the end" on a tool that is really new, rather than "starting at the beginning" with an classic font editor built on ufoJS, was a mistake; and perhaps making font editors on the web platform is a mistake too.
Certainly from his actions, and from our chats, I gather that Adrien would agree
So, that's a summary of the saga so far. Where it goes, we'll have to see... I expect to spend 2016 focusing on contributing to Trufont to see how far it can go. It may be that Metapolator ends up as a Trufont extension, rather than a web based application.
This year I started to work directly with Khaled on providing the world with high quality libre Arabic fonts, and I'm hoping that when the extensions system is ready, he'll join the Trufont effort and develop tools for complex script development.
And for FontForge, last year the UFOv2 support was massively improved, with some v3 support; and this year Pathum Egodawatta (whose work Thomas Phinney presented at Granshan, and who started the MATD this year) started a foundry in Sri Lanka this year, making a few Sinhala + Latin libre font families in collaboration with Sri Lanka's only other foundry, and were using FontForge extensively. As part of that work his company undertook the pull down menu reorganization, and I hope an upcoming release of FF will ship that work.
Although I’m quite sure that there will be people in the fast growing font-development community that will be very happy with a powerful open-source (read: free) font editor, I’m not so fond of the shopping-around tendency when it comes to its development. I don’t believe that Frederik and Georg ever had the idea to create prototypes for open-source competitors when they developed RoboFont and Glyphs respectively.
If Dave uses his pockets full of money to support Trufont, and the program looks and behaves like RoboFont combined with stuff from Glyphs, then it will become difficult for Frederik and Georg to get a proper return on their investments. If font developers want to convince their potential customers that it is normal to pay for an original product of which the development requires a lot of skills, knowledge, time, and patience, they should be willing to support the people who develop original tools for the production of these fonts too. I think that Trufont should become a unique font editor that provides additional value to the existing ones.
Recently a renowned colleague wrote me that he would stop buying OTM if an open-source version of the program would be released. If that happens, it will become difficult for us to compete with a free clone of our tool, I reckon.
However, I do think you are being a little high handed... I spent the last 2 years focused on trying to do something really new and unique with Metapolator; your quote specifically ellides the real time collaboration capabilities which - so far - are seen nowhere else; and you don't mention your own involvement in a few other innovative libre font tool projects of mine, such as your collaboration with me and Pippin on the libre font tool Kernagic, and your collaborations with me on the libre autohinter ttfautohint.
The 2 things you mention seem to me as totally fair for all other editors to implement. The whole idea of UFO as an interchange format is that many fonts editor applications support it. Editing glyph outlines in the same window as you space them has been popularised by Glyphs... but, as far as I know, this idea was originally proposed by Mark Simonson on the Typophile forum in 2003 - http://typophile.com/node/189 - with this mockup:
I don't think they have much to worry about; FontLab v6 surely poses a much greater threat than Trufont, and even then, in a commodity market branding is everything.
Glyphs' brand is very good, thanks mainly to their excellent and attentive customer service. RoboFont hasn't seen a point release for a while - last two were in 2013-01-14 and 2013-10-07 - and the "no previous knowledge" politics does not fare well in the customer services department.
And they do, and I expect they'll continue to do so. FontLab 6 is explicit in their marketing that they expect (and are working to conveniently be) an interoperable part of all high quality font development workflows, alongside other tools. The days of Fontographer or FontLab or Ikarus being a one-stop-shop are long gone.
Additionally, most font developers supporting RoboFont are doing so by releasing a lot of libre-licensed extensions on Github; Frederik and Georg both have active Github accounts. Your assertion that contributing to libre licensed tools is acting against the interests of proprietary tool developers seems a bit strange to me
But this raise the question of the main target audience for such a project, which are probably students, and does it worth the effort? Students needs are limited, and temporary.
I agree with Frank that the project better have a unique additional value that answers a solid need and audience, otherwise your efforts are somehow wasted.
People like myself who want software freedom in development, reliability and support of software can not get what we want from proprietary software, so all efforts to develop libre font tools are worth the effort ipso facto.
I guess I just don't understand what it is that you cannot get from proprietary software, other than "free". One gets what one is willing to pay for; it has always been that way. Otherwise there is little or no motivation for software developers to continue to make their product better.
I have looked at libre products in other areas in the past and while I was impressed by the effort involved on the part of the programmers, the end result was not as good as that of commercial versions. Profit is the best driver.
The remedy for not having a dedicated paid support stream is having a fairly large expert user base. Figuring out how to build that community is a big factor of success from most—not only GUI apps—open source project.
I don't think that I'd get on board with profit being the best driver in software development—I think that it's debatable given the range of form software takes—but I have similarly been underwhelmed with the polish on the (other) GUI OSS that I've used in the past.
Still interested to see where this goes.
So that said, I might be able to shed a little light:
George Thomas says:
"I guess I just don't understand what it is that you cannot get from proprietary software, other than 'free'."
If you mean a price of zero, I've yet to get that with any open-source software I've ever used. Money is money and PRICE is just a part of the COST of obtaining and using a tool.
Over the past four years I have spent hours and hours trying to install FontForge in Windows and have never, ever gotten an installation that didn't crash constantly. I gave up. On Mac, I recently spent a few hours over a period of days getting FontForge to install because the latest version had a compatibility issue with the version I had of some other software that FF was dependent upon or had to co-exist with, or something.
I tried a previous build of FF, and all was OK.
Finally.
But there certainly was a cost.
And this brings me to my main criticism of open source software as I have experienced it: it seems crafted with the assumption that the user is at expert level and is programming-savvy. I feel like I need to know a secret Unix handshake to get the stuff working and I just don't.
Now, I've done a lot of scripting for the Windows command line, the Windows Script Host, and JavaScript for front end web development, and I'm a schooled network engineer, and I learn because I can and I have to.
But there is no reason why an open-source product should not be offered with the same level of polish and concern for the average user as is a commercial piece of software.
Too many kinks. Too much taken for granted, and I get angry about it.
On the other hand, I happen to find the proprietary OTMaster very easy and convenient to use for a lot of things. I just paid for an upgrade to version 5.0. It installs easily and it does reliably what the makers of it say it will. I also have Glyphs, which is a proprietary tool and also works very well. However, in the case of Glyphs, as primarily a Windows user who prefers working in Windows, there is no Glyphs for Windows and probably never will be and there is no "you get what you pay for" equation at work for Glyphs. It is what it is because the customer base for Glyphs are primarily Mac users. It's a take-it-or-leave-it proposition that works out fine for the makers of Glyphs, but not so good for me and other Windows users. Really nice product, and I've already gotten a second email reminding me of where to go for support! Smart. You don't get that with open-source stuff. But why the f**k not? Why do they stop short?
(There is a big issue for a lot of users with regard to "who's standing behind" an open-source piece of software, but I'm skipping that.)
Dave says:
"People like myself who want software freedom in development, reliability and support of software can not get what we want from proprietary software, so all efforts to develop libre font tools are worth the effort ipso facto."
Dave prizes the ability to freely change the code without government interference through patent or copyright laws above all else.
That's not a crazy stance at all. Ask somebody who owns a VW diesel car for which no outside entity could legally inspect the software code for fear of prosecution under the DMCA. (Digital Millenium Copyright Act) It was and is, incredibly, against the law for a driver or anybody to reverse engineer the code controlling the vehicle.
Slippery slope analogies, anybody?
Being relatively new, it wasn't so long ago that software code was not even considered copyrightable expression.
Maybe it should have stayed that way.
(And over the years, as the courts have grappled with the idea of code as "expression", little of the code in any software product will be found copyrightable, BTW. Software makers can benefit from copyright protection, yes, but the kind of copyright is what's come to be called "thin copyright". The competing software maker has to be offering an exact match, or close to it, to be held as an infringer.)
Anyway, off to install Trufont!
Me too. That is such a coincidence.
If one is willing to pay for sequential re-enactments of previous tools, with freeness being the major unique and original new feature, it's only rational to assume the target is not even tools. So I'd like to Test the free fonts and the free tools, just reading and writing open source fonts of various kinds.
Consider the times you've experienced a crash in a program that went unfixed longer than you wanted, or had an idea for a feature of a program that has never been implemented.
Sure, you can get along with those negative outcomes, say to yourself "well, I paid my fees and this is what I get, I take it or leave it." But it kind of sucks, right?
Most people are willing to go along with that arrangement until the crashes or the bug or the missing features become really annoying. Then what can they do?
Today in our community, some people are petitioning Adobe to add what they see as 'missing features' for font OpenType Features. How do you feel about that?
For the last few years, many people here have been asking FontLab Inc to fix crashes in FL5. What was that like?
Why do those negative outcomes happen? I think that they happen because the developers have a monopoly on those programs; only they can decide when a crash is fixed or when a feature is added. They are totally, 100% responsible.
Which leads to your next point:
There has been little or no motivation for Adobe to make OpenType Font features conveniently accessible to users; there has been little or no motivation for FontLab to fix bugs knowns about for years.
Sometimes proprietary software is available without a fee, and sometimes libre software requires a fee to access a copy.
You got what you paid for, and that was it. RoboFont calls this being a "victim" in its design principles.
What I want to get is the ability to get involved in how my tools work, so that when those inevitable moments arrive when I want the tool to work in a way that the developers are not providing, then I can take personal responsibility to get what I want to happen, happening.
That kind of ability is a particular one, I think accurately called freedom.
I'm going to nit-pick here, because I think your phrasing raises an important point. You say "the end result," as if the program was never going to need to be changed ever again.There is one program I am aware of that is at that 'end result' stage, Donald Knuth's TeX: it has not had any bugs identified in years, and works exactly as it was specified and is documented. But the world is always changing around us. Other pieces of software are being written that each program could be combined with. But if there is a monopoly on development, can it? This is not a technical question; it is a social question, "who decides?"
If TeX was not libre, I doubt that it would ever reach that 'end result' stage. And because it is, its 30+ year history continues: The original TeX can't interface with OpenType fonts, so a version of it was made that can, XeTeX. But in turn XeTeX can not easily typeset multi-script documents, so the SILE project was started; a clean start that yet still includes parts of TeX.
So an important point about why tool freedom matters is that a tool's utility value isn't just what it can do today, but what its future/potential utility can be. If only one person or organization can decide, that is not a market monopoly, but a monopoly de facto.
But really your point here is that in your experience, the overall result of libre programs is not as good as proprietary ones. I can agree that the overall result of many software projects is less than satisfying, but for me the balance is in favour of libre ones. All too often I want to do things that the program can not yet do, and through somewhat bitter experience I have come to the conclusion that there is a principle that tools I use ought to be libre.
Many libre software projects are developed for-profit, though
The greatest thing about a capitalist mode of production where companies offer customers something they want so much they will pay enough that the company is profitable, is that focus on what users want. The problem for users is about the monopoly on development this often entails.
But for-profit development isn't incompatible with libre software development. Many libre software projects are developed for-profit!
Red Hat Inc is the largest example of a for-profit company like this; it is public traded on the NASDAQ. The business model works just like one that many proprietary software companies use: users pay a subscription to the developers, and the developers earn the money by developing software that users want. Happy customers continue to pay, unhappy customers shop elsewhere.
I very much hope that someone starts a business developing TruFont like that.
Jack said,
When I was studying to be a designer, I expected to have revenue from clients for whom I would perform design services, and I planned to use some of that revenue to hire people with programming skills to make the changes that I wanted.
Jack, you're an active user of RoboFont. Are you completely happy with it? Are there things you think that Frederik will never fix or support?
I must admit that I rather bristle when people paint the idea of software freedom being a wooly, abstract, impractical concept. To me it is an entirely practical thing. If all else is equal, who would prefer a proprietary tool to a libre one?
Of course I understand, as stated in the design principles, that RoboFont is built as a platform. "The extensibility of its object model allows a designer to build whatever they can think of on the base of RoboFont." Therefore some RoboFont users might say that it doesn't matter if Frederik will not fix or support something, because one can write your own version of whatever you need that runs inside RoboFont.
The problem I have with this is that for some things, I would need to have access to the internals of RoboFont; this things are not available to each user, only to Frederik. A few years ago I discussed this with Frederik and he kindly said that, well, in a real situation like this I would only have to email him and he'd share the source code I needed. That's a wonderful offer, but what if he says "no"?
I hear RoboFont users complaining about the speed of the program in various ways. I suspect that it isn't possible for RoboFont users to improve the speed, without complete access to the source code. However, TruFont is built with PyQt5, so it should be able to fix all speed problems that arise.
In the FAQ there are a number of questions to which the answer is simply and firmly, "No." Chief among them is if there'll ever be a version of RoboFont for computers running something other than Mac OS X.
Adrien runs Windows, and doesn't want to use a Mac. Thus, TruFont.
The following story has illustrative value, I think, in keeping with the discussion of Trufont and open source font tools as that discussion has unfolded in this thread.
Not so long ago, I had a great desire to create a new tool for fonts using, as a basis, proprietary software from Monotype. I needed a way to make compressed EOT files using Monotype's proprietary MicroType Express (MTX) technology.
The tool that Microsoft was offering for the purpose, named WEFT, was a piece of abandonware, unworkable in a production environment. And Microsoft seemed totally uninterested in making better tools whether or not EOT was adopted as the standard webfont format or not. The ball was in Monotype's court.
Being able to make an EOT in a production environment was critical:
At the time, everyone involved in the negotiations at the W3C - negotiations which ultimately ended up crowning WOFF as the standard format for webfonts - everyone involved assumed that Monotype held all the legal cards because of Monotype's patent on the method for making EOTs. And that without licensing from Monotype - which Monotype could refuse - webfonts that worked with legacy versions of Internet Explorer was simply not a practical proposition. Such a situation would, unfortunately, set "fonts on the web" back years and years because without a practical tool for creating EOT's you couldn't deliver the font to any of the legacy versions of Internet Explorer.
In the world of patents and copyright, things are often not as simple as they seem - a fact which works to the supposed rights-holders advantage every time. I remember talking to Dave C. about it at the LA Typecon some years ago. As I was searching for ways around the patent restrictions.
The practical effect of Monotype's patent on MTX and therefore EOT sent a chill wind through the proponents of open source. It gave Monotype a sword of Damocles which they promised to remove by taking MTX public domain, if EOT was chosen as the standard web font format. But it still smelled like an ultimatum, and I really, really don't like ultimatums. The prospect of waiting years more for fonts on the web was unacceptable.
The solution I came up with was a Windows command-line executable called EOTFAST.
It did indeed use the proprietary software mentioned above and I did not need a license from Monotype to do it.
How was I able to do that? Simple - I did some homework. There is a principle in patent law called "patent exhaustion". What that means is that those who license their technology are not entitled to double dip. If a company that makes pencil sharpeners licenses a patent from another company to use their patented rotary wood sharpening blade system and incorporates it into their product, that company cannot then, in turn, ask you - as a customer who bought the pencil sharpener - to pay extra to license the blade system. It came with the initial purchase. The deal is done. Finished.
As lawyer and legal scholar Douglas E. Phillips explains in his book, "The Software License Unveiled":
Similarly, having bought and paid for a license for Windows, you're perfectly free to make use of the dlls that control the making of an EOT. No further license necessary. (I also found out that EOTs were not only supported by IE but Powerpoint and Word, as well.) The software necessary to create them was already in Windows. And as long as you did the work within the scope of your license for Windows, there wasn't a damn thing Monotype could do or say about it. They had exhausted their rights by licensing the technology to Microsoft.
As a courtesy, I sent an email to Si Daniels and Microsoft's rep in the CSS fonts group, Sylvain Galineau, (working for Adobe, last we spoke) and I explained the situation and released the product.
(For the record, it was the legal baggage related to how EOTs handled the embedding restrictions that made it unpalatable to the majority. The compromise of Woff gave the font producers their "garden fence" against unlicensed use without that baggage.)
Now, to turn to matters of marketing : rather than just slap EOTFAST up on SourceForge or wherever, I decided to give it the patina of a "professionally" made product. I say "professionally" facetiously because it certainly was professionally done. I took a .com domain name for it. I gave it an icon. Good documentation was provided. It was all zipped up nice.
I just don't know how to present a product any other way. Ok, so it's free. But you still gotta dress for success, it's a matter of pride.
And that's the story of EOTFAST. Which I still use constantly today.
A few years down the road, to their credit, Monotype did publish a universal release saying that anybody who wants to is free to use the MTX technology. And so it turns up here and there in non-Windows spaces like the Font Squirrel Generator, to name one.
Lastly, Dave mentioned Red Hat which markets its products and services at the same level as companies selling proprietary software solutions.
After thinking about it, another company that figured out how to market itself and its products to compete against proprietary software financed by monster companies like Microsoft, is Mozilla. They built brand names. They presented themselves in the marketplace in a way that builds user confidence. I just wish we saw that with some of the smaller projects in the open source community more frequently.