Apple Advanced Typography Request #999

oh where can my glyph variations be? oh where, oh where…

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.

Advertisements

The State of CSS, Japanese Layout, Open Type Variable Fonts and why Apple News+ won’t happen in Japan

It’s an open secret that Apple doesn’t really care about advanced typography, they just say that they do. The laughably amateur vertical text support feature recently added to iWork Pages makes that clear. If you have any interest in what professional Japanese typography really is, check out Nat McCully’s presentation on Japanese layout he gave at the Japanese Electronic Publishers Association meeting (JEPA). Both his Japanese video presentation and materials are online and well worth your time.

I knew Nat back in the 1990’s when he was an engineer at Claris responsible for the development of the highly successful Japanese version of ClarisWorks. I think he also worked on a QuickDraw GX version of ClarisWorks until GX was killed in 1997.

Luckily for us, he moved from Apple to Adobe in 1998 and put his extensive knowledge of advanced Japanese typography and programming skills to help solve a big problem: the inability to reproduce beautiful Japanese layout (kumihan) on western created layout software and fonts of that time (Quark XPress, Illustrator, InDesign 1.0, etc.). McCully explains the background and 2 year development of InDesign J at the 10:25 mark in his presentation, and the challenges of working around the limitations of baseline font metrics while developing good line break algorithms for Japanese layout.

The result was InDesign 1.0 J which shipped in early 2001. InDesign J was the first, and only, major software application developed outside of Japan that followed the Japanese Industrial Standard (JIS) X4051 typesetting and composition specification (the kumihan “bible”) and traditional Japanese print production methods. I have covered some basics of Japanese layout before, but a review is helpful for first time readers. I’ll use a mix of my material and McCully’s presentation to explain.

Japanese Layout Basics: Space

Japanese culture is the only culture I know of where the central core cultural value is subtraction: how much can we take away to bring out the essential beauty of an object. This is embodied in ikebana, in Japanese gardens and in people: the Kanji shitsuke 躾, inadequately rendered in English as ‘discipline’, is a Kanji that originates from Japan, not China. Western culture and Chinese culture are similar in that the central cultural value is addition: how much can we add that’s not here to make an object more beautiful.

The central core value of traditional Japanese text composition and layout, called ‘kumihan’, is space. Kumihan is driven by what text will fit in a given space, how to balance and minutely control that space. Kanji characters are contained in little boxes of space, known as virtual bodies, also called the grid system because the middle of each box is one center point on a grid. Everything is calculated from the center and the space surrounding that center; there is no baseline.

top image@2x
The red line is the outline of the virtual body, the blue line is the type face boundary. The standard size virtual body comes from the era of moveable type.
A virtual body Kanji with approximate baseline overlay red line.

Western created DTP layout is graphics-driven and calculated by margins and font baselines. The western baseline typography model and font metrics is how PostScript and OpenType fonts, and all layout engines evolved. Adobe was well acquainted with the shortcomings of their own font technology and InDesign J got around the problems by adding proprietary Kanji virtual body font metrics and Japanese line break algorithms.

That is fine for InDesign and print production, but web layout and typography via CSS is an entirely different world. There are 3 huge obstacles for good vertical Japanese typography on the web:

  • No font metrics for virtual body/em-box glyph space placement: everything has to be accomplished with baseline metrics
  • No reliable space control
  • No reliable line breaks

In the presentation McCully highlights a web post from Vincent De Oliveria that neatly summarizes basic problems of working with CSS:

Line-height and vertical-align are simple CSS properties. So simple that most of us are convinced to fully understand how they work and how to use them. But it’s not. They really are complex, maybe the hardest ones, as they have a major role in the creation of one of the less-known feature of CSS: inline formatting context

(summary)

-inline formatting context is really hard to understand
– vertical-align is not very reliable
a line-box’s height is computed based on its children’s line-height and vertical-align properties
we cannot easily get/set font metrics with CSS

Deep dive CSS: font metrics, line-height and vertical-align

This is further complicated by all the devices out there. A Japanese web page that looks good on iOS looks terrible on Samsung Galaxy because Samsung has a different layout engine that has a different idea of how to use space.

