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 multilingual internationally savvy text layout architecture where 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.

Inside Hiragino: Hiragino Shock and Apple Publishing Glyph Set

The Hiragino fonts in OS X

The transition to macOS X was a very interesting time for the Japanese publishing industry. In his first official appearance in Japan after returning to Apple, Steve Jobs turned the publishing industry on its head when he announced at MacWorld Tokyo 2000 that Apple would bundle professional Japanese fonts licensed from Dainippon Screen with extended character sets: “Capturing the beauty and richness of the Japanese language and kanji characters has always been beyond the capabilities of personal computers. Now, with premium quality fonts and the largest character sets ever, Mac OS X will make high-quality publishing a reality in Japan for all customers—professionals and first-time users alike.” At the time I wrote a report for MacInTouch:

Steve Jobs made a very big deal about kanji fonts and making MacOS X “the best kanji operating system” by licensing 6 ‘Hiragino’ font designs from DaiNippon Screen. It played well in yesterday’s keynote and the demonstrations today. And it is exciting that Apple is addressing some basic problems of Japanese publishing. Apple said these new ‘X’ fonts will use the new Adobe Japan 1-4 and JIS encoding standards unveiled at the last Tokyo Seybold Seminars 1999.

The official unveiling of bundled Hiragino (also used as the OS X Japanese system font, still in use today) was the February 2001 MacWorld Tokyo keynote just one month before OS X shipped. Steve:

As you may know, there have never been good Japanese fonts shipped in a personal computer operating system. If you want want to get over 8,400 characters and if you want to get very beautiful fonts you have to pay a fortune to go license these fonts on a per computer basis.

What we have done is we have licensed the most beautiful Japanese fonts around and we are bundling them in every copy of MacOS X. 17,500 characters…characters that just don’t exist in normal computer font sets. Characters that you cannot get on a personal computer without paying a lot of money. All bundled into MacOS X. I don’t think we’ve seen anything like this before.

MacWorld Tokyo 2001 keynote

Indeed the market had never seen anything like it and coined a new word: ‘Hiragino Shock’.

The Japanese font problem
To understand Hiragino Shock, it’s important to understand what was happening in the Japanese print market. It was a strange post bubble time when the migration path to the newly announced OS X and ATSUI Carbon framework was not all that clear. Just before OS X launched I wrote about the situation for The Seybold Report.

Japanese DTP arrived with Apple’s NTX-J PostScript printer and Linotype’s first Japanese PostScript imagesetter in 1989. They came at the right time: The early ’90s economy was bubbling, companies had money to burn and Japanese DTP took off. It was a young, booming market and it forgave many mistakes that would haunt the industry later.

By 1996, the go-go days were gone and they would not come back…DTP tools (Quark Xpress, Illustrator, Photoshop and, to a smaller extent, PageMaker) had captured nearly 40 percent of the production process. For a conservative industry like Japanese publishing, this was phenomenal―until compared to the West. There, in the same amount of time, practically the entire industry converted to DTP production. Japan is still about 40 percent and holding.

The Second Wave of Japanese Desktop Publishing, The Seybold Report Volume 30 Number 6, November 2000

DTP growth leveled off because market leader Sha-Ken refused to license their font library for PostScript, keeping it locked to their proprietary hardware, and because the first Japanese PostScript font format had severe limitations: they were a 1 byte hack with horrible performance issues that had to reside on a hard disk attached to the printer, they had small glyph sets and were very, very expensive.

A single unlimited resolution Morisawa PostScript font for an imagesetter cost ¥218,000. A basic set of 5 Morisawa fonts was a requirement for every Japanese PostScript licensee. When I was the imagesetter product manager at Heidelberg PrePress (old Linotype-Hell) our #1 customer request was for imagesetters without bundled Morisawa fonts, but our hands were tied by Adobe Morisawa Japanese font duopoly licensing.

