WWDC22 Wish List

It is hard to be enthusiastic about this year’s WWDC when Apple’s entire integrated software/hardware business model is coming under attack. With so much distraction these days there’s not much of a wish list, just a few observations for Apple Pay, Apple Maps and Text Layout.

Apple Pay
First up of course, is Apple Pay. After Jennifer Bailey’s WWDC21 appearance where she announced home keys, hotel keys, office keys and ID for iOS 15 Wallet, and the separate Tap to Pay on iPhone PR announcement release in January, I don’t think Jennifer will be in the WWDC22 keynote. She’s not going to appear just to explain that Apple Pay is not a monopoly, that’s Tim’s job with CEO level pay grade, it’s unlikely she’s doing to appear to just recap details of what’s already been announced.

Bailey’s job is to announce new features, and I don’t think that after the big iOS 15 rollout of new Wallet features and Tap to Pay on iPhone there’s nothing really new. And it’s not her job to announce new frameworks, that’s what the sessions are for. Things that I have been wishing for these past few years such include easier, more open NFC Pass certification process and/or new frameworks for developers to access the secure element for payments or use Tap to Pay on iPhone. There needs to a clearer path for developers who want to use the secure element for payments (Wallet) or iPhone as payment terminal (Tap to Pay on iPhone).

Apple needs to open up the NFC/Secure Element Pass certification process and clarify the process

The only possible ‘new’ Apple Pay Wallet feature I can think of is the long in the works Code Payments. It has been lurking in the iOS shadows since iOS 13, so long that Apple legal inserted official mention in a recent Apple Pay & Privacy web page update: “When you make a payment using a QR code pass in Wallet, your device will present a unique code and share that code with the pass provider to prevent fraud.” If Apple Pay delivers native device generated QR code payments without a network connection, just like all Apple Pay cards to date, it would be quite a coup but by itself, but probably not worth a Jennifer Bailey appearance. Other future goodies like passport in Wallet or ID in Wallet for other countires are too far out to mention, at least in the iOS 16 time frame.


Apple Maps
The only new Apple Maps feature that suggests itself is AR enhanced ‘Look Around’ indoor maps for stations. That’s the conclusion after examining the current (February ~ May 2022) backpack image collection in Tokyo, Osaka, Kyoto and Nagoya. It is highly focused on stations, and stations such as Shinjuku, Tokyo, Shibuya, Ikebukuro, etc., are mostly underground, surrounded with densely packed extensive maze like malls.

This means Apple image collection in Japan is going indoors for the first time, likely at pre-arranged times when people are scarce. This is hard to do at a place like Shinjuku station as multiple companies collectively manage the entire site (JR East, Odakyu, Keio, Seibu, Tokyo Metropolitan Bureau of Transportation, Tokyo Metro, just to name a few).

Apple needs something new with indoor maps as the current incarnation is inadequate for stations. As Google Maps Live has shown in Tokyo station, AR walking guidance is a good fit for indoor maps that navigate users through intricate, information dense underground station mazes, though Google’s version has its problems. New and improved, AR enhanced “Look Around” style indoor station maps with walking directions that seamlessly guide users from transit gate to final destination would be far more useful than they are now.

Recent image collection suggests Indoor Station Maps might be coming in iOS 16

Overall, I am not optimistic that Apple Maps in Japan can become a top tier digital map service. The local 3rd party map and transit data suppliers that Apple depends on to make up the bulk of the Japanese service are decidedly not top tier. Old problems remain unfixed. In the case of the main Japanese map data supplier things have deteriorated.

Increment P (IPC) was 100% owned by Pioneer but was sold to Polaris Capital Group in June 2021 with a new CEO (ex Oracle Japan) who quickly changed the name to GeoTechnologies Inc. Under hedge fund Polaris Capital Group led management the company has been busy inflating the number of cushy company director positions, never a good sign, and pushing out shitty ad-ware apps like Torima. The focus is leveraging assets not building them.

Apple’s Japanese map problem can only be fixed by dumping low quality GeoTechnologies for a top quality digital map supplier like Zenrin (the amateurish UK backed Open Street Map effort in Japan is not worth serious consideration) or Apple aggressively mapping Japan themselves. Apple has not pursued either option: the image collection effort in Japan is leisurely and limited, its use remains restricted to Look Around. Until this changes, expect more of the same old fundamental Japanese map problems in iOS 16 and beyond. Apple Maps is a collection of many different service parts. Some evolve and improve, some do not. Let’s hope for a good outcome with the data Apple is collecting for indoor station maps.