The end result, as McCully concludes in his presentation, is that quality Japanese vertical layout on web pages is very difficult to achieve. It requires a massive amount of extra work dealing with CSS limitations and optimizing things deep in the OS layout engine level such as iOS/macOS Core Text.

Failure of Open Standards

It’s helpful at this point to remember the key goals of QuickDraw GX:

  • Treat all writing systems and layout models equally as one single layout package
  • Make advanced typography a comprehensive high level framework that is standard across the OS and applications, simple to use for developers, and easily available to all users

People only remember the failure of GX technology at a time when Apple was spinning out of control, but the goals were, and remain, visionary and timeless. GX was about breaking advanced typography out of a niche to make advanced typography of all writing systems a widely used standard feature for developers, and for users. Unfortunately those goals were forgotten in the rise of web technologies and open standards like CSS and EPUB which focused on improving web based text only from a western typography perspective. Vertical text layout almost didn’t make into the EPUB format until a small but vocal group of Japanese programmers argued for its inclusion. They encountered a lot of resistance along the way, which seems to be the case for any feature outside the immediate needs the western typography perspective.

What we have now are web technologies and OS text layout engines that offer advanced layout from a limited perspective for a limited set of web designer programmers. In other words, niche. We can see the same thing happening with OpenType Variable Fonts. They are mostly for the web. They will remain niche. They will remain western due to the high development costs of creating OpenType Variable fonts with huge glyph sets like Japanese.

It’s an unfortunate situation, but without a vision and strong leadership, the smart people in the room always run off in different directions creating an animal farm of different ideas and approaches pulling in different directions. That’s what open is. Very rarely does it coalesce into a tight integrated whole greater than the sum of the parts.

In the eternal words of venerable Japanese font engineer Tomihisa Uchida, “no matter what kind of fancy fonts you have, they look bad with poor typography”. Which brings us to Apple News+ and why it will never see the light of day in Japan: Japanese customers will never pay for a news subscription service that doesn’t deliver good looking vertical text content. The Apple News Format can’t pull that one off, and Apple is not going to spend the resources to do it right. The iWorks vertical text support feature is certainly proof of that.

iWork Pages Celebrates International Haiku Day with Vertical Writing

Today is International Haiku Day and Apple Education is celebrating it in Japan with the new version of iWork Pages that finally supports vertical text layout. In honor of International Haiku Day and vertical text support in Pages, I tried writing a haiku in vertical text using the new version of Pages. This is how it went…

Let’s see, I want to rotate the roman characters to stand vertical like they do in traditional ‘Tate-Chu-Yoko‘ Japanese layout.
Oh wait, Pages vertical rotation only works in groups 2~3 characters. Anything less or more does’t work. How about if I split them up.
Okay this isn’t working, but I have an idea…
I’ll just use egword Universal 2 instead. Problem solved with the Tate-Chu-Yoko setting.

Update: Japanese reactions to the Apple Education ad (top screen shot) now running on Twitter are fun and sarcastic: “Are you serious? Way too late,” “Good thing I didn’t wait and installed egword,” “10 years too late,” “Oh, Pages is finally useable,” etc.

The Apple Stock app widget needs some Japanese localization work

Japanese company names in the Stock app widget

Good localization is never easy, that is to say it’s easy to fuck up, especially when different app pieces come from different companies. I already pointed out that the Yahoo supplied backend Japanese data took a real nosedive after the Verizon purchase, but there is more.

Japanese stock ticker names in the Stock app widget are hideous to look at. They shrink into oblivion instead of intelligently truncating a long name to keep it readable. This is a textbook case of how not to do app internationalization. Nobody at Verizon or Apple evidently cares enough about quality to fix it. It’s another nail in the coffin of Apple’s typography legacy.


The State of OpenType Variable Fonts vs. Advanced Typography Feature Fragmentation

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 font options
Hiragino advanced font features are found in the Typography palette but they don’t work across apps or platforms, some options are just plain broken

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?

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.

Apple’s advanced typography technology lineage goes back to QuickDraw GX

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.

  1. 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.
  2. 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.