I finally had time to catch Adobe Nat McCully’s ATypl Tokyo 2019 presentation. He covers the topic that I have covered in depth many times before: the (sad) state of CJK typography. As Nat points out most software developers and system engineers talk about CJK support as typography without any idea of what it means. Throwing CJK glyphs on a screen is not typography, they are not the same thing at all.
The defining feature of CJK typography and layout in general and Japanese typography in particular is that space is an essential composition element equal with text and graphics, with fine space element control way beyond a baseline. Instead of thinking about how much space should be between text, flip it around and think about how much text should be between the space. Baseline font metrics will never deliver great CJK typography because there are too many limitations. So everybody implements the missing stuff on the fly and everybody does it different. Unfortunately the irony of it all is that Adobe played a huge role in how these limitations played out in the evolution of digital fonts, desktop publishing (DTP) and the situation we have today.
QuickDraw GX was probably the only time in computer history that fonts, layout engine and the basic OS came together to solve these limitations for all language systems, all language typography as equal from the bottom up. Parts of that effort survived, such as Apple’s San Francisco variable system font based on the TrueType GX model, and the inclusion of the TrueType GX model as the base technology for OpenType Variable fonts. Nice as this is, it’s only a tiny sliver of the GX vision pie that survived, all the other baseline font metric and CJK typography limitations still exist. Outside of a handful of people like Nat at Adobe, and the Adobe CJK typography ghetto approach of keeping all the good stuff corralled in InDesign J, very little is being done to address them.
Call me a pessimist but after 20 years of watching things slide sideways, I don’t see much hope for the future evolution of great CJK typography on digital devices. Most western software development people think that having CKJ glyphs on a screen is ‘good enough’ CJK typography, end of story.
Already I see the OpenType Variable Font effort devolving into a bauble for web developer geeks, always stuck in demo-hell, never going mainstream. It is the same story for quality CJK typography on digital devices. When the current Adobe CJK leaders like McCully and Ken Lunde reach retirement age, whom have devoted their careers to fixing these problems, I think it will be the end of an era. In many ways we are already there.
The new SF Symbols system font is a fantastic addition to iOS, macOS, etc. and it is an OpenType (née QuickDraw GX TrueType) variable font to boot. But please, Apple, the crusty old Font and Typography pallet has to go. Put the poor dead horse in its grave already. A fantastic new variable font from Apple screams for a nice new user friendly font UI to access those lovely glyph variations. If you don’t, nobody will ever find them. And that’s a shame.
The Japanese Flick News site reports that iWork/Pages/Keynote will finally gain vertical CJK text layout support with the major iWork update announced today with the new iPad Air and iPad Mini, that should drop at the March 25 Apple Special Event along with iOS 12.2. Mainland China and Korea have pretty much abandoned traditional vertical layout for books and newspapers over the years but vertical text layout is still very important for the Japanese market.
Microsoft Word is the only major word processing application that currently supports CJK vertical text layout across macOS and iOS. The late great egword Universal 2, the first top to bottom Core Text word processing app on the market, returned to macOS recently but has yet to appear on iOS. Robust vertical text layout support in iWork across macOS and iOS will be a great update but like all things, the devil will be in the details. As one eminent Japanese font engineer once told me regarding OpenType J fonts and the state of typography in most apps:
the only OpenType (Japanese) layout engine out there is InDesign (J)…(this) means you have to use InDesign to access OpenType advanced typography…no matter what kind of fancy fonts you have, they look bad with poor typography.
Apple has a long history of creating rich text layout and font technology that never makes it into their own apps. Case in point: the Core Text API that provides vertical text layout handling has been around since OS X 10.5 Leopard (2007), why has it taken Apple 12 years to add that support in their word processing app suite?
Update Major Japanese IT news sites and blogs are running the iWorks CJK vertical text support update story and screenshot without attribution. It smells like somebody leaked a press release in advance of next week’s event.
Update 2 A press source tells me that Apple sent out iWork update PR to select outlets with the iPad announcement. Why not just put it on the Apple web site where everybody can see it? It would create some positive buzz in the Japanese market where Apple needs it. This kind of boneheaded nonsense is sad commentary on how also-ran and unimaginative Apple PR and marketing have become.
Update 3 The update has arrived and the vertical text support is rather elementary level, almost useable.
OpenType Variable Font support in focused on browsers and Adobe apps
CSS is the main focus of variable font support
Typo Labs 2018 had some interesting updates on OpenType Variable Fonts (OTVF), where they are now and roadmap directions to the future. The most interesting presentation by far was Jason Pamental’s Variable Fonts and the Future of Typography. One benefit of using variable fonts in our era of multiple digital devices is that maximum readability for any given content can be optimized across devices with optical sizing which doesn’t sound very sexy but pays big dividends.
Apple leverages this with the variable font capability in their San Francisco system font. It’s the thing that makes Dynamic Type dynamic and has existed on macOS since the QuickDraw GX era, Apple’s TrueType GX fonts provided the technology base for OTVF. Pamental stresses that there are many more important benefits to variable fonts than just optical sizing and the future of digital typography needs to incorporate them. I strongly agree with Pamental’s view but I also see problems.
The initial focus for OpenType variable fonts has been CSS web development and optical sizing support is in already in Safari and Chrome with Firefox and Edge joining any day. You can see and play with variable font examples on Axis-Praxis (ignore Arphic’s hideous AR UDJingXiHei font, it’s some Chinese designer’s idea of a Japanese font). So far, so good.
We Have Been Here Before The real problem is going to be the same problem we had before with OpenType: advanced typography feature fragmentation. I interviewed one of the top Japanese font engineers back in late 2003, Tomihisa Uchida of Iwata Corporation and he explained the problem. At that time Adobe was pushing the Japan market away from the expensive Japanese Postscript printer font model to the dynamic font download model of OpenType Japanese fonts with PDF and InDesign J. What Uchida san said in 2003 is still true today:
I work with newspaper fonts and layout. Newspaper font designs are different because the text is always vertical. Fonts need good layout to look their best.(Japanese) OpenType has fractions, third-width and quarter width glyphs, but most applications are not OpenType-feature aware so it’s a real waste. The result is pretty ugly.
Right now, the only OpenType (Japanese) layout engine out there is InDesign (J)…(this) means you have to use InDesign to access OpenType advanced typography…no matter what kind of fancy fonts you have, they look bad with poor typography.
Advanced Typography Feature Fragmentation in Action You can see and test this problem for yourself on macOS with the recently revived egword Universal 2 Japanese word processor app and Pages. Hiragino Japanese OpenType fonts bundled with macOS are chockfull of advanced typography features (both AAT and OpenType tables) mentioned by Uchida san and much more: glyph variations, vertical substitutions, extended character sets, etc. The full set is listed in the crusty old macOS Fonts >Typography palette.
Hiragino has many advanced typography features but they don’t work across apps or platforms. Some listed features such as glyph variants are completely broken. Pages accepts some of the Hiragino advanced features but does not offer vertical text layout, a basic Japanese typography requirement because the Pages team only implements the lowest common denominator typography features that work across WebKit, macOS and iOS.
egword Universal 2 has excellent Japanese vertical and horizontal text layout but ignores Typography palette advanced fonts options in favor of its own app palette which only offers a sub-set of Hiragino font features.
The only place to use the whole Hiragino feature shebang is a trip to InDesign Creative Suite J. What’s the matter with you, don’t you have one?
egword Universal 2 ignores the Hiragino font features in macOS Typography palette but deploys a limited subset in its own palette
Pages accepts some Hiragino options offered in macOS Typography palette but glyph variants are broken in macOS Mojave
Variable Fonts and What’s Missing Where do OpenType Variable Fonts fit in this scenario? What and how are features offered and how does an app present them to the poor user who might want to use them?
The answer is something I have been trying to write about from my very first blog post and revisited last week. 3 years in I think I finally understand it: the QuickDraw GX vision thing. Not the API or any of the GX technology that westerners got hung up on missing the big picture:
QuickDraw GX, the vision part not the API, was the only major text layout architecture in a major OS I know of that treated all typography from anywhere as one single thing available to all applications. The Steve Jobsian ‘it just works’ for the entire world’s advanced typography.
The critical difference was the GX vision of the world’s advanced typography and layout as one unified common fundamental thing that just works and is available everywhere seamlessly across the OS and all apps. All this advanced typography stuff doesn’t work unless it is one unified thing. To paraphrase Uchida san ‘fancy fonts look bad with poor typography’. Without vision and focus OpenType Variable fonts will turn out to be fancy fonts that look bad most of the time.
Apple is the only company in the world that owns both the software and hardware across personal computer and mobile platforms so it comes down to 2 points.
If Apple can’t come up with an advanced typography vision again, OpenType Variable Fonts will suffer the same advanced typography feature fragmentation fate that OpenType advanced typography has suffered from all along: it will live in the Adobe app ghetto which is fine for the designers who live and work there, but it never leaves that world. It will be ignored by most of the developer community because they can’t figure it out on their own when different advanced typography features are fragmented and scattered across OS platforms and frameworks (UIKit, AppKit, Core Text, WebKit). And when app developers ignore it font developers are much less inclined to support OTVF, especially Japanese and Chinese font developers who have exponentially larger development costs than Roman based font developers.
When that happens typography remains stuck at the lowest common denominator feature set but users will never know the difference, or have the opportunity to find out. The end result is that after all this time, 22 years later and counting, fancy fonts still look bad with the poor typography we end up getting. That’s sad.
Only Apple can give us world savvy advanced typography and layout as a one thing OS vision model for the rest of us. That might be too much to ask for in this era where open web standards dictate what kinds of, ahem, western centric advanced typography we get, but if Apple can’t do it, nobody can.