Apple Typography TextKit 2 migration
WWDC21 saw the unveiling of TextKit 2, the next generation replacement for the 30 year old TextKit, older than QuickDraw GX even, but much less capable. TextKit 2 marked the start of a long term migration with most of TextKit 2 initially ‘opt in’ for compatibility. We’ll find out how much of TextKit 2 will evolve to default on with an ‘opt out’. There are holes to fill too: the iOS side didn’t get all the TextKit 2 features of macOS such as UITextView (multiline text), some of the planned features like NSTextContainer apparently didn’t make the final cut either. We should get a much more complete package at WWDC22. Once the TextKit 2 transition is complete, I wonder if a Core Text reboot is next.


watchOS 9 Express Cards with Power Reserve?
Mark Gurman reported that watchOS 9 will have “a new low-power mode that is designed to let its smartwatch run some apps and features without using as much battery life.” While this sounds like Express Cards with Power Reserve (transit cards, student ID, hotel-home-car-office keys) and it might even mimic the iPhone feature to some degree, it will not be the real thing. Power Reserve on iPhone is a special mode where iOS powers down itself down but leaves the lights on for direct secure element NFC transactions. iOS isn’t involved at all.

Real Power Reserve requires an Apple silicon design that supports the hardware feature on Apple Watch, it cannot be added with a simple software upgrade. Until that happens, a new watchOS 9 low-power mode means that watchOS still babysits Express Cards, but anything that gives us better battery life than what we have now is a good thing. We’ll find out later this year if Apple Watch series 8 is the real Power Reserve deal.

Enjoy the keynote and have a good WWDC.

Stroke Fonts Forever

The start point is the end point. The first time I saw Japanese stroke fonts in action, I had the same revelation Steve Jobs did when he visited Xerox PARC and was blinded seeing the first Graphical User Interface: this is the way it’s supposed to work. Stroke fonts are the way digital Kanji based CJK fonts are supposed to work. But they don’t work that way.

When one set of cultural priorities drive a technology standard, everybody else outside that culture is forced to adapt. This is the duality of technology and context at play. In one context a technology can be constructive and foster innovation, in another context the same technology can be stifling or even destructive. When DTP and PostScript fonts (the baseline font metrics layout model) were brought to Japan (the virtual body layout model) in the late 1980’s, it was both. It brought some innovation, but didn’t address important market needs because the technology was western centric and deemed ‘good enough’ for everywhere else.

Limitations of current outline font technology and the Japanese glyph set problem
When writing Hiragino Shock, it struck me how little things have changed, that 20 years later the most basic problems of digital Kanji fonts are still with us: a poor imitation of traditional virtual body layout using inadequate baseline font metrics, large files for each different weight of the same font family, confusing collections of different glyph sets. Regarding the last one I wrote:

For many developers (Adobe included), creating larger and larger fonts was not the best solution to handle the ever-evolving character standards. Adobe did go on to create more Japanese glyph collections but their ability to rally the industry around them diminished over time. Back in 2002 I thought that most Japanese fonts would probably stop at AJ 1-4, leaving Apple in the enviable position of giving users a industry standard super-font with every copy of Mac OS X…not a bad place to be. It’s pretty much how things panned out.

Former Apple MacOS text and layout architecture engineer Yasuo Kida echoed the same opinion and nailed it in the Hiragino Shock interview:

Another regret was that we should have created a solid subset (or subsets) of Apple Publishing Glyph Set / Adobe Japan 1-5. Applications that really need the whole set of APGS are books. Display typefaces obviously do not need the whole set, nor do magazines and so on. We were concerned that font developers might think it necessary, or be pressured from customers to develop whole AJ 1-5 or whatever whole set for every single font that they have when it is not really necessary.

To demonstrate this was not the case, we intentionally left some of our bundle fonts with a smaller subset. But it was not enough, it did not establish a solid character set category that everyone can follow. I should have worked with Adobe to develop a good standard subset based on X 0213 and give it a name. AJ 1-4 is not a good subset as it contains itaiji that many of applications do not need, and it does not contain important characters from JIS X 0213. AJ 1-4 is effectively used as a fallback subset right now.

The necessary glyph set depends on the job. Japanese book publishers need the Adobe Japan 1-5 glyph set, Japanese newspapers publishers need Adobe Japan 1-6 or 1-7, most magazines can make do with Adobe Japan 1-4 while most digital device display for apps only needs Adobe Japan 1-3. The situation is similar for all Kanji based CJK font collections in their respective markets and countries.

