This is not a WWDC23 prediction, but at some point Apple will certainly unveil a variable San Francisco CJK (Chinese-Japanese-Korean) system font to match the rest of the Apple SF font family, and it will be unveiled at WWDC. I’m not a fan of the CJK name and the mental baggage that comes with it because it’s one of those western concoctions that deal with pesky Asian cultural differences by sweeping those differences under the rug of indifference. Like using a leaf blower to blow and hide dirt everywhere instead of removing the dirt by neatly sweeping the mess into a bag. It’s all Chinese right?
Wrong. Chinese is merely the start point for centuries of cultural evolutions and written language aesthetics that are distinctly different for each language. There are Kanji created in Japan that have migrated the other way. Cultural flow is never one way. CJK is a kind of snub intended to keep the cultural flow one way by neatly collapsing important differences as ‘CJK styles’ for the convenience of westerners who can’t be bothered to understand what those differences are. Just as western based baseline font technology can’t reproduce high quality vertical kanji layout, all in one CJK designs can’t reproduce high quality typography across languages. One hopes Apple is spending the money and time to get those differences right for each language group, C+J+K if you will, because it’s not easy.
What will a SF C+J+K design instead of an all in one CJK design look like? Hiragino Sans GB is a good font to examine as it represents an early Apple lead effort to create a mixed Japanese and Chinese design, best described as a “Simplified Chinese version of the Hiragino typeface…designed to make Simplified Chinese characters look good in Japanese texts, and vice versa.” When I talked with one of the key Hiragino designers, Osamu Torinoumi, in 2009 about the Hiragino Sans GB bundled in Snow Leopard, he explained that one design does not fit all.
The modifications for Simplified Chinese characters in Hiragino Sans GB from the original Hiragino character designs are circled in red
We (JIYUKOBO and Screen) visited Beijing Hanyi Keyin Information Technology Co. in December 2007. The top designer is a young woman, Ms. Zhong. We couldn’t talk to each other because of the language barrier and didn’t know if we had the same design sensibility so she started pulling out the hand drawn templates for one of their designs and we went through them one by one. I would point out the design problems and she would nod her head in agreement and after a while I realized we both thought alike.” JIYUKOBO sent all the original Hiragino design data to Hanyi Keyin through Screen and they adapted the designs for China.
“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.”
“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 Japanese and Chinese “Kokoro” glyphs which the Chinese designers insisted were different.”
If one of the top font designers in Japan cannot understand the differences between Japanese and Chinese “Kokoro” glyph designs, I doubt Apple designers will be able to figure it out on their own. I hope for the best but all too often ‘all in one’ CJK font designs sweep those kinds of important differences under the rug.
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.
One of my favorite work tasks is bringing classic Nichiren Shu Japanese texts into the digital age so they can be translated easily or republished using the latest print technologies for paper and ebooks. Before a title goes into production there are essential steps of obtaining the basic text in digital format, if any exists, and exploring archives for definitive published Showa era sources to double check digital text integrity. Exploration is spelunking into the past to find people connected with the original production process, however remotely, and tease out helpful details: are there any production materials, was it all analog, is there any digital content to work with, and so on.
When helping to bring Senchu Murano’s wonderful Lotus Sutra English language translation back to life, I was heart broken to learn that after months of searching, the original production materials had been destroyed when the printer closed the business only a year earlier. Fortunately there was already a team working on recreating all the English text (over 120,000 words with lots of transliterated, diacritical heavy Pali vocabulary) in desktop computer word processing software. However, when the project finally entered into the primary layout stage I quickly discovered that Murano, or the kumihan typesetters of the 1974 1st edition, had used a number of non-standard Kanji characters in the glossary section, aka Gaiji.
The glossary from The Lotus Sutra 3rd edition
Fortunately I knew the designers of the Hiragino Japanese macOS system font and they introduced a former apprentice who did outside contract font design work. After a careful review he found 15 gaiji characters, unique regular kanji variations not included in the Hiragino Gothic Pro N extended character set and created them for Lotus Sutra 3rd edition.
The 15 Gaiji characters created for the Lotus Sutra 3rd edition.
One thing I learned from the gaiji creation process is that the line between a quirky Japanese kanji design of a regular character and a real gaiji can be very fine. It’s not always an easy black or white call. There is also the publishing history to consider, what was the original intention? Did latter editions swap out complex kanji with simplified versions due to the transition from analog production, and because the early electronic layout production systems were so limited? These are all important points to consider when porting classic Japanese texts to modern production system software.
I was reminded of this with a new project recreating a 31 day chant book of Nichiren Shonin’s Minobu Letters. Fortunately Okazawa san was available to do another fine comb review of our materials.
We found that the original Showa text kanji, which is considered the definitive source, had been changed in the Heisei version. Upon further investigation I discovered the Heisei text had been reproduced on a proprietary Panasonic electronic typesetting device that had limited character sets, and was obsolete. The Panasonic device Japanese fonts used i the book were also somewhat quirky. They looked different enough to consider them gaiji-like, but in the end after comparing everything to Showa printed books, we realized they were just quirky simplified designs of the Panasonic device. Not the original intention.
The happy end here is that the default macOS Hiragino Gothic Pro N extended character set has all our production needs covered. And it’s a great design that travels very well.
I have not used Adobe Illustrator much the past few years and certainly don’t use it enough to justify buying a Creative Suite subscription that only lasts 12 months. Recently a localization project came in where I needed to edit the original Illustrator file data text. The printer sent me their Illustrator print files and I blithely opened the file with a name that ended with ‘OL’.
As soon as I clicked the body text I realized what OL meant: outline. All the text in a 2 page document with lots of text had been converted to outlines via the Illustrator convert text to outline feature. I couldn’t edit anything. I contacted the printer and received a backup file with the text intact that had not been converted to outlines.
Japanese service bureaus and printers require all Illustrator file text be converted to outlines (left image), they usually will not accept regular text data (right image)
I reflected on this basic Japanese designer practice of converting all Illustrator file text to outlines before sending work files to the printer. It took me back to my days setting up some of the first Japanese PostScript DTP production lines for print companies in Shizuoka. Any printer or high end print service like Lithmatic (a great service company by the way) always requests designers to submit Illustrator work files with all the text data pre-converted to outlines. I hate doing this because it strips away all the font hinting. Font hinting is now only thought of as a screen display thing, but printer font hinting was necessary back in the days of 300~600 DPI PostScript laser printers.
Maybe printer font hinting is no longer necessary in this era of high resolution CTP (computer to plate) on-demand small print runs. Even so, to my eye, stripping out the font hinting reduces the Japanese typographic quality of smaller printed kanji text with their complex glyph strokes. Why is it necessary in this age of PDF workflows to even bother converting text to outline anymore?
It all goes back to the many original sins of the first Adobe Japanese PostScript fonts, the biggest sin being they could not be downloaded to the printer on a job basis…they had to reside on the printer. And they were not cheap: ¥300,000 a pop (back in 1990 when that kind of price was a lot heavier on the wallet) for a single unlimited resolution Japanese PostScript printer font. Not only that, early Japanese PostScript print drivers sucked. They were slow and print jobs would often trip up the RIP job with a memory error or something arcane. Like it or not, print job managers learned to read voodoo tea leave PostScrip error codes to decipher problems, fix the Illustrator file and run the job again. Late work nights were common for production staff.
Usually it was just easier to convert text to outlines which was the godsend feature that arrived with Illustrator v5 along with Japanese Adobe ATM. Instead of buying expensive printer fonts and dealing with incomprehensible PostScript output errors, it was easier (and cheaper) for print service bureaus to require all Illustrator file text data be converted to outlines. This was a time when Illustrator was the workhorse choice for DTP designers in Japan.
All of the PostScript problems were eventually fixed with OpenType fonts and PDF workflows, PostScript fonts themselves will officially die on January 2023. But the PostScript font damage done in Japan will never be fixed. There’s just too much legacy data out there, both in data files, and printer fonts still installed on high end output devices. And Morisawa will always provide legacy OCF fonts for their Passport customers that need them, no matter what Adobe says.
PostScript fonts may be going away, but the ghosts of PostScript fonts, the fine art of outlining Illustrator text data, will be haunting Japan for a very long time.
Hello! I am doing a transportation design website + a map about trains. I am looking for a Japanese-latin typeface.
Can you please recommend something, preferably free, but I am open to buy too.
ありがとう🙇♂️
This is a very good, and not so easy question to answer these days. It much easier to answer in the pre-smartphone desktop era where there were more limitations and far fewer choices: just work with the default installed Japanese fonts. All Japanese fonts come with built-in latin characters that might not be what you are looking for, but are designed to work well in mixed Japanese/Roman typography situations.
That’s still basically true today but web designers have to deal with the split between Apple, Google and Microsoft platforms, and the different Japanese fonts they bundle. There are many choices for Japanese web fonts and such but working intelligently with default installed Japanese fonts is always an excellent, and practical, strategy.
As a rule of thumb, Japanese fonts are much more adept dealing with mixed encoding/character pages than letting the designer designate different Japanese and Roman based fonts for each language. Only go that route if the designer is very experienced using Japanese fonts on the web in mixed language pages and extensively test Japanese font choices on different computer platform web pages.
In the pre-iPhone internet era the Japanese + Roman choices were basically: Hiragino on OS X and the Ricoh designed MS Ryumin/MS Gothic on Windows XP. The very nice Meiryo came along with Windows Vista, and Microsoft Word for MacOS, but the ubiquity of the XP installed base kept Meiryo sidelined. Then iPhone and later Android came along changing everything.
iOS, iPadOS and macOS all have the same basic set of Hiragino fonts but there are some differences to be aware of. The Japanese system font is Hiragino Sans ProN (Hiragino Gothic in Japanese) but the Roman characters are SF Pro. If a web designer wants to use the ‘native’ Roman characters of Hiragino Sans ProN, they need to designate the Hiragino font name, not the system font. Hiragino Sans is always a good overall choice for the iOS/macOS side if the designer isn’t familiar with Japanese fonts. It’s ubiquitous, reliable and works well in any situation.
The Android side is more complicated. The default Japanese system font was Motoya (MotoyaLMaru W3) which was replaced with Noto Sans CJK in Android 6. This upset a lot of Japanese web designers because Noto Sans CJK is a lousy font design, especially the hiragana and katakana designs. Most CJK ‘all in one’ fonts are shit, especially hiragana/katakana. If you want quality, choose a font that is optimized for each region…not easy to do with Android. The current Android system font is Roboto for Roman and Noto Sans CJK for Japanese. OpenType Variable Fonts were supposed to solve the CJK limitations of OpenType, but it hasn’t panned out so far. There are better solutions out there but…we are where we are. And no, CSS is no magic bullet solution either.
Here are some handy Japanese font resources to help web designers make good choices:
Also this Japanese web typography primer: Seven rules for perfect Japanese typography, might be useful if you don’t know anything about Japanese. Be very careful however as it is old (2016), is far from being perfect advice, and does not have any of the latest CSS typography and JP web font tricks.
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.
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
A virtual body Kanji with approximate baseline overlay red line.
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.
You must be logged in to post a comment.