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.

Advertisements

Apple Maps Japan Reboot Challenge: Real Progress

Now that Apple Maps image collection white Subaru vans are out and about in force with lots of people tweeting about it, it looks like Apple Maps has finally gotten serious about mapping Japan. We hope. I see 3 basic challenges:

Collect Quality Data
This is obvious and the whole point of Apple Maps image collection vans, but it’s not the whole story. Apple cannot do it all and has to rely on quality map data suppliers. Increment P (IPC) supplies Japanese map data to Apple but they are not the best quality provider and seem to collect and package other data sources rather than getting their own. Case in point, it took IPC 2 years to fix the Great Shinbu Hot Spring Data Cutoff. If Apple wants to go toe to toe with Google Maps in Japan, they should sign Zenrin who are the top map data provider for Japan. Google recently dropped Zenrin and Google Maps Japan has been a disaster ever since.

Process Quality Data
This has been the bane of Apple Maps since day one. I see it as Apple’s biggest challenge: if Apple cannot quickly and intelligently process map data from multiple sources, the best quality data collection effort, along with the data, is completely wasted. Let’s take a look at how well Apple processes IPC map data for the Ikegami Hall area and compare it to Yahoo Japan Maps and Google Maps.

Ikegami Hall

As you can see from the example, Apple isn’t using much of the IPC map detail available to them, including Ikegami Hall. Maybe somebody at the Apple Maps data processing center in India forgot to put it in, or is waiting for an update from an Apple Maps van. Either way, the Apple Maps team has no idea something important is missing and that in itself is a big problem.

Present Quality Data
In short, cartography. Good cartography doesn’t only make maps look good, it directs your attention to what is important to know, filters out extraneous detail so you can find what you are looking for, while showing how to get there quickly. Yahoo Japan Maps has the best cartography by far, Google Maps runs a distant 2nd place. However both of them constantly tweak their cartography and evolve it. Apple Maps has yet to substantially update their Justin O’Beirne 2012 era cartography and they desperately need to. Take a look at the Gotanda station area of Tokyo comparing the default views of Apple Maps, Google Maps and Yahoo Japan Maps. The quality improves going left to right.

Apple Maps cartography overwhelms the screen with information that doesn’t need to be there. Yahoo Japan Maps is super clean, smartly edited and easy to navigate. The captions explain it all, case closed.

The challenges facing the Apple Maps team in Japan are many. Now that Google has stumbled, Apple has a golden opportunity to create a better map service for Japan and change the market perception of it. I wish them good luck and look forward to seeing what progress they make.

UPDATE
Related coverage on the WWDC19 Apple Maps Wish List

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.


Almost Useable: Japanese Vertical Text Support in iWork Pages Update

CJK Vertical Text Layout in Pages and Bashō Haiku

Apple released updates for the iWork suite as promised, the biggest new feature is vertical CJK text support which should have been in place since 2005. Better late than never, here is a quick overview.

I’ll discuss vertical features from the Japanese typography point of view since vertical text is more important for Japan and Pages/Keynote/Numbers CJK vertical text is not offered in Simplified Chinese. In an era of devices where everything is horizontal, younger generations have grow up without the deep connection to traditional vertically written culture. Korea, and to a lesser extent the Traditional Chinese markets in Taiwan and Hong Kong, have pretty much abandoned vertical layout for mainstream newspapers, magazines and books which still flourish in the Japanese market.

Also Japan has the most comprehensive vertical text layout composition rules: the Japanese Industrial Standard typesetting and composition specification JIS X4051, the bible of Japanese composition and the only truly complete specification for vertical text composition in the world. I covered Japanese typography basics in another post but it’s important to remember a few essential differences:

Unlike DTP layout, which is graphics-driven, traditional Japanese text composition, called kumihan, is driven by how much text will fit in a given space. Designers know how many characters (virtual bodies) are supposed to be on a line and on a page before they start composition, and this is how they discuss layout with writers and editors. Western composition is calculated from margins, a wholly different concept.

kanji box 3
A virtual body Kanji with approximate baseline overlay red line.

It boils down to the western typography baseline rules and conventions which is what DTP layout and digital fonts were built around vs. Kanji virtual bodies which were never considered by software programmers back in the early 1980s. All written languages outside of the Roman Empire cultural heritage have been living with the limitations of those computer software decisions ever since. Especially in web browsers.

InDesign J gets around this limitation by creating Kanji virtual body information on the fly along with Adobe proprietary internal font metric tables. Everybody else who do not have their own typography and layout engine have to make do with OpenType baseline font metrics information, the advanced typography layout offered by Core Text, and their programming prowess.

The best Japanese word processing program egword universal 2, the first top to bottom Core Text word processor program, is proof that a focused and talented team can accomplish a great deal. egword universal 2 has grids and a well thought out subset of advanced Japanese typography features that satisfy most needs without overwhelming the user. It’s a testament of the the talent of Norihito Hirose and the Monokaki-do team.

egword universal 2 handles Kanji glyph variations with ease

Unfortunately Pages-Keynote-Numbers CJK vertical takes the low road adding as little as possible:

  • No easy access of OpenType/AAT advanced Japanese type features like glyph variations or proportional Kanji spacing, it’s the usual nightmare of hunting for features in the Apple Font Panel or using the input module
  • Importing Word Docs with vertical layout are not preserved and rendered in very bad horizontal layout
  • Last but not least: no ruby or furigana lousy ruby support
egword universal 2 ruby in action, ruby support is an essential feature for any Japanese language document creation

The last feature is so basic for Japanese document creation, it is mind boggling and embarrassing that Apple had the balls to offer CJK support without it in such an amateurish incarnation. The only CJK advanced typography feature offered is the ability to rotate groups of vertical glyphs horizontally, though it is a very amateurish, time consuming, one selection at a time affair.

Other than that, iWork CJK vertical text is almost exactly the same kind of simple implementation that macOS TextEdit has had for years. Short text strings of vertical text are okay for Keynote but the updated Pages is no replacement for Word or egword universal. And of course vertical text support is completely missing on web versions of Pages/Numbers/Keynote. No wonder Apple snuck the feature mention in a iWork update PR release to select media outlets instead of proper announcement.

Taken together with how many years it has taken Apple to get this simple low level of CJK vertical layout support into their word processor app, it is sad commentary on Apple’s advanced typography priorities in the post Steve Jobs era. It’s clear that Apple doesn’t care about advanced typography, they only say that they do.

UDATE
Ruby characters are available via context menu and have been for some time. Apple’s implementation is pretty bad and rotating vertical glyphs via context menu pop-up is very manual and not very good either.



UPDATE 2
I tried writing a Haiku using Pages vertical text support.