Font creation and end-user dilemmas
So what are customers supposed to do? Buy the most expensive font license subscriptions with the largest variety of glyph collections for each and every computer? Mix and match? And how much time and effort goes into managing all that when the production line or designer is juggling many different jobs that require many different fonts?

Going back to the original list of problems, let’s look at large glyph collections and large font file issues as one problem, and examine that problem on the font creation side and the font use side.

First of all you have to create all those Kanji glyphs. One of the glaring deficiencies of current outline technology is that every single Kanji must be traced and tweaked extensively. A ‘Standard’ Japanese font has 9,354 glyphs, the Adobe Japan 1-4 character set has 15,444 glyphs, Adobe Japan 1-5 has 20,317 glyphs.

Take that total and multiply by each weight (light, demi-bold, bold, etc.) that has to be designed and tweaked. It can and does take years to create a high quality Japanese font family, and so it goes. You have an idea of how much work goes into font-making and why Japanese fonts are so expensive. Last but not least the font files themselves are large—anywhere from 3 to 8 MB each—because the basic outline model is not efficient for complex shapes like Kanji.

Font file size is one of the problems that TrueType GX née OpenType Font Variation format (OFVF) is supposed to fix, but none of the major Japanese font vendors has released anything in OFVF. It’s a lot more work to do OFVF with Japanese fonts and the payback on all that extra work just isn’t there.

Put another way, if your business choice is using limited resources, do you use those limited resources: (1) to create new font designs that delight customers using the same production methods, or (2) to update and re-release old fonts in a slightly more convenient web font format? It’s a no-brainer that font development resources don’t go into OpenType Variable fonts.

The stroke font solution: taking outline fonts to the next level
Any solution has to be two fold: better tools to create large collections of Kanji based CJK fonts more efficiently and economically, and better ways to use them on devices that capture that same efficiency and economy. Stroke fonts address both of these problems.

Stroke fonts have been around for a long time in various forms. The beauty and eternal appeal of the technology is that it is very efficient at creating a large number of glyphs from a small reusable library of parts. This makes them perfect for small, power and memory contained devices, like Apple Watch. In 1995 Fontworks International was busy developing stroke based Japanese fonts of their library that used their built customer font scaler and OFA. What’s that? Let me back up and explain.

Anybody who has studied Chinese or Japanese knows that although each Kanji is unique, certain parts, i.e. strokes, occur again and again, recombining to create new characters. You can get a good feel for this by looking at Chinese or Japanese calligraphy. The brush is the most natural way to write Kanji, and with a little study, you quickly comprehend the order of strokes.

A group of researchers at Stanford in the late 70s~early 80s created prototype ‘Chinese vector fonts‘ based on the Metafont79 system that attempted to use Kanji stroke parts for computer display complex fonts in the extremely restricted memory and storage environments of early computer systems. Don Hosek started a project to refine and enhance those concepts based on Metafont84 before abandoning it for lack of financial support.

One of the real groundbreaking but unnoticed features of QuickDraw GX was Open Font Architecture, OFA for short. It was a simple but powerful concept: plug-in digital font scaler architecture that let font developers create new font technologies that ‘just worked’ by adding plug-in scalers: a plug-in scaler for PostScript, a plug-in scaler for TrueType, a plug-in scaler for stroke fonts and so on. Asian font developers such as Fontworks and DynaLab used OFA to create GX stroke based fonts.

In a similar way to Chinese and Japanese calligraphy and vector font concepts, Fontworks International and DynaLab broke down their Kanji outline fonts into parts that loosely correspond to brush stokes. The crucial difference of these GX stroke fonts was that instead of earlier primitive ‘vector fonts’, they took outline font technology to the next level: smart outline stroke font technology for Kanji based fonts.

These smart outline stroke parts were kept in a library that the stroke-font scaler used to draw the character, resulting in a much smaller and more efficient font. At the time the Fontworks technical director, said that stroke technology “allows us to do weight variations over the full range from Light through Ultra Bold without losing typographic details all in a 4 MB font.” An equivalent OpenType Kanji font family can weigh in around 18 MB although a single OFVF file would likely reduce the size somewhat.

Stroke technology shines is character creation. Once a base library of stroke parts has been created, a designer can create high quality Kanji quickly and easily make adjustment and modifications. Fontworks then applied what they called ‘recipes’ to create different weights from the basic stroke part library. A key feature of the stroke font approach is that it preserves the stroke width as the part is scaled, which is impossible to do with regular outlines. This means efficient high quality blending is possible over the entire rage of font weights, difficult to with OpenType Kanji variable fonts.

