TYPE DESIGN INFORMATION PAGE last updated on Mon Apr 15 04:46:27 EDT 2024
FONT RECOGNITION VIA FONT MOOSE
|
|
|
|
|
Unified Font Object | ||
|
|
|
|
SWITCH TO INDEX FILE
Adrien Tétar
| |
In a lively discussion in May 2015, Adam Twardoch defends the position that fonts are programs, while Dave Crossland doubts it. The truth is that fonts are not programs. I quote passages from their arguments: Adam Twardoch (MyFonts, ex-FontShop): The general legal assumption (which the other party can challenge, of course) is that digital fonts are computer programs: The type designer uses a font editor to create a computer program, and that process is considered the process of the creation of a work of authorship. The font rasterization engine executes this program snd produces images of characters. Therefore, the digital font is protected just like any other computer program. The digital images the font produces are generally not protected. This method of protection is based on the assumption that the designer places outline points in a creative act and that the individual point placements cannot be automatically inferred from the glyph image. Manually set hinting instructions are slso considered part of the computer program that is protected. In a way, this paradigm of protection assumes that, as a designer, you're using a GUI tool to write a PostScript program by hand. If someone takes your digital outlines and modifies them, the current legal assumption is that it's equivalent to taking the source code of a 3rd party's computer program and modifying it without permission. Computer programs generally enjoy stronger copyright protection than other works, also in Germany. But this paradigm of protection is based on a handful of 20+-years old U.S. court rulings (Adobe vs. SSi), and has not really been verified or challenged in other jurisdiction---so there is just assumption of protection. Dave Crossland (Google): Adam, I know that Adobe folks have been claiming for years and years that "fonts are programs too" but my understanding of the SSI case is that this claim was never substantiated by that court. Indeed, I think its disingenous to claim fonts (by which we assume SFNT fonts) are computer programs. They may contain computer programs - TT hinting instruction rendering programs, and AAT state machine layout programs - but they are mostly data. (I believe the difference is that programs are executed, while data is used as input to a program. In the LISP family of programming languages, program code is written in a way that the output data of a program's function can itself be executed; and compiler programs process code as a data input, translate it from 'source' form to 'object' form, and output a binary file object that can be executed. There are some non-SFNT based formats, like PostScript Type 3 and METAFONT, which are truly programs. But Type 1, CFF and TTF outlines are not executed, they are parsed as input to rendering systems. Since UFO is XML, UFOs are clearly not programs; and even the .fea files inside them are not, because - like HTML and CSS - they contain markup data that is parsed to the OpenType Layout Engine programs like Harfbuzz.) However, what the SSI case did substantiate was why fonts can be claimed to be subject to artistic copyrights: the assumption that the designer places outline points in a creative act and that the individual point placements cannot be automatically inferred from the glyph image But its important to note that typeface designs themselves - glyph images - and not the Bezier points that express them, are not subject to copyright restrictions in the USA, and probably in many other places. And that Ralph, is the core of the dispute about them willfully infringing your copyright. The museum is talking about the typeface design, but you have deduced that their font data is derived from your font data, and is thus a derivative work under copyright, and they need to settle with you pronto. This 'in principle it could have been original' stuff is cute, because indeed they could have made the design that their fonts displays by hiring a type designer to create new font data of that design, and then they would be legally legitimate. But it seems that this is not what they did! And so they have put themselves in jeopardy. This is exactly the error that SSi made with Adobe's fonts in the famous SSi case Adam refers to. However, unlike SSi, it seems that they were an licensee, and thus bound by your EULA contract. This to me seems like your strongest card to play, because if this is the case, the copyright status of fonts and designs is entirely irrelevant. There was a famous Monotype vs ITC lawsuit in the 1990s that turned on such a contractual obligation by Monotype not to copy designs by ITC. (The lawyer Paul Stack led the case for Monotype that they did not copy the designs exactly, and thus were legitimate, and Michael Twyman was a star witness that testified that they were not exact copies.) However, in Germany there may be a 25 year copyright on typeface designs themselves, in addition to the regular artistic copyright term (life+70 years or whatever) on the font data. The reason the case turned on contract and not copyright is because copyright restrictions don't apply to type in the USA at all. [Google] [More] ⦿ | |
Chester Jenkins
| |
Chris Simpkins
| |
Cooper Hewitt
| The Cooper Hewitt Smithsonian Design Museum in New York City is giving away for free its bespoke house typeface, a sans designed in 2014 by Chester Jenkins, the founder of the Village type foundry. Even the original UFO files are made available. They write: Cooper Hewitt is a contemporary sans serif, with characters composed of modified-geometric curves and arches. Initially commissioned by Pentagram to evolve his [Galaxy] Polaris Condensed typeface, Chester Jenkins created a new digital form to support the newly transformed museum. The museum's director, Caroline Baumann, says distributing the typeface for free was a way to demonstrate the Cooper Hewitt's commitment to its mission. Quoting her: We're all about giving the public access to great design---to our collection online, to our typeface, to our programs---and this was a natural step for us. Open Font Library link. Cristiano Sobral's Tanohe Sans (2020) has re-worked style numbers, a shorter J, and a true italic lower case a. Fontsquirrel link. [Google] [More] ⦿ |
In a forum in which Adrien Tetar's Trufont UFO font editor was discussed in 2015, the conversation turned to free versus proprietary software. Many argued that you get what you pay for. Dave Crossland had one beautiful (long) reply to many questions or objections, in favor of free software for making fonts. To the comment I guess I just don't understand what it is that you cannot get from proprietary software, other than "free", he replied: "Freedom" is a pretty wooly term, and clearly hasn't conveyed the idea to you. I'll try to explain another way: I get personal responsibility, or, control of my design process. 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. The argument of a pro-proprietary poster: 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. Dave Crossland's reply: 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. A new commentary: 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. David Crossland retorts: 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. Next objection: Profit is the best driver. Dave's reply: Many libre software projects are developed for-profit, though :) So I totally agree that when libre software projects are not backed by full time - waged - developers, then the overall result is more likely to be dissatisfying than if it is only developed by part time hobbyists. 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! :) For me, the paid development of libre software is really the sweet spot, and I work hard to raise funds to pay people to work on libre software and fonts. I feel sad indeed that almost all of the libre graphics applications are developed by hobbyists, and are inadequate for many professional designers. Blender and Krita stand out as exceptions. 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. Next comment: I can't speak for Dave, but as a software developer there are times when it's frustrating that you can't crack open some piece of software to either fix some issue or to add some missing functionality. . Dave's reply: Most frequently it is people who have learned some programming who care about this ability, people who can say with a straight face, "I am a software developer." I'm rather unusual in that respect, as I don't know much about programming, but I really value my freedom to use, study and modify my design tools. 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. I was much influenced by those classes and keynotes in the type community about 'designing the design process,' where the importance of designers being able to work on their design tools, as well as with them, is highlighted. That is really what the software freedom movement is about, for me. One more comment: That being said, that means that GUI OSS is going to be a fairly limited appeal if that's the only additional draw. Dave: 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. [Google] [More] ⦿ | |
David Schweinsberg
| |
Erik van Blokland
| |
A summary of digital font formats, as of 2012:
| |
Compile fonts from sources (UFO, Glyphs) to binary (OpenType, TrueType). By 2020, fontmake has grown into a very popular tool, partly driven by Google Fonts' requirement that all its fonts be made with open source tools. Google's requirement is that there is a reproducible build process that does not rely on commercially licensed software. This leads most often to the production chain Fontmake+UFO+DesignSpace. [Google] [More] ⦿ | |
A typedrawers discussion in 2020 about the use of fontmake or Adobe's AFDKO in font production. Quoting font technology expert Adam Twardoch: AFDKO is an older set of tools and libraries that was created to convert between various font formats. Its most-used components were those for converting Type 1 fonts into CFF-based OpenType fonts, for compressing the CFF table using subroutines, and to compile feature definitions from the FEA format into binary OT tables. AFDKO is mostly written in C/C++, with some code in Python. fontmake is a small tool that uses a large set of libraries written in Python, written from scratch or significantly extended in the last few years. Its core is fontTools, originally a Python-based OpenType parser, today a set of libraries that provides alternative, newer implementions of most of the commonly-useed AFDKO modules. There are additional libraries like ufo2ft or glyphsLib that fontmake uses to convert other formats into something fontTools can compile. Originally, developers used AFDKO and fontTools in combination. In fact AFDKO does use fontTools itself in small bits. The code of ADFKO was a haphazard mix of different languages and programming styles and glue-code. fontmake, fontTools and the other libs are written in a much cleaner way, esp. since the migration to Python 3. Almost all of relevance what AFDKO could do the fontTools-based workflow can do (I find calling it "fontmake" is a bit of misnomer, fontmake really is just a small frontend). Users still use AFDKO because it's well-established and it's shortcomings are well-known. But the community is gradually migrating towards the Python-only ecosystem built around fontTools and fronted by fontmake. AFDKO and fontTools is an interesting case if you compare how they came to be. Both projects are opensource, but there is an important difference. AFDKO was developed in-house within Adobe, to fit Adobe's own workflows for font development, and also their particular focus on the types of fonts they were making. Adobe made the source of AFDKO available to interested parties so that apps like FontLab could bundle the compiled code. Overall, the number of people who had insight into the code was small. Because there were hardly any open collab tools for code, changes and fixes, even if made by some of those who had insight, may have only ended up in the private forks. Much later, Adobe opensourced the bulk of AFDKO. This was great — but the code remained very tied to its original limitations: there are many functionalities for Euro-centric fonts but few for complex scripts. fontTools was different. It was opensource from day one. When Behdad Esfahbod and Google i18n took over its maintenance, and the code appeared on Github, a large group of people could advance it. People added new functionalities and other libraries quickly, and they all worked well together. The ecosystem around fontTools outgrew the original scope of the library many times. I think the fontTools ecosystem is better, largely because the library was opensource from the start, so it could grow by consensus. AFDKO was an in-house package for a long time. It is fine, it is great that it's there, but it didn't enjoy the benefit of many eyes for that long. [Google] [More] ⦿ | |
Frederik Berlaen
| |
Georg Seifert
| |
gerb
| In 2022, Manos Pitsidianakis, aka epilys, released the open source font editor gerb. gerb is an experimental GUI font editor written in gtk3 and rust. Still in prototype phase, it opens fonts in UFOv3 format but can't yet export to otf and ttf formats. Pitsidu=ianakis is an electrical and computerengineer at the National Technical University of Athens. [Google] [More] ⦿ |
James Godfrey-Kittle
| |
| |
Jimmy Wärting
| |
LettError
|
Erik van Blokland is a graduate of the Royal Academy of Art in The Hague (KABK), class of 1989. He develops niche tools for type design and font production and has been involved with Tal Leming in the development of the UFO (for font sources) and WOFF (for font binaries) formats. Since 1999, he is a senior lecturer at the TypeMedia master at the Royal Academy of Arts in Den Haag. Erik developed many type software tools such as the acclaimed type interpolation tools MutatorMath and Superpolator, and the teaching tool TypeCooker. Their typefaces:
Erik speaks often about his work. At ATypI 2004 in Prague, LettEror spoke about education in type design, and the RoboFab toolkit. Speaker at ATypI 2013 in Amsterdam and at ATypI 2014 in Barcelona [on interpolations with Superpolator3]. Klingspor link. FontShop link. Wired interview. Shop. FontFont link. [Google] [MyFonts] [More] ⦿ |
Manos Pitsidianakis
| |
Font editor project by Simon Egli (initiator, Switzerland), and Lasse Fister, Reuben Thomas and Ben Martin (core developers). Metapolator will be a web-based parametric font editor, providing a GUI for designing with UFO fonts and Metafont technologies. Metapolator is intended for type designers to design large font families faster, and for typographically sensitive graphic designers to adjust their libre fonts for their exact needs. For example, expanding a single style design into a family of weights and widths, or fine-tuning the weight and width of a font for your exact needs. Metapolator first provides a typical 'super' interpolation system that works with unlimited numbers of masters and axes, and will load and save normal UFO fonts. Github link. Open source software guru Dave Crossland wrote this opinion in 2015: 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. Github link. [Google] [More] ⦿ | |
Online Font Converter
| The Online Font Converter converts fonts to/from: pdf dfont eot otf pfb tfm pfm suit svg ttf pfa bin pt3 ps t42 cff afm ttc woff woff2 ufo. By Jimmy Wärting. [Google] [More] ⦿ |
Developed by Letterror, RoboFab is a library of code and objects written in python for all Python-supported platforms (MacOS X and 9, Windows, Linux, etc). RoboFab is a toolkit for font and glyph data. It works together with FontTools and FontLab, but it can be used seperately. The basic version is free. " The toolkit offers a new and improved approach to working with type development projects, and it implements a brand new XML-based font data source file format called Unified Font Objects (UFO). This enables easy exchange of font source data between applications, it stores Cubic ("PostScript") as well Quadratic ("TrueType") contour data and it is application and operating system independent. Individual characters from a project can be distributed, checked into databases and manipulated with standard text tools and version control software. The UFO format contains glyphs, Unicode data, metrics, kerning, names, and many forms of data which would not normally be associated with a final font format like TrueType or PosScript. Several new tools based on RoboFab and UFO are in development, MetricsMachine, for example, is a powerful spacing and kerning editor for MacOS X making use of the development tools that ship with Apple's OS." [Google] [More] ⦿ | |
A professional UFO font editor for the Mac unveiled at ATypI 2011 in Reykjavik by Frederik Berlaen, written in Python. [Google] [More] ⦿ | |
Speakers included Tal Leming (TypeSupply), Frederik Berlaen (RoboFont), Erik van Blokland (LettError), Yanone (SpeedPunk), Miguel Sousa (Adobe), Frank Griesshammer (Adobe), Petr van Blokland (Buro Petr van Blokland + Claudia Mens), Ben Kiel (House Industries). Video presentations. [Google] [More] ⦿ | |
Source Foundry
| Chris Simpkins (Source Foundry, Baltimore, MD) wrote these free font tools:
In addition, Chris designed the free programming font Hack (2018). Github link. Use Modify link. [Google] [More] ⦿ |
Developed by Erik van Blokland in 2003-2004, and first shown at ATypI in Prague in 2004, Superpolator is a flexible tool for interpolating fonts and glyphs with extreme flexibility in design space topology. Superpolator is a python package, based on RoboFab. The package contains scripts for use in FontLab (with vfb fonts) and for use with UFO-style fonts. Superpolator2 (2007) is its commercial version at 250 Euros per license. [Google] [More] ⦿ | |
Tal Leming
| |
Trufont
| Free open source software: a cross-platform UFO3 font editor. Written in 2015 by Adrien Tétar (Paris, France). Github repository. TruFont is a font-editing application written with Python3, ufoLib, defcon and PyQt. In 2019, the Trufont group started rewriting Trufont with a wxWidgets GUI (replacing the old Qt one). [Google] [More] ⦿ |
TypeDesigner
| David Schweinsberg (Pasadena, CA) is developing a Unified Font Object Editor for macOS in 2021 called TypeDesigner. [Google] [More] ⦿ |
TypeMyType
|
|
Tools for extracting data from font binaries into UFO objects. [Google] [More] ⦿ | |
UFO QuickLook
| Free Mac OS X Leopard tool by Georg Seifert. It works with UFO format font files. [Google] [More] ⦿ |
The developers write: Glyphs are stored as .glif files. Other data is stored in XML-based plist files. The plist format is developed by Apple, has a DTD, but is platform independent.The UFO is a new file format for font and type design related data. Glyphs are stored as .glif files. Other data is stored in XML-based plist files. The plist format is developed by Apple, has a DTD, but is platform independent." Glif is Just van Rossum's description of one single letterform (glyph) in XML. UFO enables easy exchange of font source data between applications, it stores Cubic ("PostScript") as well Quadratic ("TrueType") contour data and it is application and operating system independent. Individual characters from a project can be distributed, checked into databases and manipulated with standard text tools and version control software. The UFO format contains glyphs, Unicode data, metrics, kerning, names, and many forms of data which would not normally be associated with a final font format like TrueType or PosScript." In 2004 they write: "RoboFab has a new, standardised object model for font, glyph, contour and friends. RoboFab supports a new, future-proof XML based file format for font source data, the Unified Font Objects or UFO. This allows scripts based on RoboFab to work the same in FontLab as in plain Python environments, cross platform, cross application. This new format is not a contender in the TrueType, Type 1 or OpenType race, it is a format to store **sources**: all data related to type design in an application independent and standardised XML way. UFO files can be used to exchange font and glyph data between applications. RoboFab is free for end users, well documented, and downloadable from http://www.letterror.com. There are versions: UFO1 (2004), UFO2 (2009), UFO3 (2012). The design philosophy, summarized: | |
ufo2fdk
| Tal Leming wrote a tool, ufo2fdk, that permits to go from the UFO font format to FDK. This will permit users then to generate OTF and TTF files. It requires the FDK library. [Google] [More] ⦿ |
UFO to FontTools (and thus to ttf and otf). [Google] [More] ⦿ | |
ufo2ft
| James Godfrey-Kittle works at Google in Mountain View, CA. He wrote ufo2ft: ufo2ft ("UFO to FontTools") is a fork of ufo2fdk whose goal is to generate OpenType font binaries from UFOs without the FDK dependency. The library provides two functions, compileOTF and compileTTF. [Google] [More] ⦿ |
JavaScript API for the Unified Font Object. [Google] [More] ⦿ | |
Tool that will normalize the XML and other data inside of a UFO. [Google] [More] ⦿ | |
The official Unified Font Object specification source files. [Google] [More] ⦿ |
[
Jeff Mcneill is based in Chiang Mai, Thailand. His 
LettError is a foundry in Den Haag, founded by the interesting duo, Just Van Rossum (b. 1966) and Erik van Blokland (b. Gouda, 1967). Many of their fonts can be found in the FontFont library. 
Erik van Blokland's brainchild. Robothon 2012 took place at the KABK in Den Haag, The Netherlands, from March 8-9, 2012. Paul van der Laan wrote: This year we're proud to announce an international range of speakers, the new UFO 3 format, amazing new tools and ideas. Robothon is a great opportunity to hang out with your colleagues from around Europe, meet the TypeMedia crew, and see the Gerrit Noordzij Prize exhibition and seminar dedicated to Wim Crouwel. 
Frederik Berlaen (TypeMyType) is a Flemish type designer, b. 1981, 
|
|
|
|