Adobe and Morisawa addressed some of the original PostScript problems with CID, the first 2 byte PostScript format as a forced upgrade. The per font CID upgrade was not only expensive and time consuming (the floppy disk era), it also changed font metrics and Kanji designs. At the time Morisawa admitted customer reaction to the CID upgrade was negative: “Our biggest marketing challenge is how to explain all this to customers. We understand how customer feel confused. Part of the problem was that Adobe took so long coming out with CID.” Another part of the problem is Morisawa changed the font spacing data in their CID fonts without really telling anybody about it. Designers and production line operators opened documents and discovered they had to redo everything. The resulting publishing industry uproar forced Adobe and Morisawa to pull the CID upgrade and release an update for the update called ‘New CID’ that incorporated both new and old metrics for compatibility.

Things eventually settled down but the CID upgrade disaster left customers feeling wary about yet another upgrade, this time to OpenType. The uncertainty was palpable when I interviewed font designer Osamu Torinoumi of Jiyukobo for the Hiragino profile piece in mid 2002. The beautiful Yumin font had just been released:

JB: You have a new font, don’t you?

Torinoumi: Yes, the Yumin font. We’re releasing it as an OpenType font. But it doesn’t have the OpenType Pro glyph set. We will add other glyph sets gradually as an upgrade. Adobe Japan 1-4 doesn’t have all of the Japanese Industrial Standard (JIS) X0213 glyphs. JIS X0213 has all the possible characters used in Japan so that is a standard that will probably be used as we go along. Apple’s APGS (Apple Publishing Glyph Set) has all of X0213.

Our Yumin is ¥100,000 for a single license, and that is just for the first year. The second year, it costs ¥70,000. We also have volume licenses. We have to have a business model so we can keep adding more features (glyph sets, etc.). I think Morisawa must be having a tough time with OpenType…We really don’t know how it’s going to pan out.

The OpenType business model
Torinoumi’s comments succinctly outline the challenges facing font vendors at the time. Japanese OpenType wasn’t just a font upgrade for end users, it was a whole new business model for Japanese font vendors.

Adobe’s OpenType Japan announcement at Seybold Seminars Tokyo 1999 was the first official sign that the Japanese DTP industry had to migrate away from the PostScript printer font business model Adobe created 10 years previously. OpenType Japanese fonts downloaded dynamically and did away with printer fonts, they were no longer necessary, Japanese fonts finally worked like Western fonts.

All well and good, but there was the catch: Japanese fonts are expensive to produce, and the market was relatively smaller than the western one. How would a font maker create revenue to pay for all the work involved in making large glyph sets?

Jiyukobo’s Yumin font was the first new OpenType Japanese business model concept. Instead of selling a software package, they sold an annual subscription. In exchange, users got free tech support and upgrades like Adobe Japan 1-4 extended glyph sets, advanced layout and any other features that came along later. In a way it was a return to the traditional business model with printers paying monthly royalty font fees for use on proprietary typesetters…without the typesetter.

It took a long time for the industry to realign. Fontworks Japan launched their LETS program in 2001, which stands for Leading Edge Type Solution. While users could still buy a packaged font for ¥18,000, a single LETS license covering use of the entire FontWorks library cost ¥36,000 a year per client in addition to a one-time LETS “membership” charge of ¥30,000.

Japan’s first and largest PostScript font vendor, Morisawa launched their first OpenType products as OpenType Pro at ¥26,000 per font in 2002. No OpenType Standard, no upgrades for CID or OCF users, take it or leave it. At the time I asked Morisawa product manager Nobuaki Nakamura for a comment and he practically sputtered, “That’s right, no upgrades; and we’re not going to follow anything Apple does because it’s non-standard. Print it.” The remark shows how angry Morisawa was at Apple for bundling the Hiragino font and creating the Apple Publishing Glyph Set. Morisawa eventually came out with a LETS-like subscription service called Morisawa Passport in 2005.

APGS Shock
The Apple Publishing Glyph Set (APGS) was a MacOS Japanese character set initiative, separate from but simultaneous with the bundling of Hiragino. APGS created a stir because it added another set of glyphs above and beyond Adobe’s AJ 1-4 specification. At the time, Japanese font developers grumbled about yet another Apple-created spec that, like QuickDraw GX, would go nowhere. Yet it turned out to be a shrewd move.