Smarter stroke fonts take outline fonts to the next level

Post GX stroke font development
Tomihisa Uchida was the lead font engineer for the Fontworks stroke font project that had two goals: QuickDraw GX stroke font versions of the Fontworks library to be bundled by Apple in Copland OS, a font productions tool suite called ‘2X2’ that used stroke technology for glyph creation and editing, but could export in multiple formats (Illustrator, etc.). After Apple hit the kill switch on Copland, Fontworks scrapped their GX stroke font project. The 2X2 production tool morphed into Gaiji Editor that shipped in 2000. Unfortunately Gaiji Master was killed in 2001 when Uchida san left Fontworks and joined Iwata KK to lead their font engineering team.

Since retiring from Iwata, Uchida san is working again on a stroke font based production tool. He showed it to me in 2019. The video I took shows some the features: the ability to switch between ‘full outline’ and ‘stroke outline’, intelligent point handles for efficient part editing and much more. Watching it in action is like seeing his entire Japanese font engineering career knowledge compressed into an application.

Demo of Tomihisa Uchida’s stroke outline font editing tool. The ability to edit and switch back and forth from full outline to stroke parts might look mundane to the untrained eye but can greatly accelerate Kanji glyph creation

Stroke fonts saw quite a bit of action in Japan in the pre-iPhone handset era. The explosion of 3G Internet capable Symbian OS Japanese handsets with Docomo iMode and compatible services, leap frogging display sizes and specs demanded high quality scalable Japanese fonts that fit tiny storage and memory requirements. With their tiny overhead using a library of font parts to create a large variety of fonts, stroke fonts were the perfect solution. There were many handset stroke fonts: Morisawa had KeiType, Ascender Corp (later bought by Monotype) had Compact Asian font technology and Taiwan font developer DynaComware had DigiType.

Stroke fonts: a perfect match for smart devices
As far as I know, none of these are still used in the smartphone era. However the advantages of stroke font technology grow exponentially as device sizes shrink. Apple Watch, health trackers, AR glasses. Tiny compact high quality Kanji fonts with a wide variety of weights are essential. There are other non-Roman writing systems that could benefit as well. In 2016 industry sources said Apple was actively searching for “the best stroke font technology.” Maybe Apple plans to do something with it, maybe not.

The problem with OpenType fonts is not the technology, it’s simply that the current OpenType standard is a desktop era solutioin that has not evolved: it has not evolved to address the western cultural priorities that inform the standard, it has not evolved for the smart device era with storage and memory constraints. Let’s assume Apple is doing something with stroke fonts. They can fix a few problems:

  • Stroke font scaler and format: a stroke based system font doesn’t have to fit within the restrictive OpenType format, but it can be developed in mind to be upwardly compatible, if and when OpenType evolves.
  • Solving CJK glyph set confusion: because stroke fonts reuse the same basic library parts, supporting the largest CJK glyph sets is not a problem. It also makes CJK all-in-one fonts practical and also solves the problem with current CJK fonts: one design doesn’t fit every culture sensibility, what looks good to Chinese users does not to Japanese users and so on. Glyph variation ‘recipies’ for different cultural regions correctly display the versions that look best.

In addition to this there is one last problem not immediate to stroke fonts but related to vertical layout. As Adobe’s Nat McCully pointed out, ‘real’ vertical layout is impossible to do across apps and on the web with the current OpenType baseline model:

  • 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
kanji box 3
A virtual body Kanji with approximate baseline overlay red line.
character spacing@2x
Character spacing and tracking are different concepts in Japanese typography as well.
Kumihan character spacing is the amount of space measured between outer virtual box boundaries, the 10% red area
On the other hand tracking, ji-tsume in Japanese, is the amount of space measured between type face boundaries and virtual body boundaries, the blue area

Right now InDesign J is the only application that does real vertical layout because Adobe created proprietary Japanese font table metrics for virtual body layout. There needs to be open standard virtual body metrics included in font tables for robust real vertical layout that works across applications and on web pages because using CSS will never cut it. Along with the stroke fonts Apple could deploy new AAT tables incorporating virtual body metrics, again in mind to be upwardly compatible at a later time, just like TrueType GX variation font AAT was for OpenType variable fonts.

Not that any of this will happen, but I wanted to write about it one last time in the hope that by laying out the issues, the solutions can somehow live on. The end point is the start point.

Many thanks to Tomihisa Uchida and many other great folks from Fontworks, Iwata, Morisawa, Adobe and Apple who shared their time, thoughts and opinions over the years. It was a blast.

ありがとうございました!