Category: Mobile and Web

Mobile and web tech related news and posts

Apple’s Once and Future Japanese Variable System Font

2020 is the coming out party for Apple designed OpenType variable fonts, both the SF Pro and SF Compact system fonts and the all-new New York font shipping in iOS 14, watchOS 7 and macOS 11. The Apple created variable font technology is not new of course. It has been around since the QuickDraw GX days along with the TrueType GX enhanced Skia font. It was due to be standard in MacOS Copland system fonts including a Japanese variable font created by FontWorks. Then Steve Jobs returned to Apple and everything changed.

Yes, it has taken 25 years for an Apple created technology to make it into the basic system. It proves my long stated belief that font technology doesn’t matter unless it is a standard feature built into every nook and cranny of the OS foundation. The TrueType GX Skia variable font has been with us all this time, but only matters now because the SF Pro system font has gone variable.

Why is It Taking So Long?
iOS 14 and macOS 11 variable font basics are covered in an excellent WWDC20 video, ‘The Details of UI Typography’. It’s important to remember that while OpenType variable font technology is ‘world ready’, at this stage they only apply to Roman based font sets. It’s going to be a long time before we see a Japanese language system font in variable format.

There are many reasons. In the WWDC20 video Loïc Sander of the Apple design team drops a big hint when he explains that while digital technology (PostScript fonts) “gave us a lot more flexibility in handling text,” it also “made typography a bit more crude than it used to be.” The statement shows how clueless designers and engineers outside of Japan can be about Japanese fonts and typography.

While a ‘bit more crude’ might be true for Roman based fonts and text layout, PostScript fonts completely broke traditional Japanese font design and composition models. Everything was thrown out because Adobe made no accommodation for Japanese Kanji based font metrics. Western created DTP layout is graphics-driven and calculated by margins and font baselines.

The western baseline typography model and font metrics is how PostScript and OpenType fonts, and all layout engines evolved. Adobe was well acquainted with the shortcomings of their own font technology and InDesign J got around the problems by adding proprietary Kanji virtual body font metrics and Japanese line break algorithms. None of this exists as an open standard that benefits everybody.

Because of this situation Japanese DTP forced users to adapt to limited font technology rather than technology solving their production problems. I know this because everyday at work I had to deal with the endless problems and limitations of Japanese PostScript fonts that could only reside on the output device.

Another big problem was that Adobe relations with Japanese PostScript licensees in the 1990’s was not healthy. Adobe stuck with closed print device font licensing for far too long and discouraged independent font production wherever they could. Because of this situation, digital font progress in Japan was slow and very expensive.

Here are some challenges facing Japanese variable fonts.

Once Upon a Time
One basic flaw of OpenType outline font technology is that it’s extremely inefficient for kanji glyph production and storage. Every glyph has to be created and stored separately and doesn’t scale well. This is why OpenType CJK fonts on tiny devices like Apple Watch are a match made in hell. One solution to this problem is stroke fonts. Stroke fonts use a library of basic glyph parts to efficiently create complex glyphs.

Stroke fonts are a perfect fit for kanji font production and for small constrained devices like Apple Watch because reusable parts don’t take up precious resources. On the desktop, stroke fonts can do weight variations over the full range from Light through Ultra Bold without losing typographic details, all in a single 4 MB font while an equivalent OpenType variable font can weigh in around 18 MB.

The technology has been around for a long time and was supported up until macOS 9 but lost out when Apple quietly dropped the QuickDraw GX derived Open Font Scaler architecture in the migration from classic to macOS X.

While stroke fonts are not supported in the current Apple OS lineup, on the font tool side stroke font technology has appeared in software such as the classic MacOS Gaiji Master from FontWorks. The lead engineer of that effort is currently working independently on a similar gaiji glyph tool for Windows based on stroke font technology that is much more advanced than the old and long unavailable FontWorks software. I plan to cover developments in a future post.

The Japanese Font Production Challenge
The Hiragino iOS/macOS Japanese system font was not created by Apple, it was licensed from Screen Holdings (SH), originally created by independent font design studio Jiyukobo in the early 1990’s. There is much more work involved creating a Japanese font compared to Roman based languages. Hand drawn glyphs are created, scanned and cleaned up for digital production.

The Adobe Japan 1-7 glyph collection requires 23,060 glyphs for a single weight, multiply this work by the different weights for one family and you get an idea how massive the undertaking is. From Osamu Torinoumi, one of the key designers of the Apple licensed Hiragino font on its creation:

On average, one person would (hand) draw 12 or 13 glyphs a day, which is not much change of pace from the days of creating block type…the whole process, from start to finish, took three years.

One might think that a single CJK (Chinese-Japanese-Korean) font sharing a common design can streamline the process but this is a huge misconception. Each culture has centuries worth of different design aesthetics that good design must incorporate: what looks good to a Chinese designer and works well in a Chinese text design, looks terrible in Japanese context. I have yet to see a decent digital ‘kana’ design from a Chinese font designer. Osamu Torinoumi on the differences in creating the Simplified Chinese Hiragino Sans GB:

“We worked with the Adobe GB 1-4 character set (29,064 glyphs) at 2 weights. Basically we had to finish one weight in 6 months. One year for the entire project. At first we only thought we would be there as backup, but Screen kept passing us all the questions from Beijing. It turned out to be a lot more work than we anticipated.”

Jiyukobo sent all the original Hiragino design data to Hanyi Keyin through Screen and they adapted the designs for China. Torinoumi said that one of the major differences is that Chinese design demands that Gothic (sans serif) characters mimic handwritten style. This means the character should be slightly off center within the virtual body. “Even after the project was over I still didn’t understand the difference between Japan and Chinese “Kokoro” glyph which the Chinese designers insisted were different.”

The Variable font UI Challenge
Finally we get to a problem on the Apple OS platform side that has been around since the GX days: how to present advanced typography features in a useful and easy to understand system UI that works everywhere. What works on macOS obviously won’t work on iOS, but iPad OS will need some degree of advanced typography feature access. Sliders have their place but I agree with Adobe Type Senior Manager Dan Rhatigan who made a very good point in his TYPO Talk 2016 presentation: there has to be a better UI control concept out there.

fvar
Dear Apple, didn’t Adobe tell us not to use sliders?

This is because there are many more OpenType Japanese variable font features than just weights. There are gylph variations, vertical layout variations, horizontal and vertical compression for tatechuyoko instances. In macOS Catalina these are hidden away in the crusty old Font Pallet that is desperately in need of a major overhaul. Please tell me that macOS 11 fixes this or that Apple has a vision how to.

Oh where can my glyph variations be?

Japanese typography is unique in that it has preserved its own print ‘moji bunka’ cultural history and vision that China and Korea have largely abandoned in the face of western centric computer culture that often pretends to care about such things, when it really doesn’t. If western developers cared about good typography for everybody we would have vertical text in web browsers that actually works. I hope a rich text culture can be preserved and conveyed to future generations even in such small details as a well designed and executed Japanese variable font for computers and smart-devices.

Japanese Typography and Font Posts

This is a collection of long form Japanese typography posts. They were written as stand alone pieces, so there is some background explanation overlap, always a weak point of the blog format.

NTT Flet’s fails in the Covid traffic crunch

NTT FLET’S internet service has been around forever in many configurations, the latest being Flet’s Hikari ‘optical fiber’. I call it flexible fiber because NTT uses the term Hikari when they should not. My Hikari only comes into the apartment building junction box then branches into each apartment with good old cooper wire phone lines and a VDSL modem. NTT calls that Hikari, I don’t.

PPPoE/IPv4 traffic has been tapped out in Tokyo since at least 2017. When I first upgraded from PPPoE/IPv4 to IPoE/IPv6, I saw a pleasant bump in speed with none of the night time internet traffic meltdowns when using PPPoE.

  • Flet’s PPoE/IPv4
  • Flet’s IPoE/IPv6

I thought my problems were solved but over time IPoE/IPv6 download speed has slowed down while iPhone NTT Docomo 4G LTE speed has skyrocketed past NTT Flet’s:

  • NTT Docomo 4G LTE then
  • NTT Docomo 4G LTE now
  • NTT Flet’s now

A year ago Twitter user shao, who posts wonderful network and payment tech tweets with the deep tech background to back them up, noted that the Japanese Internet Provider Association was in a collective hissy fit with NTT. IPoE/IPv6 junction points to NTT main lines where tapping out and providers needed more junction points, they also wanted IPoE access pricing brought in line with PPPoE and better traffic control. NTT gave internet providers the cold shoulder with ‘we’ll consider it if you do the work.’ The result of that is NTT East/West Flet’s service is seriously slowing down in face of stay home telework, bored kids streaming content and too much online shopping.

As shao notes 4G and KDDI au Hikari nuro service are, so far, unaffected. The strange thing here is that KDDI is simply renting NTT dark fiber for nuro. So yes, NTT has the capacity, but doesn’t seem inclined to put in the effort to share it unless providers do the work, and also pay up. To be fair I think one of the problems is hinted at in a recent annual NTT financial report: a shortage of field engineers and technicians. Somehow it seems fitting that the human problem of Covid is also the human problem of slow internet speeds.

Japanese Text Layout for the Future* (hint: there isn’t one)

I finally had time to catch Adobe Nat McCully’s ATypl Tokyo 2019 presentation. He covers a topic I have covered many times before: the (sad) state of CJK typography. As Nat points out most software developers and system engineers talk about CJK support as typography without any idea of what it means. Throwing CJK glyphs on a screen is not typography, they are not the same thing at all.

The defining feature of CJK typography and layout in general and Japanese typography in particular is that space is an essential composition element equal with text and graphics, with fine space element control way beyond a baseline. Instead of thinking about how much space should be between text, flip it around and think about how much text should be between the space. Baseline font metrics will never deliver great CJK typography because there are too many limitations.

This is why InDesign J implements virtual body metrics based on Adobe proprietary table information for true high-end Japanese layout. There is no virtual body standard digital font metric standard so everybody implements the missing stuff on the fly and everybody does it different. Unfortunately the irony of it all is that Adobe played a huge role in how these limitations played out in the evolution of digital fonts, desktop publishing (DTP) and the situation we have today.

QuickDraw GX was the only time in computer history that fonts, layout engine and the basic OS came together to solve these limitations for all language systems and all language typography as equal from the bottom up. Parts of that effort survived, such as Apple’s SF variable system fonts based on the TrueType GX model, and the inclusion of the TrueType GX model as the base technology for OpenType Variable fonts.

Nice as this is, it’s only a tiny sliver of the GX vision pie. Many other baseline font metric and CJK typography limitations still exist. Outside of a handful of people like Nat at Adobe, and the Adobe CJK typography ghetto approach of keeping all the insanely great stuff corralled in the InDesign J text engine, little is being done to address them.

After 20 years of watching things slide sideways, I don’t see much hope for the future evolution of great CJK typography on digital devices. Most western software development people think that having CKJ glyphs on a screen is ‘good enough’ CJK typography, end of story.

Already I see the OpenType Variable Font effort devolving into a bauble for web developer geeks, always stuck in demo-hell, never going mainstream. It is the same story as the quality CJK typography on digital devices one. When the current Adobe CJK leaders like McCully and Ken Lunde, who passionately care about great CJK typography and devoted careers to fixing the problems, finally retire, I think it will be the end of an era. In many ways we are already there.

UPDATE
Ken Lunde posted a wonderful overview of his Adobe career, also his ATypl Tokyo 2019 presentation.

NTT Docomo rolls out 4G LTE Gigabit service

In case you missed it, try this if you are a Docomo iPhone customer: open the Docomo Speed Test app and tap the Area Map button. The previous red area has been replaced by yellow. The app needs to be updated but the red now indicates the areas with 1288Mbps~988Mbps Gigabit-class ‘Premium 4G‘ service, just in time for the iPhone 11 and iPhone 11 Pro release.

I am fortunate to live in a red 4G Gigabit speed area and my iPhone XS 4G speed is faster than my NTT East FLET’S HIKARI ‘mansion type’ VDSL service. It’s an older apartment building where telephone lines and VDSL are the only way to connect to the internet. That’s depressing to think about, but it will have to do until I can move to a place with direct fiber connection service. At least my iPhone XS 4G LTE is fast and will get faster if I upgrade to iPhone 11 Pro.

KDDI au is offering similar 4G LTE Gigabit-class carrier aggregation service for iPhone 11 customers. Be sure to check details and coverage with your carrier.

Bug Bounties, Public Betas and Risk Management

I love Paul Jorgensen’s blog and his unique take on cyber security issues. It is his chosen profession and he was one of the very few to notice and take interest in the August 2017 Google BGP leak that brought down Apple Pay Suica services and major parts of the Japanese internet. He was also one of the few to blog about China Telecom spoofing the BGP protocol to poison internet routes to suck up massive amounts of American and Canadian internet traffic for intelligence analysis.

In his post today Paul quotes Katie Moussouris on bug bounties and risk management. Specifically, relying on public bug bounty programs that just create the “appearance of diligence”:

“This is not appropriate risk management. This is not getting better when it comes to security vulnerability management..

A lot of the patterns [have] not actually shifted that much from where we were when I started out professionally 20 years ago as a penetration tester…

We’ve created a $170 billion industry, which, we’re really good at a few things, security not exactly being one of them. Marketing, definitely.”

As Paul points out, “bug bounties are a tool, but only one tool. And it’s a game, so people will look to take advantage.”

To draw a close analogy I would also say that the public beta approach that Apple now uses for iOS and macOS development is similar in that it just conjures the appearance of diligence, not diligence itself. It creates an atmosphere of reduced expectations, both on the engineering side and the user side: “it’s just a beta, we can still work out the bugs.” I wonder if we would be better off without a public beta, a better developer beta program with robust bug reporting tools might set a higher bar.

As others such as John Gruber have noted, iOS 13 has been one of the buggiest beta development cycles in recent memory. Perhaps I am being nostalgic, but I think when Steve Jobs still walked the halls in Cupertino, his drive to deliver an excellent shipping product, and fear of his wrath when things didn’t measure up, was due diligence that instilled the Apple development culture of that time.

People perceive quality even if they cannot put it into words, the old look and feel thing. As Moussouris points out, marketing is a poor substitute for diligence and quality. The risk of the current environment is that Apple ships software products that have lower expectations which no amount of marketing can make up for.