APGS was based on the JIS X0213 standard (which was also released in 2000) with some additional glyphs from high-end Sha-Ken systems and the National Language Committee. Any JIS standard is the “final word” for Japanese character sets. By adopting JIS X0213 and releasing it as part of OS X, Apple created an instant “super-font” standard of 20,291 glyphs and upstaged Adobe Japan 1-4. Yasuo Kida was an Apple engineer who worked on APGS. He shared some recollections of the project.

Understanding Hiragino
When I visited Jiyu-kobo’s office for the first time, there was a drawing of the character 「あ」in mincho style on the wall. It drew my eyes and even to my untrained eyes it was obvious that there was nothing like that as a digital typeface. I suddenly realized everything.

I knew people complained that they did not have the digital typefaces that they wanted, but I did not really understand why they complained. Was it just nostalgia, or just an excuse for not changing the way they do their job? As soon as I looked at that character however, I realized that this is THE typeface they wanted but didn’t have.

I do not remember if it was Torinoumi san or (co-designer) Takada san who explained that it was a design called ‘A-Mincho’ and the A stands for “atarimae”. It was a typeface they were developing for printing literature. I fell in love with that typeface. The revelation was not related to Apple’s business decision or anything but it was the moment that I made up my mind. Apple licensed Hiragino, and later on the A-Mincho, or Yu-Mincho typfaces for iBooks.

The challenges
It was the late 90’s when fonts were added to my responsibilities. I saw a few challenges:

1) TrueType was not usable in DTP because of the limitation of the resolutionthe bundling TrueType in MacOS created problems for customers.

2) Lack of font varieties: Because you needed to have matching fonts on the printer’s hard disk to print your document, and because printer fonts prices were astronomical, the only reliable fonts that you could use at any service bureau were the few Morisawa fonts bundled with the output device.

3) Sha-Ken fonts were not available: many professionals complained that they can’t do their print job with DTP because Sha-Ken fonts were not available.

4) Lack of characters: professionals also complained that the Kanji glyph sets that they needed were not available in DTP PostScript fonts. These fell in two categories. One is ‘itaiji’ of Kanji that are either in or outside of the JIS X 0208 character specification. Another one is Kanji that are not in JIS X 0208. Interestingly we found many of the latter category were not in JIS X 0212 either.

At that time Mac OS was moving to Unicode. We needed therefore to define the base Japanese character set for the Unicode age. It was also the best timing to resolve the problem #4.

The APGS project was born in this environment. We did two things. One is to define the base character set which resulted in adopting JIS X 0213. The other is to define professional glyph set, APGS. APGS was done independently from choosing the fonts we bundled, however both projects went in parallel for the most part. Adopting APGS was a prerequisite for fonts we bundle.

The Solution
We decided to adopt JIS X 0213 as our new Japanese base character set replacing JIS X 0208 (the previous Mac Japanese encoding). JIS X 0213 was not final at that time but was taking form. We had some doubts if JIS X 0212 would fulfill people’s everyday needs, and we liked the approach that the JIS X 0213 team was taking. Being the base character set means we expanded our Kanji input method to take advantage of the JIS X 0213 character set.

For professional needs, we investigated every single character that phototypesetting systems had, e.g. up to Sha-Ken gaiji set C, and determined if the particular character should be included or left out. We wanted to say we have most if not all characters that are available in legacy systems including their gaiji plates that are not usually available.

In the process we learned that Adobe was also working on defining a new glyph set (AJ 1-4) with similar goals in mind. I wanted to merge the efforts but it did not work out. We could not just use Adobe’s effort as it seemed they were concentrating on itaiji of JIS X 0208, and were not working on adding Kanji that were completely missing. It meant we needed to continue with our own efforts.

At the same time, because the target was the DTP market, we needed to be upward compatible with whatever Adobe has. We made our glyph set upward compatible with theirs, expecting they will add ours to their glyph set later which is what happened.

At the start of the project we had decided to adopt Adobe’s format, i.e. CID, because TrueType was dead in the Japanese DTP market. I then changed the format to OpenType following the industry’s move. Hiragino became the first non-TrueType font bundled in Mac OS, Hiragino also ended up being the first Japanese OpenType font in the market, not our intention but it happened.

