AAT In Decline? Who develops AAT features?
Dave Crossland
Posts: 1,430
Is AAT on the way out? Seems Apple's support for OTL is getting better and better.
I'm also curious who here might have experience AAT feature development services?
I'm also curious who here might have experience AAT feature development services?
0
Comments
-
Seems Apple's support for OTL is getting better and better.
What on earth makes you say that?0 -
FWIW, AAT is alive and well on Apple OS's. In fact, the reason OT support has been inconsistent over the years is that OT features are translated on-the-fly to the AAT equivalent and rendered by AAT. The problem is that the two systems are not exactly equivalent, so translation has not always been correct.
CALT support has been pretty good lately as far as I can tell. Most OT stuff seems to be supported now at the OS level, but apps don't always take advantage of it, or have not been updated to take advantage of it (previous versions of iWork), or support it incorrectly or not at all (Final Cut), or drop the support they did have (latest iWork). TextEdit seems to be the only app that's ever on the same page as the OS with regard to OT support.
(This is based on my experience with 10.9/Mavericks. Don't know what if anything has changed in 10.10/Yosemite.)2 -
I remember Adam Twardoch saying that the complex script layout with AAT is about 3 times faster than OpenType with comparable functionality.
But the more important difference between the two technologies is that they have two completely different processing models, and the things that are cumbersome or close to impossible in OpenType are often perfectly doable in AAT. I’ve recently read the transcript of John Hudson’s TypeCon presentation where he gives, p. 25, an example of the positioning problem that he found impossible, or impractical, to resolve with the current OpenType Layout model. I believe that the issue he talks about could be solved with a single, backward-moving state machine kerning subtable in AAT.
Such differences, of course, often work both ways, and I suppose there are things that are obvious with OpenType, but are somewhat tricky to achieve in AAT, like the case of one guy’s contextual ligatures I stumbled upon on FontLab’s forums the other day.
Personally, I don’t expect Apple to invest much in OpenType, because it’s a technology that’s de facto controlled by Microsoft, and the recent trend at Apple is all about the whole technology stack being their own from top to bottom. Besides, I read somewhere, can’t remember where, that the very decision within Microsoft to develop OpenType was a result of Apple refusing to license them the technology back then known as TrueType GX, a move that seemed predictable when one considers all the issues of the original TrueType deal with Microsoft.1 -
Personally, I don’t expect Apple to invest much in OpenType, because it’s a technology that’s de facto controlled by Microsoft, and the recent trend at Apple is all about the whole technology stack being their own from top to bottom.
Each new version of OSX and iOS brings more extensive OTL support. Much of it is unnoticed by North American or European folk, though, because it is focused on complex script support. So, for example, Yosemite implements Indic2 shaping (previous versions only used Indic1), and is actually the first major consumer software to do so with {rclt} feature support for cross-cluster shaping* (recent builds of Harfbuzz also implement this). So in at least one respect Apple's OTL support is ahead of Microsoft's.
*http://tiro.com/John/Fixing_Indic2_OTL.pdf
_____I believe that the issue he talks about could be solved with a single, backward-moving state machine kerning subtable in AAT.
Interesting. Are you able to talk us through how that would work?
My experience with AAT was limited to work on the Apple version of Zapfino. Simple substitutions were easy enough, but as soon as things got contextual I had to ask Dave Opstad to help.1 -
I say that because I've commissioned dozens of Latin + Devanagari fonts this year, and that is what the foundries are telling me.Seems Apple's support for OTL is getting better and better.
What on earth makes you say that
I think it makes logical sense, since (a) the model of AAT is that there is a simple rendered and complex fonts, and OTL is complex renderer and simple fonts and (b) there are so many OTL fonts and so few AAT fonts, so Apple is incentivised to make all those OTL fonts work better and better over time, and there's less room to make AAT better incrementally.
All OTL engines have problems though...0 -
Developing OpenType Layout vs AAT features is similar to developing PostScript vs TrueType hints. Just like, strictly speaking, in PostScript, there are "hints" (and the rasterizer is "smart") and in (original) TrueType, there are "instructions" (and the rasterizer is "dumb") — OpenType Layout feature definitions are "hints" (with a "smart" shaper) while AAT feature definitions are "instructions" (with a "dumb" shaper).
In both rasterization and shaping, it seems that the "hint" model is easier to understand and adopt at a basic or intermediate level for the majority of font makers because the responsibility of "making it work" is split between "designers" (who make the fonts) and "developers" (who make the font engines). So in the end, the "hinting" (or another term would be "declarative") model is more popular.
However, the very same nature causes frustration as your declarative hints grow in complexity. The kind of work that John Hudson does would be actually much easier to do in the AAT model because John could actually generate a large state table for the entire Hebrew Bible and put it in his SBL Hebrew — and it would just always work. But there are only very few people who desire this type of detailed control, so AAT and manual TrueType instructing have always been a minority.
The declarative frustration has been also seen in the HTML+CSS model. Originally, the simplistic HTML+CSS model was very appealing because it was easy to learn and easy to quickly receive decent results. But the inconsistencies of the "smart renderers" (i.e. the web browsers) and the growing desire to control more and more details of the design have caused a lot of frustration — the kind of frustration that was less known to people authoring PostScript or PDF documents because these formats were more "instructing" (explicit) rather than "hinting" (declarative).
Interestingly, the frustration of HTML+CSS developers seems to have gone down since the advent of performant JavaScript engines in browsers. In a way, you get the best of two worlds: you can code declaratively via just HTML+CSS or explicitly via HTML+CSS+JS. So it seems that the addition of a real, full-fledged programming language was the answer.
Which brings me to my conclusion: I believe AAT is dead. I think the future should be OpenType Layout with JavaScript (or another programming language) added to it. So the most demanding font developers could skip OTL or hinting etc. and just develop their "font" in a programming language entirely.1 -
Ps. I also might add that while I don't know Grzegorz Rolek personally, I've looked at some of his AAT-related work with interest, and I imagine that he might be willing to help font makers who'd want to venture into AAT development.
And yes, I have it on good authority that about 2-3 years ago, Indic AAT feature processing was measured to perform about 3x faster than Indic OTL processing on iOS devices. I don't know if this benchmark still stands but in principle ot should.
Also, an interesting bit of trivia: in the opensource HarfBuzz engine, the key portion of the unified Indic OTL shaper is implemented via a finite-state table, the same mechanism that is the foundation of AAT.
Therefore, I'd imagine that it would be rather possible to take an Indic OTL font and, with HarfBuzz's assistance, produce the AAT version.
Or more generally speaking, it is definitely possible to make a tool that takes any GSUB OTL definition and convert it into a morx table. AFAIK, nobody has done it in a publicly available tool, and since it actually is a fairly trivial task, I guess that it confirms that AAT is "dead".0 -
Personal opinion only:
I personally think the OT model is woefully insufficient, and I believe AAT is sufficient. I think the 'need a Dave Opstad' stuff is mostly to do with the lack of community understanding of the technology, and having well documented libre AAT fonts would be very educational.AT: it would be rather possible to take an Indic OTL font and, with HarfBuzz's assistance, produce the AAT version.
FontForge has for many years had an OTL2AAT converter already, although I'm not sure how good it is...
http://fontforge.github.io/gposgsub.html#ConversionAT: I think the future should be OpenType Layout with JavaScript (or another programming language) added to it
I think the chances of Google, Microsoft, Apple, and Adobe implementing that in harfbuzz and the proprietary shaping engines is.... small.GR: the recent trend at Apple is all about the whole technology stack being their own from top to bottom
Well, I don't think fonts are seen as a differentiating technology by anyone any more. There was a scramble around color fonts for emoji, everyone did their own thing, but (AFAIK) everyone has welcomed everyone else to implement their thing. Fonts are infrastructure.
I think Apple is the least incentivised to support anything beyond what they do. They have AAT. It works. They already (I guess sorta like harfbuzz) translate OTL into AAT on the fly. Most importantly AAT has already shipped on all their devices.
Indeed, since AAT fonts already work on all iOS devices, and since most Android users will upgrade to new devices within a couple years, if harfbuzz did someday support AAT, then 24 months after Android ships that version we could see AAT dominating mobile fonts for scripts that require shaping.
(Perhaps it might even be possible to backport the harfbuzz-aat to some Android systems, such as the Reverie/etc renderers used in Micromax/etc devices...)
The publication of more and more AAT-only fonts would incentivise Microsoft, Adobe and others to implement AAT support too.
So I think extensions to OpenType that break the 'simple fonts, smart renderer' model are unlikely to go anywhere. Its not really OpenType if you add JS or anything executable.AT: while I don't know Grzegorz Rolek personally, I've looked at some of his AAT-related work with interest
Grzegorz, I'd love to hear more about your AAT work, here or privately
0 -
Let me first introduce, for John and others, the rather simple concept of a state table kerning as it has existed since the early days of AAT. Kerning in particular is a little-known part of the technology, even among people that have a good deal of experience with AAT. I think this is because, apart from maybe FontForge, there were no tools available to build the tables, and the format itself has become obscured by being buried inside the long-forgotten
kerntable. Introduction of thekerxtable, the recently updated specs from Apple, and the upcoming update to their Font Tool Suite could somewhat change the current situation.
In a nutshell, with a kerning state table, you go through the line glyph by glyph, switching to various states depending on the glyphs that make up your context. Each state you define is able to act differently on any particular glyph that appears in the line.
In a typical scenario, you follow your state chain looking for some specific context and, in the meantime, you pick up from the line those and only those glyphs that you want to act upon, keeping them on a separate so-called kern stack. Now, when a particular context is more or less complete, and you have your kern stack assembled and ready, you simply trigger some predefined list of kern values to be applied to the glyphs from the stack.
More specifically, the actions that you can trigger from within each state, and on each new glyph in a line, are:
1. put the current glyph on the kern stack
2. apply a particular list of kern values to the glyphs already on the stack
3. indicate the next state
4. stay at the current glyph and re-process it within the next state.
Each list of kern values, when applied to the stack, kerns the glyphs one-by-one until either the list is consumed or there are no more glyphs on the stack (the stack keeps only the last eight glyphs). Moreover, the stack is maintained until the subtable is done running, so you can kern the same glyphs multiple times repeatedly or in patches (the kerns are additive).
Nice part of it all is that your context, or the state chain, can evolve throughout the line, or that the glyphs you pick up can be interspersed between its very ends, and you can apply your kern values at any moment and even repeatedly — all in a basically constant time of a single line processing. Performance-wise, this is the main advantage of finite-state automata of AAT over the look-ahead/backtrack model of OTL.
That’s it, that’s the whole mechanics of state machine kerning in AAT. No lookup types to remember! There are few variants, like cross-stream kerning for both horizontal and vertical line layouts, but these only differ in their output, whereas the mechanics are all the same. Recently, with the advent of thekerxtable, it was extended with control-point attachment positioning, but from the conceptual point of view it’s nothing really new, and the inner workings are actually more similar to the better known morphing subtables of AAT. In fact, once you get the idea of a state table, you move through the whole technology without much effort.
To add to Dave’s comment on lack of community understanding of AAT etc., I would like to note that the inner workings of OTL at the font binary level could easily overwhelm many less-seasoned font developers. It’s the tools around OpenType, or the Adobe’s high-level feature file syntax, that make it all relatively easy. In contrast, the tools around AAT, including the input files as used by Apple, were always rather close to the binary. But there is one exception, namely, the ligature list as used by Apple. In the input file these are just lists of glyphs that make up particular ligatures, but behind the scenes the whole list is implemented as a single, dedicated state table with its usual speed and conciseness.
I could now turn Adam’s argument on its head and say that I think the future should be AAT, but with some abstractions added above it, so the less demanding font developers could skip the state machines entirely.1 -
Dave, I think what Adam has on mind regarding my work is more of a general stuff around AAT. KIF compiler, presumably. No fonts I could show off yet, anyway. Right at the time when I seriously got into AAT, I started to work on a rather complex font project that to this day sits on my desk waiting to be put together and published (it’s for the needs of this particular project, by the way, that I wrote the bigger part of the compiler).0
-
Adam: "I guess that it confirms that AAT is "dead"
Grzegorz: "I think the future should be AAT,"
I'm glad you agree, but I guess you might be talking about two different things.
Dave: "Fonts are infrastructure."
Registered features that are required for marketable scripts, is what I think has reached infrastructureness. Otherwise, the rest of advanced typography might work better?
0 -
Dave writes:
FontForge has for many years had an OTL2AAT converter already, although I'm not sure how good it is...
I did test it some years ago and found that it does indeed work for simple one-to-one user-controlled replacements, and a few others, which is a good start. But of course without a real Indic shaper logic, FontForge cannot convert an Indic OTL font into an Indic AAT font, because the information in the OTL for Indic is not sufficient by itself. In OTL, it is the shaper that does the reordering while in AAT, it is the font that is supposed to do that. But I can easily imagine that HarfBuzz's shaper could be integrated into FontForge's OTL2AAT converter and do a better job.
I also must add that just as the term "OTL", the term "AAT" is not very precise. The old Apple ATSUI text engine implemented much "more" of AAT than the current CoreText engine. Some of the more ambitious functionalities of AAT exist in the specs and did exist in ATSUI but are no longer available in CoreText (variations etc.).
Further on my "AAT is dead" claim: both OTL and AAT are fairly sophisticated formats, yet both have their limitations (especially in implementations). If a type designer just needs to implement things like ligatures, oldstyle numerals, small caps and maybe contextual alternates, then OTL serves her or him well enough, so there's no real incentive to learn an additional format — especially that those aspects of OTL already work in OS X and iOS just as well as their AAT counterparts.
If a type designer wants more sophistication, though, then both OTL and AAT have their strong limits as well. These limits are just different between OTL and AAT. Also, both worlds are relatively obscure — basically, in both cases the specs "promise" you some things but the typical implementations don't deliver, whether it's optical margin alignment, justification alternates or glyph metamorphosis. Working around the implementation limits of OTL is already complicated enough (something that John alluded to), and if you were to repeat the same process for AAT, you'd be in hell.
So what I meant is that to me, AAT is "dead" as a competitor to OTL. It may solve some things similarly, some a bit differently, and some even better, but it's like discussing the differences between 16-bit Intel and AMD processors, or between PNG and JPEG.
Younger designers, especially those "designers/coders", would immediately say: well, but we live in the world of 64 bit CPUs, of video and of animation, and neither of the proposals seems to address these.
Both OTL and AAT force you to "design around the format". The format is given, and you can only do what the format permits. If I want to design with the objectives A, B, C, D, E and F, I quickly learn that OTL will allow me to do A and B and AAT will allow me to do A and C, but D, E and F are completely out of scope.
I agree that on desktop platforms and in traditional OSes, we will be stuck with OTL for quite some time. But if SVG (a web-native technology) is being put into the SFNT container, a technology that largely breaks free from a huge number of limitations of the traditional digital font technologies, then I would think that adding another web-native technology (namely JavaScript) would be the way to go. Even if such fonts would work purely in the web context.
A "real" web font technology which would allow to talk the font to the DOM and the DOM to the font, would allow you to do justification, intelligent optical scaling, metamorphosis in any way, multicolor, animation and — well, in fact — would allow you to put your own layout engine inside the font, written in JS (it could be DecoType ACE, HarfBuzz, Mutator or whatever else) to me is the answer. If you adopt native technologies which are available, implemented and speced *outside* the font context, which are already *there* in the target apps, then "enabling" them on the font level would actually be relatively trivial to most developers. The "format" of such font would essentially be a "skeleton format", because the font would in fact be more of an app. It would only define a minimal API, and it could in fact not use the SFNT container at all but be treated like normal web assets.
I mean (in a way):
@font-face {
font-family: mySuperFont;
src: url(superfont.js);
}
AAT may perhaps be a horse that is still alive, but instead of thinking about how to adapt it to pull the cart that was until now pulled by a donkey, why not come up with the diesel engine instead.1 -
Exactly! As soon as we get the donkey out of the way and add SVG to the stew, it'll all be fine.0
-
I was thinking about fonts as executable pieces of software some three years ago, but I’m actually sceptical about the idea. First and the main reason is that truly responsive text layout and rendering of pages of body text are by no means trivial tasks even for today’s standards, and they have to be both extremely efficient and free of errors or security issues. There’s a reason why all the font formats use those simple processing models — you just can’t afford to do it with a general-purpose computational model. I think it’s also one of the reasons behind Type 1 format being that much restricted subset of PostScript.
I also don’t really think that the future should be one format or the other. There’s obviously place for both. My main argument here is that both technologies are simply different. Right at the beginning I said that AAT has its own strengths and weaknesses, but the very fact of it being a different model of line processing could be welcomed by many if only well understood, I’m sure.
Recent announcement by John Jenkins from Apple suggests that they still see AAT as worth of their investment, so it’s possible that we could enjoy two distinctive and thriving technologies at our disposal in the near future.
For many people TrueType hinting seemed dead, because they had their PostScript hints that were easy to understand and the results were good enough. But then came the Web fonts, and all of a sudden TrueType hinting proved to be of equal importance and demand.0 -
I’d like to go back to John and his TypeCon issue with some details, because it’s the kind of stuff I deal with lately, and it’s also a nice use case for AAT. If you’re willing to follow along, it should give you an idea of how it works in practice. People not interested in the matter can as well skip it. I also don’t read Arabic, so forgive me if I messed up the names or anything. Here it goes.
It appears that a single substitution prior to kerning is required to keep things simple. It’s about making a dummy copy of a particular alef, reh, or for that matter any potentially conflicting glyph, if it indeed is followed by yeh barree at some point. This way we can act early in the kerning phase, without worrying about cleanups in case of any false positives. Substitution itself is a pretty basic operation in AAT and I’ll give a simple implementation in the files attached.
Now in the kerning phase, the state table is flagged to process the line backwards. It starts at the end of the line in a default state and goes through the glyphs doing nothing until it encounters one of the conflicting glyphs, say, alef. If that’s the case, it goes to a state where it can look for yeh barree or any intermediate glyph.
If the glyph following alef is yeh barree itself, it puts the yeh barree onto the kern stack, applies its full kern to it as required, and it goes straight back to the default state and continues from there. Simple enough.
But if the glyph following the alef is indeed one of the intermediate glyphs, say, peh, it puts the peh onto the kern stack and applies the same yeh barree kern to it, moving it out from alef.
You’re now in a situation, when the peh is kerned out from alef by the amount yeh barree itself would be kerned, thus the position of yeh barree relative to alef is the kern mentioned plus the advance widths of all the glyphs in between. This time, though, the machine stays at the peh for re-processing and goes to a state where it can act differently depending on a particular intermediate glyph.
So it goes through the intermediate glyphs, and because peh is still the sole glyph on the kern stack, each new glyph encountered (that includes the peh itself) systematically reduces the initial kern of peh by triggering a kern value to be applied to the stack that’s a negative of the advance width of the current glyph. The moment yeh barree is seen, the machine goes straight to the default state, effectively leaving the alef–peh kern in the amount desired.
How this looks in source format you can see in the attached files. I wrote the substitution part in a known MIF syntax. Kerning part is in my KIF syntax that’s modelled after MIF. In binary it shouldn’t be heavier than few kilobytes of data.
Unfortunate thing is, that you can’t actually test it. Not today, anyway. Backward kern processing for thekerxtable, although it’s defined and ready in the new Apple’s spec, the spec also says that the support for it is planned for future releases of OS X and iOS.0 -
Back to Adam and the Web-native font technologies: SVG is Web-native only in as much as it happens to be XML. Even this, though, does not hold very well, as the way the very soil of scalable graphics — the paths themselves — are defined in SVG, is not even XML.
But I agree with Adam that a closer, two-way communication between the font ‘asset’ and the environment it’s used in, however that would look like, could be a nice thing in general.0 -
I rather not go into the discussion whether AAT or OTL has the better solution. But it seems fair to make some remarks about the OTL side of the equation.
There are two different context lookup types (actually three, but two are essentially the same).
Context: A format in which you specify an glyph sequence, to which one or more rules is applied and then the shaper skips the whole sequence to look for the next.
Chained Context: Allows to create an additional context of glyphs before or after the glyph sequence that you apply the rules to.
It can be argued that the Context format is a subset of the Chained Context. But it is smaller and depending on the kind of thing you do, the one or the other is the best choice.
Each type has three formats:
1 a set of context rules for individual glyphs
2 class rules: glyphs are given a class number. You can then create a set of rules using these classes. Any glyph not classified has class zero. Which you can use in rules.
3 coverage format: a rule to lists of glyphs. This is like context rules for individual glyphs, except that for each element in the sequence you can provide a list of glyphs.
Correct me if I am wrong. But the last time I checked, VOLT and the Adobe tools support the Chained Context lookup type in the coverage format only. So a lot of what is being said about OTL in the comparisson with AAT is comparing AAT context support, with the implementation of a single format of OTL context tables. Add to this an additional limitation, that of the graphic UI of Volt and the feature file syntax.
It can be argued that Chained Context lookup type in the coverage format can do anything the other options can do too. That is true. But with classes you can do everything that the coverage format can do to... with more rules and less data in fewer lookups.
The OTL context rules consist of a sequence of glyphs to apply a GSUB and GPOS lookup to. There is no reason why these cannot be context lookups too. So that means that if you need a lot of lookups for a certain script: you can greatly reduce the number of lookups that the shaper needs to consider by having intermediate rules: A context rule that selects what context rules are needed.
So with class rules it is easier to combine rules within lookups and with class zero to have rules that skip over intermediate glyphs. I have seen Telugu fonts with 100's of Volt lookups, which could have been done with dozens of class context rules (or more ligatures). With context lookups using context lookups, you can make sure that the shaper does not have to go through all the context rules for everything, by having a context lookup that decides when it makes sense to check which set of context rules.2 -
Recent announcement by John Jenkins from Apple suggests that they still see AAT as worth of their investment
URL? 0 -
John Jenkins posted on the Apple Font Tools section of the FontLab Forums:Recent announcement by John Jenkins from Apple suggests that they still see AAT as worth of their investment
URL?
Apple Advance Typography spec updated
http://forum.fontlab.com/index.php?topic=9117.00 -
0
-
I don't think AAT is going away in a hurry. But I do know Apple's support of OpenType has continually improved. They are primarily concerned with language support these days, as several folks have noted.
The feature removal in iWork affected AAT as well as OpenType, no? So a side point on the discussion.1 -
Thomas,
> The feature removal in iWork affected AAT as well as OpenType, no?
> So a side point on the discussion.
Yes.
But there are indications that it was not a conscious decision. It has been confirmed as a bug that the "Typography" panel is now "disconnected" i.e. changes made there no longer have any effect on the type in Keynote or Pages. The underlying technology still works, because if you do apply small caps or other features in an old version of Keynote or Pages and then open the document in the new version, the features are intact. So it's just a UI glitch that the Typography panel and the iWork internals aren't communicating.1 -
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6gvar.html Other than Apple, who released AAT fonts with gvar tables?0
-
Does Apple releasing ones fonts containing gvar and cvar, count? Or are you trying to find out what other company would be so smart as to release, presumably after costly development, testing, (on what?) and marketing, into a print-only world, without a single gvar-savvy publication design app, while having to cope with the pre-web delivery, documentation and support issues of the time? And then I may be able to let you know if that info is free or not, comes with an Apache or OFL license, and which room here we could go to, to talk about it.;o
1 -
Does Apple releasing ones fonts containing gvar and cvar, count?
No I can see the fonts bundled with Mac OS X that have these tables, I'm wondering if there were ever any others. Or are you trying to find out what other company would be so smart as to release, presumably after costly development, testing, (on what?) and marketing, into a print-only world, without a single gvar-savvy publication design app, while having to cope with the pre-web delivery, documentation and support issues of the time?
I was in diapers at the time, remember, so I don't know if there were gvar-savvy publication design app(s); I guess AppleWorks or something like that supported the format. No?And then I may be able to let you know if that info is free or not, comes with an Apache or OFL license, and which room here we could go to, to talk about it.;o
As always, next time you're in New York then we can visit some fine dining, and I keep you posted when I head north
0 -
SoftPress' Freeway web design app still supports fonts with variations, such as Skia. Freeway started out as a word processing app with layout capabilities called MacAuthor Uniqorn, which was released around the time GX was being promoted.
http://www.softpress.com/freeway-pro/
1 -
Thank you Mark! I was unable to find a similar weight/width sliders in the TextEdit typography tools, but Freeway has them!
0 -
Why do you "disagree"?1
-
Sorry! I meant to hit INSIGHTFUL
1 -
Thought that might have happened.0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 802 Font Technology
- 1K Technique and Theory
- 618 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports