Featured

The Buddha’s face is only seen thrice

There is a Japanese saying: the Buddha’s face is only seen thrice. It can also be roughly translated as: a person can only behave like a Buddha 3 times. It’s a reference to human nature that we humans aren’t always good at being good or following rules, or obeying COVID lockdown state of emergency protocols forever. We can behave like a Buddha 3 times, after that forget it.

It’s also a warning to those in power: don’t push people too far, there are limits. This is happening now with the 3rd Tokyo State of Emergency, curtailed store hours, closed cinemas and reduced transit operating schedules are much less effective than they were the first time a year ago during Golden Week 2020. SOE 2 was less effective and SOE 1, SOE 3 feels pointless. Companies are not cutting back or reducing hours, trains are crowded, the evening before SOE 3 went into effect people rushed out to bars and restaurants. And so on.

No matter what emergency the Tokyo government announces down the road, people are not going to put on a face of the Buddha for a 4th time. What people really want is the Tokyo government to think and plan, what they are elected to do, and come up with a better long term course of action than simply hitting the same ‘state of emergency’ panic button again and again.

May the Pfizer be with you

My partner is a doctor so from day one of the COVID crisis I have been listening to a few mantras: 1) Vaccinations don’t stop people from getting infected, they lessen the severity if you do, 2) COVID is basically a cold virus so learning to live and deal with it, with good treatments instead of vaccinations, is the best long term adaptation, 3) Extensive PCR testing is a waste of time and money (especially at this stage, but a good money maker for the providers).

When the local city government started the vaccination reservation program in June we signed up for a first shot today, July 30. It seemed like an easy decision then, but as reports from heavily vaccinated Israel and UK that infections were picking up because of the Delta variant, which the Pfizer and Moderna vaccinations don’t cover, the mood started to change in the Japanese medical community. A wait and see mood as the Japanese developed vaccination is said to be available by the end of this year. Better to wait for a new improved vaccination than a 3rd round of the same old current one that is quickly loosing traction. Sure enough vaccinations rates started to stall this week as similar sentiments spilled into the general public.

And there is the vaccination certificate brouhaha. I want to visit my father next spring but getting a vaccination now means I have to get it all over again as the Pfizer•Moderna shots are only good for 4 months…if vaccination certificates are required to travel from Japan to America. As of today, they are not, although things can and do change every single day.

And so it went with every new piece of research and field report. Reasons to get vaccinated, reasons to wait. Even in the midst of uncertainty I’m thankful for the relatively level headed Japanese approach compared with hysteria driven all over the place media narratives I see in America. The most level headed piece I read was a recent Slate piece, The Noble Lies of COVID-19, that helped me understand the USA situation, along with Alex Berenson’s Here We Go Again and the long detailed On Driving SARS-CoV2 Extinct by Heather Heying and Bret Weinstein.

After talking about it all week we decided to go ahead with our vaccination reservations. But that doesn’t mean we don’t have any reservations about it. I think a lot of people are feeling the same.

The Weekly

July 27, 2021

The ‘Apple Pay is a monopoly’ soap opera continues

ZDNet reports Australian Parliamentary Joint Committee on Corporations and Financial Services hearings that are focused on, yet again, forcing Apple to ‘open up’ their NFC chip. Actually they should be talking about the secure element in Apple Silicon because that’s what Apple devices use and it’s not just about NFC anymore, it’s Ultra Wideband too.

The Apple Pay monopoly debate isn’t new and isn’t about being ‘open’, it’s about banks getting what they want from politicians. What I found interesting was the back and forth between Apple and Google regarding the hardware embedded secure element (eSE) vs. the virtual secure element in the cloud Host Card Emulation (HCE), a topic that confuses many ‘experts’.

Google is playing both ends here because they have different flavors of Google Pay for different kinds of Android devices. Google Pixel Google Pay uses eSE while everybody else use HCE Google Pay. One very important thing not mentioned in tech blog coverage is that Samsung Galaxy and the Chinese smartphones (Huawei, OPPO, Xiaomi) all use a custom eSE with their own XX-Pay. In other words, everybody on the Android side outside of low end junk is doing exactly what Apple Pay is doing.

Apple
Host Card Emulation (HCE) is a less secure implementation, which was adopted by Android … Apple did not implement HCE because doing so would lead to less security on Apple devices.

Google
Our payments apps are immensely secure…we would refute the suggestion our HCE environment is in any way insecure … I would argue the user experience on Google Pay is equal to that of Apple Pay.

Let’s see what GlobalPlatform has to say about HCE:

GlobalPlatform
HCE solutions can be a great option for issuers to get to market cost-effectively for their Android customers. However, they aren’t without their complexities. Rooted in the NFC device OS, HCE apps can be more vulnerable than the ‘Giant Pays’.

So HCE security is up to the payment app, shitty app = shitty security without Apple Pay Secure Intent. The whole HCE debate is nonsense, like FeliCa Dude says it’s eSE or nothing. If the committee thinks that HCE means open and good, they are showing their incompetence.

Apple Pay Wallet has a very simple rule: any card that loads a Java Card applet into the secure element has to reside in Wallet. Any card or developer that wants to loads applets and use the secure element has to have a PassKit Secure Element Certificate Pass. This is covered by NDA but a company called PassKit (not Apple) gives us an idea what Apple’s NFC/Secure Element Pass guidelines are:

Apple care a great deal about the user experience. Before granting NFC certificate access they will ensure that you have the necessary hardware, software and capabilities to develop or deploy an ecosystem that is going to deliver an experience consistent with their guidelines.

Yeah, the end to end user experience, the whole reason behind the success of Apple Pay. Banks don’t want to be told they need to improve their ecosystem for a better user experience, and they don’t want to pay a transaction cut to Apple that they are used to keeping for themselves. What else is new?

The whole ‘Apple Pay is a monopoly’ soap opera is overrated.


PASPY transit IC card migrating to QR

After thinking out loud recently about dumping their PASPY transit IC card in favor of a QR Code smartphone app, Hiroshima Electric Railway Co. Ltd (Hiroden) CEO Masao Mukuda announced that Hiroden would indeed junk NFC and migrate to a QR Code app over an unspecified period of time. Running their own transit IC card is too expensive, so old folks, school children and everybody else will have to use smartphone to ride Hiroden light rail trains in Hiroshima.

PASPY is just the tip of the iceberg. There are many transit IC cards out there with the same problem: fixed infrastructure costs supporting a small region transit IC card and declining ridership. Add the COVID crisis that has decimated public transit use and you have a business crisis. All the small transit cards outside of the Transit IC card standard (the pink box) are in the same boat: they can only be used in their respective regions, they don’t have e-money functions, they don’t have the resources to go mobile.

This is exactly the problem JR East is addressing with their 2 in 1 Suica MaaS soution. JR East hosts the hardware, the local operator issues a ‘localized’ Suica that offers both special local MaaS services (discounts and extras, etc.) and seamlessly plugs into the larger Suica and Transit IC map.

Suica 2 in 1 region cards are the keystone of JR East’s MaaS strategy

Unfortunately PASPY is in the JR West region which doesn’t have anything similar to the JR East MaaS program. It would be a perfect solution: customers would get a new card that works just like it does now but works everywhere with e-money and ICOCA benefits, Hiroden is freed from the costs of hosting and issuing their own card.

QR is not going to be the salvation that Hiroden hopes it will be. QR isolates Hiroden from the wider transit IC network of Mobile Suica, PASMO, ICOCA. Even if Hiroden gets rid of their card issuing business cost, they still have to host a system to run the QR Code app and manage accounts. The real rub is that instead of anybody buying an IC card out of a machine, Users will have to sign up for the app or buy a QR paper ticket. They also have to worry about where and how their account data is stored. My prediction: it’s going to be a messy money losing transition.


Heraiza down but not out

Poor little Heraiza, one of my favorite Japanese YouTubers, has been copyright claim ‘hacked’ from a fake account pretending to be Dentsu and now has 2 bogus strikes against her YouTube account. As an independent 17 year old high school student with 150,000 followers, she doesn’t have the resources of a YouTuber managment agency like UUUM, who she likes to badmouth (and I won’t put it past UUUM using fake accounts to take her out). Dentsu or whoever the real copyright holder is has confirmed to her that her content does not violate said copyrights.

Hopefully she’ll get it all worked out and unlock all her previous videos, though YouTube being YouTube, if they don’t like you they ban you…AND keep your ad revenue. In her most recent post about one of her favorite YouTubers having their account hijacked, she has her confidence back. Good thing, in these dark times we all need to laugh.

Have a good week and enjoy the Olympics.

The Weekly

July 27, 2021

With so little real news to write about these days, I’m trying out a weekly digest format instead of individual itty bitty posts. Sticking with a mundane regular schedule is also good practice, we’ll see how it goes.

Tokyo 2020 TP Transit Card
Foreign media (already in Japan as opposed to those coming for the event who are limited by protocols for the first 14 days) covering the Tokyo Olympics were issued a special ‘TP Card’ limited transit pass covering Tokyo region transit July 10~ August 11. Dan Orlowitz who covers sports for the Japan Times tweeted some pictures of the pass. Look carefully at the transit gate display screen, there are some very interesting things going on: (1) The display language is English (nice touch), (2) The card balance is 0. The card itself is issued by JR East and is a Suica commuter card with a 1 month pass and the balance turned ‘off’, that is to say that TP Card numbers are ‘block listed’ for any recharge function.

The TP Card shows a way forward for Transit IC (Suica, PASMO, etc.) that started with Welcome Suica: more flexible options, discount and special passes for all kinds of users and uses. The next important step will be getting these, along with 2 in 1 Region cards, on mobile.


Is Apple Pay Overrated?
What technology works and doesn’t work for people in everyday life is always a fascinating subject. Mike at Tech702 asks a good question: is Apple Pay overrated? For Mike in daily Las Vegas life, yes Apple Pay is completely overrated. I saw much of the same during my Salt Lake City summer stay in 2018, although Smiths grocery had just started taking Apple Pay at the time. Did they pull the plug? It’s a good reminder that retail chains and banks in America switch loyalties without notice and the payments infrastructure is all over the place, witness Targets changing their accepted credit card lineup when I was in Salt Lake.

Some snobby Europeans like to look down on America and other places they perceive as not being up to speed with contactless payments. The truth is when Japanese journalists like Junya Suzuki take a good look at state of European contactless payments, it’s not so great either. The state of contactless payments around the world is still very much a touch and go thing.


iOS 15 Beta 3 Score Card
iOS 15 reached beta 3 last week. Here’s how it’s panning out:

Apple Maps new cartography continues to evolve. Japanese roads were decolorized, railway lines are different and drawn in harder to see light blue. Overall I think dark mode is works better than light mode (better contrast, easier to pick out details, etc.). See Justin O’Beirne‘s page for details. Transit Notifications are also improved slightly but still only work for surface transit. Forget about using it on the subway. Despite the fancy redecoration Apple still refuses to label the Sea of Japan (since 2020). Unnecessary, dumb and insulting.

Weather App: still only shows temperature maps which I think are useless. Forget about precipitation which is the killer feature for any weather app worth using. Air Quality doesn’t apply to Japan as there is no national standard.

Last but not least, Apple Music and Apple TV are basically useless in iOS 15 b3, more 3rd party app are crashing too. Hopefully b4 will be stable.


Ossan’s Love in Hong Kong?
Just when I thought the Ossan’s Love franchise had run out of gas, it seems the Hong Kong version of the Japanese series is also a hit and making waves instead of giggles, although calling it “sugar-coated marijuana” is pretty funny. If the Hong Kong version is anything like the Japanese one, it is sugar-coated silliness. For my money the other Japanese hit gay themed series ‘What did you eat yesterday?‘ was not only a lot more engaging, funny, serious and thought provoking, it was also useful as a cooking show. Kinda like Shinya Shokudo (Midnight Diner) with better interior decorating and worth the time investment.

Have a good week and enjoy the Olympics.

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.

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

Apple text layout architecture evolution: TextKit reboot

No matter what kind of fancy fonts you have, they look bad with poor typography.

Tomihisa Uchida, former lead font engineer of Shaken, FontWorks, Iwata

As I wrap my typography related writing, it’s fitting to post about Apple’s text layout architecture evolution one last time. There have been a few changes over the decades. Actually it has been nothing but changes, going forward, pulling back, going forward again in bits and pieces instead of one united comprehensive vision.

Part of my current job includes dealing with lots of vertical text Japanese documents with lots of traditional Kanji characters that juggle different Japanese encoding standards depending on when the documents were created. For that reason I’m keen on robust vertical text layout and easy to access, easy to use high end Japanese font typography features. InDesign is there but its high end page layout features are overkill and time consuming when a good word processor will do.

Unfortunately there are very few choices outside of the Creative Suite world. Japanese high end features in Word are clunky and confusingly scattered around the UI, Pages vertical text and advanced font feature UI is a joke. The best Japanese word processor on macOS is egword Universal 2, egword has a long history and has used every single macOS text engine at some point. It’s a miracle that it survived. Why it is so hard to get international savvy, insanely great typography and layout features that should be standard and universal?

QuickDraw GX is the start point for built-in high end typography on personal computers. Thought it was short-lived, GX parts and concepts live on in Apple OS platforms to this day such as the SF variable system fonts. It’s hard to explain how revolutionary GX was in the Asian markets and how much exciting development was going on at that time, utterly impossible to comprehend from the western biased wikipedia entry. Suffice to say GX was the first text layout architecture were all writing systems, languages, various font technologies, scripts and layout models were equally and very well supported, right to left, vertical, contextual and so on.

After Copland OS was cancelled in August 1996, GX text technology morphed into Apple Type Services for Unicode Imaging aka ATSUI. ATSUI along with Apple Advanced Typography (AAT) font tables were some of the technology that made the Hiragino Apple Publishing Glyph Set feature, aka Hiragino Shock, possible in OS X 10.1. The better performing Cocoa based 64-bit Core Text replaced 32-bit Carbon ATSUI in OS X Leopard. macOS Lion AppKit finally gained some vertical text support but it wasn’t very robust as was demonstrated later when TextKit functions migrated to UIKit in iOS 7. The lead font engineer of Iwata Corporation had this to say:

UIKit (TextKit) doesn’t support real vertical text layout, the Japanese punctuation and glyph spacing are all wrong. The easiest thing for an app developer to do is bundle a display only Japanese vertical font just for displaying vertical text in the app. Go ask the programmers at Monokakido, I’m sure that’s what they have to do for their iOS Japanese dictionary apps.

‘Real’ vertical text layout remains a low level Core Text coding exercise which Apple really doesn’t encourage unless, “you must do text layout and font handling at a low level, such as developers of layout engines. You should develop your app using a higher-level framework if possible.” In other words, use TextKit.

I suspect one reason for Apple’s recommendation to use TextKit instead of Core Text whenever possible, is the parade of Core Text rendering bugs and security leaks that started cropping up in 2013 and continue to trickle. Therefore high level TextKit in iOS UIKit and macOS AppKit is the preferred text layout method as it abstracts away Core Text grunt work and exposing potential Core Text rendering and security bugs.

There’s a trade off however: TextKit is 30 years old, far older than Core Text, older than GX even, and shows its age. It’s the last NextStep holdout that never got an upgrade, its text layout features and performance are good enough, but not very good. Apple recognizes this and is finally doing something about it: TextKit 2, Apple’s next-generation text engine.

The best place to start for all things TextKit 2 is the WWDC21 video: Meet TextKit 2. The big new takeaway points are:

Non-linear viewport-based layout: TextKit 2 only lays out the appropriate text area that needs to be displayed • edited unlike linear layout which does the whole text document sequentially. You are probably familiar when scrolling long text documents and it takes forever for the text to render down to your current location, like standing on the beach waiting for the last tip of a wave to creep up and reach your feet. That wait is gone in TextKit 2.

TextKit 2 does this using viewport-based layout and rendering. When I saw the WWDC video my first reaction was ‘this reminds me of that shitty new WordPress block editor.’ Other developers had the same reaction. The thing is, once you get used to the shitty WordPress block editor, you don’t want to go back. It’s way more convenient even if the performance isn’t great.

The new TextKit 2 block editor approach promises to deliver convenience and high performance along with, “a robust set of customization points, making it simple to extend the layout system and add your own behaviors” that “also lends itself well to mixing non-text elements into your text layout.” Great, just what I wanted, more emoji + text + whatever-you-want-to-insert-here mishmash.

Glyph Abstraction: aka correct rendering for complex scripts because Apple does the grunt work (in Core Text) so you don’t have to. It removes the drudge. On a practical level text selection will work correctly no matter the script or language. With UIKit•TextKit 1, text selection is never reliable even for Japanese.

Safety aka more abstraction: there’s a huge middle section that discusses the bulk of the new TextKit 2 calls and how they work, the goal being using layout ‘elements’ instead of glyphs, strings, paragraphs, etc. Like glyph abstraction, it’s another kind of abstraction and illustrates the TextKit 2 mantra of using higher level objects to control layout. Eliminating the many TextKit 1 layout details developers have to juggle is a good thing.

Inclusive layout yes, but is it high quality layout?
TextKit 2 is the start of a long term migration. When it is done I think we’ll just have TextKit 2 that is simply called TextKit. For now, most of TextKit 2 is ‘opt in’ for compatibility. macOS 12 has all TextKit 2 functions, on the iOS side, UITextField (single-line editable text) has been updated to use TextKit 2 but UITextView (multiline text) has not.

The migration is going to take a while. I don’t think we’ll get the full TextKit 2 story until WWDC22. Once the transition is complete I suspect Core Text 2 is next. We’ll see. Japanese developer reactions have been muted along the lines of, “Apple wants to be inclusive, which is nice, but it doesn’t look like a high end solution.” After all, Japanese developers have been down this road many times before.

And so we circle back to my original question, does TextKit 2 finally deliver international savvy, insanely great typography and layout as standard universal features all developers can implement easily in apps? Definitely maybe…for apps, but never for the web. That’s a whole other story.