Because we did not adopt the Adobe Japan 1-4 glyph set, it forced Adobe to adopt APGS but things worked out nonetheless. Adobe’s development of InDesign J, capable of handing Unicode, and supporting authentic Japanese line layout, was a critical component in re-igniting the DTP market in Japan. Morisawa was upset at the time because Apple’s move changed the structure of the font market, but the market direction were already clear when Adobe announced OpenType J in 1998.

Results and some regrets
Hiragino being OpenType removed the need for printer fonts. Because APGS effectively had all characters found in the largest character sets on phototypesetting machines, it addressed complaints from professionals that there were not enough characters in DTP production.

The Hiragino font has Sha-Ken lineage and was welcomed by people who had complained about the lack of Sha-Ken typefaces. They all come free with macOS. Taken together with InDesign J they removed all excuses for not moving to DTP.

One of our concerns was that killing the printer font business, and increased development costs because of the extended character set would negatively impact the health of the font business. To survive the change we believed the font business needed to transition to the subscription business. And this is what happened. Fontworks started its LETS subscription, and Morisawa followed with Passport. It greatly widened the variety of fonts available for people to use. It was nice.

One small technical regret was that when we defined the properties of each glyph (e.g. fullwidth or proportional), we defined math symbols and some other symbols defined in JIS X 0213 as proportional as they should be in the internationalized system (which caused some turmoils in the Japanese OT world). At that time we decided leave Greek and Cyrillic fullwidth but if I were to decide now I would make them proportional.

Another regret was that we should have created a solid subset (or subsets) of APGS / AJ 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 AJ15 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.

In September 2002 the other shoe dropped when Adobe announced Adobe Japan 1-5 that incorporated APGS. A senior Apple engineer who had been part of every Apple OS internationalization project from Pink, to GX, to Taligent and finally MacOS X had this to say about the Apple • Adobe relationship: “If it wasn’t for GX, OpenType would never have happened.” I could not agree more and add that if it was not for GX and AAT tables, we wouldn’t have extended character sets and variable fonts the way we do now. Torinoumi thought that JIS X0213 (AJ 1-5) would become the standard of the high-end market. He was right.

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.


Developers and APGS enhanced Hiragino

I believe it is in everybody’s best interest, Adobe included, for Apple to continue innovating.

Isamu Iwata, Ergosoft marketing director 2002

Ergosoft was one of the very first Japanese Macintosh developers. In the 1980s, their egword text-editing application and egbridge input module were staples for every Japanese Mac user. The arrival of ATOK from JustSystem (for kanji input) and Microsoft Word put an end to Ergosoft’s market dominance in the mid-1990s. At the same time, a foray into cross-platform development turned out to be an expensive disappointment, and Ergosoft dropped Windows development in 1997. OS X gave Ergosoft a new opportunity, and the company took it by adopting Apple innovations that other developers ignored: ATSUI, the extended glyph set for Hiragino and the power of Apple’s AAT (Advanced Typography Tables).

In 2002 Ergosoft product manager Isamu Iwata sat down to discuss their products that used these technologies. It shows a Mac software industry in transition.

JB: One of the big features of egword 12 and egbridge 13 is the ability to use all of the Hiragino APGS extended glyph set. Was it difficult implementing these features?

Iwata: There was some engineering work using ATSUI, but making the decision to use ATSUI or not was a much more difficult decision. It was a little risky. Apple made lots of promises with QuickDraw GX, then completely dropped it. It took us two years to finally decide to support ATSUI. We did surveys of other developers to see if anybody was using ATSUI, but did- n’t find a single one. We were worried that if we were the only ones, it would disappear. I’m fairly certain we are the first developer to use ATSUI in a big way. Not even AppleWorks uses ATSUI.

We put a lot of effort into making a GX version of egword, but ended up throwing it away when Apple killed GX.

JB: Did you see any opportunities in using ATSUI?

Iwata: The deciding factor was the Hiragino fonts becoming part of Mac OS X. Even though Morisawa and the other font makers don’t have APGS [AJ 1-5] extended glyph sets, we still felt it was an opportunity, because it is part of the base system. The Hiragino fonts are high quality; they can satisfy the DTP market but also be of real value to other users as well.

JB: Does egword use any other ATSUI features besides the extended character sets?

Iwata: Not at this time. There was also a bug in ATSUI [prior to 10.2] that prevented us from accessing approximately 300 glyphs. We told Apple engineering when they visited here and they were very surprised. They promised to fix it in the next OS update. Such is the risk of being the only developer to use ATSUI and Hiragino.

JB: How do you maintain font-data compatibility with Adobe’s InDesign [which does not use ATSUI]?

Iwata: Hiragino has CID ID tags so the correct glyphs are imported [and displayed, printed, embedded in PDF documents, etc.] However, we cannot import some glyphs because they do not have CID tags. [Fixed in 10.2.]

JB: All of APGS does not have CID tags?

Iwata: Not all, only some…. egbridge can access all of the characters because of AAT and ATSUI, but applications like Excel and Word cannot accept them.

Ergosoft parent company Koei KK (now Koei Tecmo Holdings) shuttered the subsidiary in late 2007 and exited all Apple related business. The timing was unfortunate. After Apple released APGS in 2001 they did nothing to promote it or ATSUI. iPhone did not go on sale in Japan until 2008, the App Store economy had yet to materialize. If Koei KK had waited a few months things might have turned out very different.

Norihito Hirose and Kenta Arano, the very talented lead programmers of Ergosoft set up with own company Monokakido in early 2008 and created some of the first hit Japanese iPhone apps such as the Japanese dictionary Dajirin. They purchased the assets of egword and egbridge and resurrected them. They are still the best Japanese word processor and Japanese text input module on macOS.


Time Line

January 1994 QuickDraw GX launch
After being unveiled at MacWorld Tokyo 1989, QuickDraw GX launched in early 1994. Key font technologies include: extended character support, Apple Advanced Typography (AAT) tables, GX variable fonts, Open Font Architecture.

1995 CID PostScript Japanese Font Upgrade Disaster

August 1996 Apple cancels Copland OS

December 1996 NeXT Purchase (NEXTSTEP)

October 1998 ATSUI (Apple Type Services for Unicode Imaging)
Key GX text technologies brought forward for MacOS 8 and MacOS X: extended character sets, Apple Advanced Typography (AAT) tables, GX variable fonts.

November 1999 Adobe Japan 1-4
Adobe announces the first ‘Pro’ extended character collection specification and OpenType Japanese fonts with 15,444 glyphs at Seybold Seminars Tokyo.

February 2000 MacWorld Tokyo ‘Hiragino Shock’
Steve Jobs announces high end Hiragino fonts will be bundled with Mac OS X

March 2001 MacOS X 10.0 Hiragino
MacOS X 10.0 ships with Hiragino, the very first OpenType Japanese font.

September 2001 MacOS X 10.1 Apple Publishing Glyph Set
Apple Publishing Glyph Set enhanced Hiragino with 20,291 glyphs ships in OS X 10.1.

September 2002 Adobe Japan 1-5
Adobe announces a new OpenType Japanese font extended character set with 20,317 glyphs that incorporate the APGS extended character set.


Looking back
Hiragino Shock and Apple Publishing Glyph Set marked the end of an era of bold new typography developments in the Japanese market. Adobe went on to create other Japanese glyph collections but their ability to rally the industry around them diminished over time. The last time that Adobe and Apple cooperated was the OpenType Variable Font specification in 2016 which incorporated the Apple TrueType GX model and AAT tables, though these have yet to see any major release in the Japanese market.

It’s a shame the QuickDraw GX vision of international savvy, insanely great typography and layout as standard universal features all developers implement easily in high-level OS frameworks and standard app feature sets never survived. In today’s modern OS landscape I find it depressing that OpenType advanced typography features only live in full glory in Adobe Creative Suite apps. Although it is almost forgotten history, Apple’s font efforts for OS X raised the bar for standard OS typography features in Japan and moved the industry forward, for that users can be grateful.

Thanks to Yasuo Kida for sharing details behind the Apple Publishing Glyph Set initiative.


Related posts:

Inside Hiragino: A Closeup of Apple’s OS X Japanese Font

Stroke fonts forever

The Second Wave of Japanese Desktop Publishing

Requiem for Sha-Ken

A Japanese font design legacy restored: Morisawa and Sha-Ken agree to co-develop the Sha-Ken font library for OpenType

Will mobile ticketing go mainstream with new JR East Eki-Net?

Waku-waku for the new Eki-Net? JR East wants to make travel ‘waku-waku’ fun and romantic again like the Showa ‘Full Moon’ campaign era when JR Group ticketing was unified.

One unfortunate legacy of the Japanese National Railways (JNR) breakup and privatization in the late 1980’s was a fragmented ticketing system. The JNR paper ticket system worked very well. I was always impressed how you could go to any JNR Green Window ticket office and the all knowing agent would give expect advice and deftly punch up tickets to anywhere, in any configuration, even covering private rail.

The JR Group model fell apart in the internet era with online ticketing services, Suica and compatible Transit IC cards limited to separate JR Group regions. JR Group ticketing for paper, but not for mobile. What got broken doesn’t get put back together easily though it desperately needs to.

Last weekend the 20 year old JR East Eki-Net online ticket reservation system got the ‘renewal’ overhaul advertised back in March, that aims to reintegrate JR Group tickets into one slick consistent UI instead of a swamp of sub-menus. It also repositions Eki-Net from a limited ‘nice but I’ll stick with paper’ online purchase option to a standard way that JR East wants people to buy train tickets.

While eTickets have been in place since March 2020, Eki-Net 2 is the first serious step towards eliminating legacy mag-strip paper tickets and drastically reduce the number station ticket offices in favor of online mobile ticketing. The first stop for all JR East ticketing is now Eki-Net instead of lining up at a station ticket window.

There are 2 Eki-Net flavors: (1) the full comprehensive Eki-Net Web version optimized for desktop and smartphones offering mobile tickets, paper tickets, car rentals and tour packages like the classic 2nd honeymoon ‘Full Moon’ campaign for retiree couples, (2) Eki-Net App that only offers JR East eTicket and Ticketless mobile options.

What exactly is mobile ticketing?
To understand the aim of Eki-Net it’s important to know the basic ticketing categories:

  • Suica (Transit IC cards) pays the distance based fare using the Stored Fare (SF),
  • eTickets are cloud account Shinkansen ticket bundles that include the end to end distance fare plus the express • seat reservation charge, they are attached to the Suica or Transit IC card via the card number but do not use SF
  • Ticketless is a mixed mode that combines a cloud account express • seat reservation for regular express train seating used in combination with Suica SF
  • Touch and Go is a ticketless Shinkansen option that uses Suica and Transit IC cards for non-reserved seat Shinkansen travel in a pre-determined area, basically the whole JR East network

What’s new in Eki-Net 2?
Suica plays a central role in Eki-Net mobile ticketing. 2021 is also the 20th anniversary of Suica which has evolved beyond its commuter pass origins to encompass eMoney payments, mobile devices, Transit IC mutual compatibility and more.

In recent years Suica has gained another role as an all purpose mobile transit card hosting Shinkansen eTicket from JR East and SmartEX from JR Central. The challenge facing JR East is migrating the vast array of special ticketing and discount fares schemes from paper to mobile. Let’s take a look at the new banner features advertised for Eki-Net 2 and examine how JR East is doing this.

JRE POINT Integration
The integration of JRE POINT is the biggest new feature and illustrates JR East’s intention. The old Eki-Net point system was scrapped, good thing, there is finally point synergy and compatibility between Suica and Eki-Net. If you have any doubts that JR East is serious about mobile ticketing, take a look at the JRE POINT reward schedule:

Earning JRE POINT in Eki-Net, the VIEW PLUS Gold vs Regular 5% difference is obscene

Online paper ticket purchases give you basically zero points if you buy them with anything other than a JR East VIEW credit card, called ‘VIEW PLUS’ service which adds 3% or 8% more JRE POINT per ticket purchase amount depending on the VIEW card for a total of 5% (Regular VIEW) or 10% (Gold VIEW). JRE POINT can also be used for purchasing mobile only eTicket and Ticketless, and upgrading to Green Car and Gran Class seats. The upgrade exchange rate depends on distance and the train type, the new UI shows users all possible JRE POINT seat upgrades during seat selection.

Using JRE POINT in Eki-Net

Improved UI for web and app
Basically the new design dumps the old way of selecting the JR line or train and streamlines everything into a single station point and date entry screen. Seat selection is the advertised UI improvement and it shows: it is much improved on the web side, discount ticket comparisons are easy to see as are JRE POINT seat upgrades.

QR Codes support for group ticket pickup
A nice paper ticket option so that one person can purchase all tickets and send a QR Code for group members to pick up their tickets at the nearest station kiosk. It’s more convenient and replaces the old insert credit card and enter PIN code method for paper ticket pickup.

Eki-Net ticket discounts
Paper tickets have traditionally been the cheaper option. JR East must offer good discount incentives to drive mobile ticketing uptake. Fortunately the new Eki-Net ‘Tokuda-ne’ discounts offer anywhere from 5% off for same day tickets to 50% off for 20 day advance tickets. Discounts combined with JRE POINT are good but we’ll only find out if they drive mobile ticket uptake when regular train travel returns. While these options have closed the discount gap between mobile and paper somewhat, the majority of discount ticketing is still paper only.

JR-EAST Train Reservation
The international flavor of Eki-Net is called JR-EAST Train Reservation. It’s a completely separate web only multi-lingual service that offers regional passes for inbound tourists that can be purchased online before coming to Japan, or at a passport reading station kiosk. JR-EAST Train Reservation passes are different from the paper only Japan Rail Pass in that a growing number of them can be attached to Suica. New features here include: (1) Expanded multi-language support (2) pass purchases after coming to Japan (3) using Suica to attach eTickets. For the later there is a new user guide and How to register your IC card section. You can use Apple Pay Suica • PASMO by registering the card number, get the number using Suica App or PASMO App.

Weak points and summary
The Eki-Net renewal is big, complex and getting mixed reviews from Japanese users. Some love it, others hate it calling it, ‘an improvement for the worse’. The biggest gripe for many is that only up to 4 Express Train • Shinkansen sections are supported for one trip purchase. If you are traveling from Kagoshima to Aomori, forget Eki-Net and go straight to your local station ticket office for paper tickets.

The iOS Eki-Net App remains a nice idea that needs work. It feels like a thin re-skinned version of the mobile web one without offering any obvious benefit, the Face ID•Touch ID login option still useless as you have to manually login once every 24 hours and complete a picture puzzle. And there is no Apple Pay in-app support.

My biggest gripe is the failure of the JR Group to get their mobile ticketing act together. Sure, we have JR Central EX and JR East eTickets, but these are locked in their respective service regions. This is 2021, JR Group ticketing should be cross compatible, streamlined and mobile ready. It doesn’t matter how great JR East makes Eki-Net, users can travel with just Suica on the Tokaido and Tohoku Shinkansen, but they have to buy 2 tickets using 2 different accounts and billing with 2 different ticketing systems. We should be able to travel anywhere on JR Group lines using one account to buy mobile tickets. In todays scenario this isn’t possible. The unfortunate legacy of the JNR breakup lives on.

‘New Eki-Net’ poster at the local JR East station. The overall impression of Eki-Net 2 is that less about going mobile and more about getting customers out of the ticket office to a station kiosk machine instead.

Reference posts
JRE POINT Beginners Guide
Suica App • PASMO App Guide
Apple Pay Suica Shinkansen

iOS 15 Apple Maps JP quick preview

There are a number of Apple Maps improvements in iOS 15 but the features you get depend on the region and the device. Only A12 Bionic devices and later display the full glory of iOS 15 Apple Maps new cartography. Only San Francisco and a select few cities will have the full range of new cartography features at iOS 15 launch. A quick overview.

New Views
iOS 15 Apple Maps has a new general use Explore view in addition to the previous views: Driving that highlights roads and traffic, Transit that highlights transit routes, and Satellite. Explore is where most of the new cartography really shines but there will be a lot of view switching. You would think that after all these years of clumsy view toggling there would be tap and hold toggle view shortcut for fast easy access, but there isn’t.

Justin O’Beirne’s iOS 15 Apple Maps screenshot page helpfully lists the new cartography features and divides them by region into different detail zones: 3-least, 2-some, 1-most. His zone 2 is a vague middle category that includes the United States, Canada, United Kingdom, Ireland, Spain, Portugal and Japan though the last one doesn’t really belong. All zone 2 counties but one have Apple mapped cartography, Japan does not. Apple Maps image collection in Japan is considerably smaller compared to other zone 2 countries and the data is only used for Look Around, not for improving Japanese cartography details. Because of this Japan belongs somewhere in-between zone 2 and 3 as ‘Areas of Interest’ and some other details are either missing or spotty.

Justin O’Beirne categorizes the new Apple Maps cartography details into zones

The big iOS 15 Apple Maps feature, by far, is the improved cartography. The contrast is better, the Point of Interest (POI) clutter has been minimized, city maps differentiate business and residential areas by color. I think the biggest improvement is Dark Mode maps. It simply blows the old Dark Mode maps away and is, dare I say, almost better than light mode.

The new design does a great overall job of clearing up the ‘death by POI’ clutter. Japanese POI text labels remain a problem. All Kanji writing cultures have an innate ability to efficiently abbreviate long names, the genius of Kanji culture. Unfortunately Apple Maps doesn’t make use of it and clutters up precious screen real estate with unnecessarily long unabbreviated text labels. Japanese typography color Kanji use is still a problem as well especially in light mode with color text over similar color background. The low contrast is hard to read.

Beneath the new skin old problems remain. 3rd rate Japanese map data supplier IPC is still there, warts and all, actually it’s nothing but warts. And there is new twist: IPC was 100% owned by Pioneer but was sold to Polaris Capital Group effective June 1 with a new CEO (ex Oracle Japan) named the same day. For some reason IPC doesn’t reveal this on their corporate website. The IPC problem can only be fixed by (1) dumping them for Zenrin, or (2) Apple mapping all of Japan themselves. Apple doesn’t seem to be pursuing either option, expect more of the same old map problems in iOS 15.

Last but not least we now know why the Sea of Japan doesn’t exist in Apple Maps: all place names are tappable in iOS 15. Apple doesn’t want people tapping Sea of Japan and are playing a geo-political game here that Google does not. Google Maps simply use language/country naming conventions for the corresponding region setting. Apple’s memory hole stunt here is a disgraceful one they wouldn’t dare pull in any other market.

Transit Improvements
iOS 15 Apple Maps also has a few new transit tweaks. The biggest ones are disembark notifications and nearby transit.

Unfortunately not all transit improvements are the upgrade I was hoping for:

  • Static Transit on route directions: unlike dynamic on route driving and walking, once transit routes are set and engaged they do not update transit times or routes according to changing time and location conditions. Transit would be much more useful if estimated transfer and arrival times updated dynamically. Another gripe: walk to/from station routes in transit don’t employ the same information system used in regular non-transit walk routes. Transit walk routes are static and sometimes use longer routes.
  • Disembark notifications are short ‘in app’ notifications that are not very noticeable and easy to miss. Disembark notifications display and sound as the train pulls out of the previous station before the disembark point. Because on route transit uses GPS, it is not very accurate. It works well enough on surface transit but based on my testing disembark notifications are unreliable when: (1) riding the subway, (2) you are using another app in the foreground with Apple Maps app in the background. The old reliable stand alone Yahoo Japan Transit app has much more robust disembark notifications.
  • Train car exits positions are now showing on some transit route directions, unfortunately real time transit and crowdedness information are still missing despite being standard in Google Maps and Yahoo Japan maps for some time now.
  • Nearby Transit is my favorite new feature. It’s simple, clear and fast location based transit info at your fingertips. Very handy.

A short list of missing features in Japan includes indoor station maps, immersive walking instructions and new driving features. I think we can be sure these won’t make the iOS 15 cycle. There is a lot to like in iOS 15 Apple Maps, unfortunately the feature reality for users in Japan will only be the new cartography.