FWIW, at the three-day Crafting Type workshop in Portland that just ended a week ago, I think we had about 19 women and 4 men. So at least the interest is there.
I am perfectly willing to believe that there is not a single answer here
Sexism is an obvious and plausible answer. Even if the sexism has substantially evaporated, until recently there was a shortage of prominent role models for female type designers. Things have improved, but it takes time for beginners to progress. I am very curious as to what the gender balance in type design will look like in another ten or twenty years.
I do *also* suspect that there are more unilaterally obsessive men than women in the world. Looking at the gender ratios of people on the autism spectrum, for example, I see that in a big way. (And I do honestly believe that many type designers are obsessive a bit beyond the range of normal people, to the point that they probably are diagnosable. I am not excluding myself in this, either.)
So, I would not be shocked if among full-time type designers, *some* degree of gender imbalance continues indefinitely. But I also expect the imbalance to decrease substantially in my lifetime.
It was on one of these rare sunny days in 1963 that when the poll committee increased the voltage to obtain a proper answer from the clearly innocent Mr. Tumbleweaty, the room was suddenly ﬁlled with exquisite classical music broadcast from the Kingdom of Tonga.
But in some Cyrillic designs, the italics are oblique and the letterforms don't change. I'm trying to figure out the borderline where these traditional forms would be inappropriate.
If I were doing an old timey Cheltenham sort of design, I'd go with the alternate (traditional) italic Cyrillic forms. If I were designing a square, high-tech spaceship font, I'd likely go with oblique forms.
I'll say what I've said before: let's forget about the distinction between a “font” as a set of complex data tables and a “layout engine” as a software program that takes a text, a font and a few formatting attributes and returns a “line of type”.
Instead, define an API (programming interface) that allows a standardized way of inputting: 1. A piece of text 2. A 2D area to fill 3. A minimal set of mandatory formatting attributes 4. An optional set of arbitrary attributes and allows outputting: 1. An arrangement of positioned visual shapes drawn in a specific technique 2. A linearized “map” of text pieces that correspond to the visual shapes and allows searching, text selection and editing.
Then, allow arbitrary software programs (real “font software”) to work behind that API.
Some of these fonts can make use of shared libraries that do simple-script single-line layout and just provide a static set of images and metrics. Other fonts can fill the requested space with dynamically drawn handwriting simulation, yet others with a sheet of musical notation or a chemical formula or a math equation, or a chessboard.
In essence: allow to bundle the layout engine with the font, or the font with the layout engine.
Something like HTML Canvas but with a “text layer”. So the font can return an area filled with things that you see and information what it is that you see (in detail).
OpenType, AAT, ACE, MATH, Multiple Master etc. can all be such shared libraries behind the API, and as a designer, you can just draw 700 static glyphs that use one of these libs, or you can draw 675 static glyphs but program 25 special dynamic glyphs that “draw themselves” using your custom program.
We have recorded music that we can play and we have a way to have a software program generate music on the fly. We have moving pictures that come from a camera recording and those that are generated by computer code on the fly (like in computer games). We can draw diagrams or write software that draws them dynamically.
We should finally also have a way to compose a “paragraph of text” by both methods.
And then, we’ll be able to write your own “kinetic kerning engine” along with your “responsive glyphs” ourselves. We won't *have to* “export our font as a GIF” (pardon me, OTF) before it can be “used”. We'll still be able to, because LegacyOpenTypeLineSetter will be one of those shared libs that our software font will be able to call. Like an MPEG-1 decoder that's needed to play some video.
I see a certain contradiction in what you're saying: you say that .glyphs is becoming an "industry-standard source format" while you cite examples of foundries using various tools, and you mention various features of the Glyphs app which are specific to that app.
I see the .glyphs format as a great source format for sources that are created with the Glyphs app. But there are, and will be, more tools that people are using, and I think many of these apps will have some functionalities unique to those apps.
I think there is a difference between a tool-specific source format, an interchange format, and a "universal" source storage format.
As long as you have a tool-specific format, the format typically supports the things that the tool supports, and vice versa. .vfb is a FontLab tool-specific format, .glyphs is a Glyphs-specific format etc. Even between these two, each supports features that the other doesn't. And, there's UFO.
For example, FontLab Studio 5 (and the .vfb format) can store and edit both cubic and quadratic outlines, same goes for UFO.
AFAIK, Glyphs currently only supports cubic outlines, but it does support color bitmaps which old FLS5 doesn't.
FLS5 supports 4 interpolation axes with max. 2 masters per axis, Glyphs supports 3 font-wide axes with a max. of 3 masters per axis, so you cannot have a family with hand-edited 4 masters. And it has additional glyph-specific axes. Superpolator is much more flexible in this respect.
Glyphs operates on the concept that all masters in a family have an identical set of OpenType Layout features, so defining a separate "cpsp" feature for Light and Black is hard.
UFO stores the features separately per master.
So you cannot loslessly move a Superpolator project along with its UFO masters into a Glyphs project, just as you cannot losslessly do the reverse.
If you have a set of TTH-hinted quadratic UFO masters, if you move them to Glyphs, they will be converted to cubics and that hinting will be lost, and once you generate TTFs out of Glyphs, you'll get different quadratics and different hinting (not better, not worse, just different).
Every tool uses different cubic <-> quadratic conversion math. So even if several tools used the current .glyphs format as its source format for cubics, the final TTFs will differ depending on how you build these.
Sure, some functionalities can map to each other between apps.
But will the results be identical? For example, FontLab previewed the smartly connecting serifs that will be part of FontLab VI two years ago, and Glyphs 2.1 now has a similar functionality — but are they/will they be 100% identical?
For "simple things", they will be. But, as you say, if you want to be 100% interoperable, you'll need to limit the features you use to a lowest common denominator. If you use any RoboFont-specific extensions or any Glyphs 2-specific features or in future any FontLab VI-specific features, you'll lose routrippability.
If you try to create a "universal source format", this may actually hinder innovation. Imagine FontLab had made .vfb into a human-readable, well-specified XML-based .vfx format 7 years ago, and that format was coined "the universal source format".
What would then happen to many of those features that Georg had implemented for Glyphs (e.g. 3 masters per axis or those bracket/brace layers etc.) if there "wasn't any place for them" in the "universal source format"?
I start to think that perhaps, across tool makers, we shouldn't try to develop a "universal source format", or even a "universal all-encompassing interchange format".
Instead, we should perhaps focus on developing itemized interchange formats for various aspects of type making: cubic monochrome glyph, quadratic monochrome glyph, SVG glyph, kerning, groups, glyph set, anchors, glyph metadata, itemized font metadata, hinting, masters and interpolation rules, etc.
These could follow a similar general syntax if needed, or perhaps several subsyntaxes.
Kind of like Apple's AAT tables: each one dedicated to a single task. I like how Apple has size-specific font tracking info a small nifty "trak" table that can exist completely independently of everything else. It's not buried deep inside some monolithic beast (be it XML or binary or TXT).
Look at kerning: the best interchange format for kerning, in a way, is still... AFM! Well, AFM has a few more things in it, but the kerning section could be spun off as ".kpx" or something like that. Cubic monochrome glyph geometry could have its own format, while the quadratic one could have another (similar but not identical).
Itemization is important. I like the aspect of UFO that you have one glyph per file (GLIF), because that instantly gives you not only a file format for a single glyph (that you can send to a colleague in an e-mail attachment) but also a clipboard exchange format, great for copy-paste.
I think the great success of the web is that it consists of itemized formats. You have HTML, CSS, JS, SVG, PNG, and many more. Want an SVG with a fallback PNG? No problem. Want video in two formats? No problem. With Web Components, they now also want to itemize the HTML (which is long overdue).
One long XML á la .glyphs is similar to one long XML á la .ttx. Not good, really. I'd much rather have a source format where I actually have a "binary-in-XML" format á la .ttx, but itemized well, in a tree, with "links" to "better sources" as a "backup" (for example .glif or .fea). So I can store my OTL features as .GSUB.ttx and .GPOS.ttx but they somehow point to a .fea or .vtp file.
A metadata file keeps track which one is more current, and if I update the .fea and run "make", the .ttx files get rebuilt (using a fea2ttx tool which is independent of RoboFont, FobtLab, Glyphs etc.).
I think the only feasible way for type designers to attain an independence of their sources (and their work) is when they have a chance to use alternative tools for each and every one of those "pieces".
Like with the web: you can use some tools to generate your CSS and completely different tools to make your HTML and yet separate ones for your PNGs. And in the end, the browsers "put these all together". Even if one of the elements of the puzzle dies off, you only lose a few % of your work — not all.
A "format" by itself is really worth nothing. Even if it's "XML". InDesign's .idml is XML and Apple Keynote's .key are or were both XML. Doesn't help much if you don't own InDesign or Keynote.
I would like to see a new spacing paradigm. The current one, in which each glyph is contained in a rectangle and each rectangle butts up against the next, is unnecessarily simplistic. To work around it, we have pair kerning, which only works within a single font.
It seems to me that it would be simpler and more flexible if side bearings could have contours other than straight and vertical. They could be slanted, for instance, or follow the contour of the glyph in some useful way. Maybe we could even do without kerning tables.
My advice is to stop working on this and design a black weight. After you've done that come back to this and revised it based on what you've learned. You'll get more out of that than you will out of continuing to grind away at this. Because what you have now is a typical light first typeface that wears your influences on its sleeves. Moving on to a black weight will force you to work out the character of the design instead of working out the evenness of the design.
I start with the lowercase i, and then the l, and then the n, h and m. What I like about this is that it means I can concern myself with stem weight, terminal treatment, and vertical proportions before I need to start thinking about horizontal proportions and spacing, which only come into play when I get to the n. [I've watched workshop students spending ages struggling with the shape of the n when it is the first letter they try, and I think it is more encouraging to start them on the simplest letters, so that when they do get to the n at least the left side is mostly taken care of for them, and they have a sense of accomplishment in the i and l.] Similarly, I don't think starting with n and o together makes sense, and have watched students spend ages going back and forth between them adjusting their relative widths without any external points of reference. The upright letters establish the rhythm of spacing, so get these designed and spaced first. Then the width of the o looks after itself.
The pseudo-word nihilim is a great test for spacing and horizontal proportion. If you can make this look good, you are en route for a nice typeface.
After those five letters it doesn't much matter what comes next, but I tend to go to a e t because these are all high frequency letters and have a strong influence on the character of the design. Only then to I go to the rounds—o b d p q—, which by this point have plenty of shapes and rhythms to reference.