Posts in Category "Open Source"

Revisiting “LOCL Test”

Posted on October 15, 2018 by Dr. Ken Lunde | Comments (0)

Something extraordinary happened today.

This extraordinary event provided to me an opportunity to revisit the open source LOCL Test OpenType/CFF test font that I introduced over two years ago. I improved the language declarations in the 'locl' (Localized Forms) GSUB feature definition, and also made other minor tweaks, two of which can be seen in the image above.

The version of Adobe InDesign CC that was released today during Adobe MAX, Version 14.0, now supports language-tagging for a fifth East Asian language: Traditional Chinese for Hong Kong. This new language-tagging option appears as “Chinese: Hong Kong” in the Character Styles and Paragraph Styles panels, and as the same in the Character panel.

For those who were not aware, OpenType has supported language-tagging for Hong Kong, a flavor of Traditional Chinese, for over 10 years via the three-letter language tag ZHH, which was introduced in Version 1.5 (May 2008) of the OpenType Specification. ZHS is the language tag for Simplified Chinese, and ZHT is the one for Traditional Chinese, but for Taiwan. For Japanese and Korean, JAN and KOR are their language tags, respectively. I am very pleased that Adobe InDesign finally supports all five of these OpenType language tags.

The timing couldn’t have been better…

🐡

About Adobe-Japan1-7 Font Names

Posted on September 2, 2018 by Dr. Ken Lunde | Comments (0)

日本語 (Japanese) はこちら

The feedback that we received from the previous article on this subject has been extraordinarily valuable. Our proposal to leave the names of Adobe-Japan1-7 subset fonts unchanged met with virtually unanimous agreement, but given the relatively minor nature of the Adobe-Japan1-7 additions, to the tune of only two glyphs, the same naming policy seems to benefit Adobe-Japan1-6 fonts as well.

In other words, fonts that currently support Adobe-Japan1-6 in its entirety can be updated to Adobe-Japan1-7 without changing their names. Of course, the advertised Supplement value as recorded in the 'CFF ' table should reflect 7. The following is a revised version of the table from the previous article on this subject:

Supplement Designator JIS2004-Savvy Designator /CIDFontName & Menu Name Examples
3 Std StdN KozMinStd-Regular, 小塚明朝 Std R
KozMinStdN-Regular, 小塚明朝 StdN R
4 Pro ProN KozMinPro-Regular, 小塚明朝 Pro R
KozMinProN-Regular, 小塚明朝 ProN R
5 Pr5 Pr5N KozMinPr5-Regular, 小塚明朝 Pr5 R
KozMinPr5N-Regular, 小塚明朝 Pr5N R
6 Pr6 Pr6N KozMinPr6-Regular, 小塚明朝 Pr6 R
KozMinPr6N-Regular, 小塚明朝 Pr6N R
7 Pr6 Pr6N KozMinPr6-Regular, 小塚明朝 Pr6 R
KozMinPr6N-Regular, 小塚明朝 Pr6N R

Of course, we still welcome any and all feedback about this font-naming issue.

🐡

Adobe-Japan1-7 のフォント名について

Posted on September 2, 2018 by Dr. Ken Lunde | Comments (0)

English (英語) here

先のブログ記事について、既にいくつか貴重なフィードバックを受け取っている。Adobe-Japan1-7 のサブセットとなるフォントの名前を変えずにそのままにしておくという提案については、ほぼ大方の賛同を得ることができたが、Adobe-Japan1-7 での追加が二つのグリフだけに限定されるため、Adobe-Japan1-6 対応のフォントについても、名前を変えない方が良いという意見があった。

言い換えれば、現時点で Adobe-Japan1-6 に対応しているフォントは、名前を変更せずに Adobe-Japan1-7 にアップデートできるということだ。もちろん、CFF テーブルに記録されるべき Supplement の値は「7」に設定しておく必要がある。この考えに沿って、前回の記事の表を以下のように修正した。

Supplement Designator JIS2004-Savvy Designator /CIDFontName & Menu Name Examples
3 Std StdN KozMinStd-Regular, 小塚明朝 Std R
KozMinStdN-Regular, 小塚明朝 StdN R
4 Pro ProN KozMinPro-Regular, 小塚明朝 Pro R
KozMinProN-Regular, 小塚明朝 ProN R
5 Pr5 Pr5N KozMinPr5-Regular, 小塚明朝 Pr5 R
KozMinPr5N-Regular, 小塚明朝 Pr5N R
6 Pr6 Pr6N KozMinPr6-Regular, 小塚明朝 Pr6 R
KozMinPr6N-Regular, 小塚明朝 Pr6N R
7 Pr6 Pr6N KozMinPr6-Regular, 小塚明朝 Pr6 R
KozMinPr6N-Regular, 小塚明朝 Pr6N R

もちろん、このフォント名の問題についてすべてのフィードバックを歓迎する。

🐡

Adobe-Japan1-7 のサブセットフォント

Posted on August 20, 2018 by Dr. Ken Lunde | Comments (0)

English (英語) here

新元号に対応した Adobe-Japan1-7 サブセットフォント作成方法の提案とフィードバックのお願い

（前回の記事で述べたように、日本で新しい元号が発表されると、まもなく Adobe-Japan1-6 文字コレクションの仕様が Adobe-Japan1-7 へ更新される。この記事では、フォントの更新に必要となる作業を説明、提案する。読者からのフィードバックを歓迎する。）

Adobe-Japan1-6 に含まれる 23,058 個のグリフを全てサポートしている日本語の OpenType フォントについては、Adobe-Japan1-7 に更新するのは比較的シンプルだ。二つのグリフとそれに関連するマッピングを追加、そして Adobe-Japan1-7 の識別子を使用してそのフォントに名前をつければ完成だ。だが、もちろん、すべてのフォントに新年号用合字を加えて、Adobe-Japan1-7 にアップデートする必要はない。この記事はアップデートしたいフォントがある場合に、フォント開発者に参照していただきたい。

まず、「OpenType Font Development」のサブセクションの「JIS2004-Savvy OpenType Fonts」にある表は以下のようにアップデートする必要があることは明らかだ。

Supplement Designator JIS2004-Savvy Designator /CIDFontName & Menu Name Examples
3 Std StdN KozMinStd-Regular, 小塚明朝 Std R & KozMinStdN-Regular, 小塚明朝 StdN R
4 Pro ProN KozMinPro-Regular, 小塚明朝 Pro R & KozMinProN-Regular, 小塚明朝 ProN R
5 Pr5 Pr5N KozMinPr5-Regular, 小塚明朝 Pr5 R & KozMinPr5N-Regular, 小塚明朝 Pr5N R
6 Pr6 Pr6N KozMinPr6-Regular, 小塚明朝 Pr6 R & KozMinPr6N-Regular, 小塚明朝 Pr6N R
7 Pr7 Pr7N KozMinPr7-Regular, 小塚明朝 Pr7 R & KozMinPr7N-Regular, 小塚明朝 Pr7N R

だが、下位の Supplement だけをサポートする JIS90 対応のフォント、あるいは、上位の Supplements から少数のグリフのみを取り入れて JIS2004 対応としているフォントについては、どのように対処すべきだろうか。以下に詳述する。

全ての日本語フォントが Adobe-Japan1-6 で指定された 23,058 個のグリフ全てを含んでいるわけではなく、多くのフォントが Adobe-Japan1-3 だけをサポートしている。その中には、JIS2004 対応とするために、上位 Supplements 4 ~ 6 の中から、144 個のグリフを追加したものもある。例えば、macOS にバンドルされた最新のヒラギノフォントは Adobe-Japan1-3 か Adobe-Japan1-5 をサポートし、JIS2004 に対応している。日本語書体のグリフをデザインするには膨大な時間と労力が必要だ。しかも、23,000 個以上のグリフが必要とされている場合でも、23,000 個のグリフ全てが頻繁に使われるわけではない。

そこで Adobe-Japan1-6 をフルにサポートしていないフォントをサポートするよう拡張するより、新元号の漢字から成る合字のグリフのみを追加したいという要求がまず生ずるだろう。そのために必要となる作業は以下のとおりだ。

JIS90 準拠の OpenType フォント

JIS90 に準拠する OpenType フォントの開発は比較的容易だった。というのもこれらのフォントはすでに定義されていた Supplements の中から一つを選び、そこに定義されているグリフ含めればよかったからだ。一般的な多くのフォントが、Adobe-Japan1-3（グリフ数 9,453）、Adobe-Japan1-4（グリフ数 15,444）、Adobe-Japan1-5（グリフ数 20,317）のいずれかとなっている。

Adobe-Japan1-7 と新元号用の二つのグリフを検討する場合、Supplement 3（別名 StdN）フォントには CID+23058（横書き用）だけが必要だ。現在と以前の年号の縦書き用合字は、Supplement 4 で初めて加えられたので、Supplement 3 ではサポート範囲外と見なすことができる。Supplement 4 とそれ以上のフォントでは、CID+23058 と CID+23059（縦書き用）を単に追加するだけだ。フォント名中の識別子 Pro、Pr5、Pr6 はそのままにし、CFF テーブル中、Supplement の値は「7」とする。

JIS2004 準拠の OpenType フォント

Adobe-Japan1-6 の文字コレクションは「OpenType Font Development」のサブセクションの「JIS2004-Savvy OpenType Fonts」にある下記の表の通りだ。JIS2004 に準拠するために上位の Supplements からのどのグリフを下位の Supplement をサポートするフォントに追加すべきかがわかる。

Supplement Additional Glyphs Designator CIDs & CID Ranges
3 144 StdN 4—9354, 9779, 12101, 12870, 13320–13327, 13330, 13332–13333, 13335–13341, 13343, 13345–13355, 13358–13369, 13371, 13373–13382, 13385–13388, 13391–13400, 13402, 13460, 13495, 13538, 13624, 13650, 13673, 13731, 13803, 13860, 13893, 13915, 13949, 13964, 14013, 14066, 14074, 14111, 14116, 14196, 14272, 14290
5—16977, 17041, 18760, 19312, 19346, 20175, 20222, 20263–20296, 20301–20305, 20307, 20314
6—21072–21074
4 81 ProN 5—16413, 16444–16449, 16467–16468, 16889, 16905, 16977, 17014, 17041, 17168, 17205, 18759–18760, 19061, 19312, 19346, 20175, 20222, 20263–20296, 20299–20310, 20312–20315
6—21071–21074, 21558, 21933, 22010, 22920
5 10 Pr5N 6—21071–21074, 21371, 21558, 21722, 21933, 22010, 22920

以下の表では、Adobe-Japan1-7 とその二つの新しいグリフを考慮に入れた場合、下位 Supplements をサポートするフォントがどのように調整されるべきかを示す。

Supplement Additional Glyphs Designator CIDs & CID Ranges
3 145 StdN 4—9354, 9779, 12101, 12870, 13320–13327, 13330, 13332–13333, 13335–13341, 13343, 13345–13355, 13358–13369, 13371, 13373–13382, 13385–13388, 13391–13400, 13402, 13460, 13495, 13538, 13624, 13650, 13673, 13731, 13803, 13860, 13893, 13915, 13949, 13964, 14013, 14066, 14074, 14111, 14116, 14196, 14272, 14290
5—16977, 17041, 18760, 19312, 19346, 20175, 20222, 20263–20296, 20301–20305, 20307, 20314
6—21072–21074
7—23058
4 83 ProN 5—16413, 16444–16449, 16467–16468, 16889, 16905, 16977, 17014, 17041, 17168, 17205, 18759–18760, 19061, 19312, 19346, 20175, 20222, 20263–20296, 20299–20310, 20312–20315
6—21071–21074, 21558, 21933, 22010, 22920
7—23058–23059
5 12 Pr5N 6—21071–21074, 21371, 21558, 21722, 21933, 22010, 22920
7—23058–23059

容易に見て取れるように、Supplement 3 のサブセットは Supplement 7 からの CID+23058 のみを含む。JIS90 準拠のフォントの項で説明したように、CID+23059 が含まれなくていい理由は現在と以前の三つの元号 U+337B「㍻」、U+337C「㍼」、U+337D「㍽」及び U+337E「㍾」の縦書き用合字が Supplement 4 に含まれていて、Supplement 3（別名 StdN）には含まれていないからだ。これらの合字のCIDは、Supplement 4 において、12041 から 12044 となっている。なお、「StdN」グリフセット（Adobe-Japan1-3 と Supplements 4 から 6 までの 144 個のグリフ）は 10 年以上安定しており、元号の縦書き用合字への要望はいままでなかったことを付け加えておく。

最後に、CFF テーブル中の Supplement の値は CID の末尾の値に合わせるべきであることを強調しておきたい。例えば、CID+23058 を含む Adobe-Japan1-3 フォントは「Std」フォントであっても「StdN」フォントであっても、「7」を Supplement 値に指定するべきである。

この記事に関してのフィードバックをお送りいただきたい。ここで提案した方法は理にかなっていると思うが、他のオプションを検討する時間もまだ十分にある。

🐡

Adobe-Japan1-7 Subset Fonts

Posted on August 10, 2018 by Dr. Ken Lunde | Comments (0)

日本語 (Japanese) はこちら

Per the previous article, the Adobe-Japan1-6 Character Collection specification will be updated to Adobe-Japan1-7 shortly after Japan’s new era name is announced. This article notes some of the changes that need to be considered as part of that update, and I am therefore soliciting feedback on the ideas that are presented below.

For OpenType Japanese fonts that already support Adobe-Japan1-6 in its entirety, meaning that all 23,058 glyphs are included, updating to Adobe-Japan1-7 is a relatively simply matter of adding two glyphs and its associated mappings, along with renaming the fonts to use an Adobe-Japan1-7 designator. Of course, not all fonts need to be updated to include the Adobe-Japan1-7 glyphs, and this article is meant to benefit Japanese font developers who plan to do so for some or all of their fonts.
Continue reading…

Preparing for May 1, 2019—2019年５月１日の準備

Posted on August 8, 2018 by Dr. Ken Lunde | Comments (0)

(After realizing that the retargeting of Adobe-Japan1-7 to include only two glyphs, and with a fairly predictable release date range, exhibited characteristics of a pregnancy, I became inspired to write the text for the Adobe-Japan1-6 is Expecting! article while flying from SJC to ORD on the morning of 2018-07-20. I also prepared the article’s images while in-flight. The passenger sitting next to me was justifiably giving me funny looks. My flight to MSN, which was the final destination to attend my 35th high school class reunion in greater-metropolitan Mount Horeb, was delayed three hours, and this gave me an opportunity to publish the article while still on the ground at ORD.)

What do we know about Japan’s new era name? First and foremost, its announcement is unlikely to occur before 2019-02-25, because doing so would divert attention away from the 30th anniversary of the enthronement, 2019-02-24, but it may occur as late as 2019-05-01, which is the date on which the new era begins. That’s effectively a two-month window of uncertainty.

Interestingly, the date 2019-05-01 takes place not only during UTC #159, which will be hosted by me at Adobe, but also during Japan’s Golden Week (ゴールデンウィーク), which may begin early to prepare for the imperial transition.
Continue reading…

Adobe-KR-9 캐릭터 콜렉션—첫 번째 공개 릴리스

Posted on July 20, 2018 by Dr. Ken Lunde | Comments (0)

English (영어) here

2017년 6월 23일 제가 서울에 위치한 산돌의 사무실을 방문했을 때, 마지막 업데이트로부터 근 20년이 다 되어가는 Adobe-Korea1-2 (링크를 클릭하면 PDF가 다운로드됨)를 대체할 만한 새로운 한국어 글리프 세트를 개발하는 것에 대한 논의가 시작되었습니다. 그리고 이는 새로운 Adobe-KR-9 캐릭터 컬렉션의 첫 번째 공개 릴리스로 완결되었습니다. 본 글리프 세트는 네 번의 초안을 거쳐 완성되었습니다. 첫 번째 초안은 2017년 10월 1일, 두 번째 초안은 2017년 12월 19일, 세 번째 초안은 2018년 1월 8일, 그리고 2018년 3월 2일의 네 번째 초안을 거쳐 2018년 5월 15일 베타 릴리스가 공개되었습니다. 여기에는 전체 데이터 파일 세트, 대표적인 글리프들의 완전한 세트, 오픈타입/CFF 폰트의 모든 기능이 포함된 두 가지 예제, 그리고 기타 보조 자료가 포함되어 있습니다.

본 글리프 세트에 대한 아이디어가 탄생한 이래로 1년이 조금 넘게 지난 오늘, 첫 번째 공개 릴리스를 발표하게 된 것을 기쁘게 생각합니다. 베타 릴리스와 첫 번째 공개 릴리스 사이에 변경된 사항이 궁금하신 분들은 스펙의 이전 버전 변경사항 섹션을 참조하십시오. 첫 번째 공개 릴리스에 해당하는 Adobe-KR-9 CMap 리소스는 이제 CMap 리소스 프로젝트에서 사용이 가능합니다. 이 프로젝트를 방문하는 동안, 최신 출시 버전에서 1,990페이지의 UTF-32.pdf 파일을 다운로드하여 책갈피를 확인하시기 바랍니다. 이 버전은 UTF-32 CMap 리소스를 위한 글리프 테이블을 제공합니다.

🐡

The Adobe-KR-9 Character Collection—First Public Release

Posted on July 19, 2018 by Dr. Ken Lunde | Comments (0)

한국어는 (Korean) 여기

What began on 2017-06-23 when I visited Sandoll‘s office in Seoul, which included discussions about developing a new Korean glyph set to replace Adobe-Korea1-2 (if you click the link, the PDF will download) that was last updated nearly 20 years ago, has culminated in the First Public Release of the new Adobe-KR-9 Character Collection. This glyph set went through four drafts—First Draft on 2017-10-01, Second Draft on 2017-12-19, Third Draft on 2018-01-18, and Fourth Draft on 2018-03-02—followed by a Beta Release on 2018-05-15 that included a complete set of data files, a complete set of representative glyphs, two fully-functional example OpenType/CFF fonts, and other collateral materials.

After a little over a year since the idea for this glyph set was born, I am pleased to announce that the First Public Release was issued today. For those who are curious about what changed between the Beta Release and the First Public Release, please reference the Changes Since Earlier Versions section of the specification. The Adobe-KR-9 CMap resources that correspond to the First Public Release are now available in the CMap Resources project. While visiting that project, be sure to download the bookmarked 1,990-page UTF-32.pdf file from the latest release that provides glyph tables for all UTF-32 CMap resources.

🐡

“Tally Marks” OpenType-SVG Font

Posted on June 12, 2018 by Dr. Ken Lunde | Comments (0)

As a follow up to my Ideographic Tally Marks article from over two years ago, the characters for two tally mark systems—ideographic (called 正の字 sei-no ji in Japanese, and 正字 zhèng zì in Chinese) and Western-style—are among the 684 new characters in Unicode Version 11.0 that was released exactly a week ago, and these seven new characters can be found in the existing Counting Rod Numerals block from U+1D372 through U+1D378.
Continue reading…

Contextual Spacing GPOS Features: ‘cspc’ & ‘vcsp’

Posted on April 22, 2018 by Dr. Ken Lunde | Comments (5)

Japanese line layout is very complex, and the first attempt to standardize its rules and principles was in the JIS X 4051 standard, which was first issued in 1993 with the title 日本語文書の行組版方法 (Line Composition Rules for Japanese Documents in English). There was a revision issued in 1995, and the latest version was issued in 2004 with the slightly different title 日本語文書の組版方法 (Formatting rules for Japanese documents). Another important document is the W3C Working Group Note JLREQ (Requirements for Japanese Text Layout), which provides much of what is described in JIS X 4051, but covers additional areas, and is tailored toward web technologies. Although still considered working drafts, W3C is also preparing similar documents for Chinese and Korean as CLREQ (Requirements for Chinese Text Layout) and KLREQ (Requirements for Hangul Text Layout and Typography), respectively.

This article is not about these standards per se, which are intended for apps and environments that implement sophisticated line layout. Rather, this article is about harsher “plain text” or comparable environments that generally do not need such treatment, yet still benefit from a modest amount of context-based spacing adjustment, particularly to get rid of unwanted space between full-width brackets and other punctuation whose glyphs generally fill half of the em-box. App menus, app dialogs, and simple text editors are examples of where such adjustments can improve text layout in these modest ways.
Continue reading…

CMap Resources & Character Collections

Posted on March 10, 2018 by Dr. Ken Lunde | Comments (0)

The CMap resources that are associated with our public glyph sets—called character collections—were first open-sourced on 2009-09-21 via Adobe’s first open source portal, and about a year later the project was moved to SourceForge. I then migrated the project to GitHub on 2015-03-27 where it is likely to remain for the foreseeable future. The main purpose for open-sourcing our CMap resources was to make it easier for developers to include them in their own open source projects, many of which require that the components themselves be open source.

I then open-sourced three of our four character collections on GitHub—Adobe-GB1-5, Adobe-CNS1-7, and Adobe-Japan1-6—in October of last year. The Adobe-Korea1-2 character collection was intentionally not open-sourced, because it will soon be replaced by the Adobe-KR-9 character collection that is expected to be published in mid-May.
Continue reading…

Three Down, One To Go…

Posted on October 15, 2017 by Dr. Ken Lunde | Comments (0)

Earlier this month, I decided to move the Adobe-Japan1-6 character collection specification to the Adobe Type Tools organization on GitHub, which was partly motivated by constantly-changing URLs on our Font Technical Notes page. Another motivation was to make the specification itself easier to maintain. At some point, I will be adding a more complete list of Supplement 7 (aka Adobe-Japan1-7) candidates to its wiki.

To this end, I decided to do the same for the Adobe-CNS1-7 and Adobe-GB1-5 character collection specifications while on vacation in South Dakota. For the former, I also used the opportunity to update the specification to include Supplement 7 (aka Adobe-CNS1-7), by adding its representative glyphs and other details.

So, that’s three down, and one to go.
Continue reading…

Adobe-Japan1-6 on GitHub

Posted on October 3, 2017 by Dr. Ken Lunde | Comments (0)

This is a very brief article whose purpose is to simply state that—due to recent events beyond my control*—the Adobe-Japan1-6 character collection specification is now an open source project that is hosted on GitHub as a new repository in the Adobe Type Tools organization.

Most of my morning was consumed by porting the original text from Adobe InDesign to GitHub-flavored Markdown, and, while I was touching the text, I decided to seize the opportunity to make several corrections and updates. The 500-glyphs-per-page representative glyph charts are now in a separate PDF file. I also used the opportunity to update the aj16-kanji.txt datafile, and also added the latest-and-greatest Adobe-Japan1-6 UVS (Unicode Variation Sequence) definition file. All good stuff, I think.

Enjoy!

🐡

* Adobe’s IT folks apparently felt compelled to (once again) change the URLs for all of the font-related Adobe Tech Notes, including Adobe Tech Note #5078 (The Adobe-Japan1-6 Character Collection). Its URL is somewhat broadly referenced, including in the IVD_Collection.txt file of the latest version of the IVD (Ideographic Variation Database). The bottom line is that I needed a stable URL.

Super, Mega & Ultra OTCs

Posted on August 26, 2017 by Dr. Ken Lunde | Comments (1)

Per a suggestion by a friend named Leroy, I recently renamed the multiple-style and multiple-family OTCs (OpenType Collections) in this open source repository which includes such OTCs that are based on the Adobe-branded Source Han and Google-branded Noto CJK families. These multiple-style and multiple-family OpenType Collections were described in this article from April of this year. The purpose of this particular article is to introduce better names for them besides Super OTC.

First, some background about Super OTCs…

Shortly after Source Han Sans and Noto Sans CJK were released, I came up with the idea of creating a single OpenType Collection that includes all languages and all weights, and the name Super OTC was coined. This was included in the Version 1.001 update (2014-09-12) as a fourth deployment format for both families, and each one included 28 fonts. These were expanded to 36 fonts when the HW (half-width, ASCII-only) fonts, which covered only the Regular and Bold weights, were added as part of the Version 1.002 update (2015-04-20). Source Han Serif and Noto Serif CJK included a Super OTC in their Version 1.000 release (2017-04-03).
Continue reading…

When Simplified Chinese Isn’t Exactly Simplified

Posted on May 31, 2017 by Dr. Ken Lunde | Comments (1)

Er, um, oops.

✨🙈✨🙉✨🙊✨

Continue reading…

Source Han Unicode

Posted on May 10, 2017 by Dr. Ken Lunde | Comments (1)

One of my hobbies is apparently to explore various ways to stress-test Adobe products, and the target of today’s article happens to be recent adventures with Adobe InDesign and our Source Han families.

The background is that I produced Unicode-based glyph synopses as part of the Source Han Sans and Source Han Serif releases, but those PDFs show only up to 256 code points per page, and it takes several hundred pages to show their complete Unicode coverage. I also produced single-page PDFs that show all 65,535 glyphs. A Source Han Sans one is available here, and a Source Han Serif one is available here. However, they are not Unicode-based.
Continue reading…

Source Han Sans vs Source Han Serif

Posted on May 8, 2017 by Dr. Ken Lunde | Comments (9)

At seemingly every opportunity, whether via this blog or during public speaking engagements, I have made it abundantly clear that the Adobe-branded Source Han families share the same glyph set as the corresponding Google-branded Noto CJK families. That is simply because it is true. What requires a bit of explanation, however, is how the two typeface designs—Source Han Sans and Source Han Serif—differ. That is what this particular article is about.

As the Project Architect of these Pan-CJK typeface families, I have my fingers on all of the data that was used during their development, and for preparing each release. I can therefore impart some useful tidbits of information that cannot be found elsewhere.
Continue reading…

Three Multiple-Family Super OTCs

Posted on April 24, 2017 by Dr. Ken Lunde | Comments (18)

To take the previous article further—and because I tend to have an urge to stress-test environments—I added two more Super OTCs to the Source Han Super OTC open source project this morning.
Continue reading…

Introducing Source Han Super OTC

Posted on April 23, 2017 by Dr. Ken Lunde | Comments (9)

The release of Source Han Serif earlier this month, on 2017-04-03, gave me an opportunity to build yet another resource for stress-testing environments, particularly those that consume OpenType/CFF Collections. (This also continues to simplify file management by combining three Super OTCs into a much larger one.)
Continue reading…

Designing & Implementing Biáng

Posted on April 8, 2017 by Dr. Ken Lunde | Comments (2)

Besides being the world’s first open source serif-style Pan-CJK typeface families, the Adobe-branded Source Han Serif and the Google-branded Noto Serif CJK also represent the first broad deployment of two highly-complex and related ideographs that are in the process of being encoded. Their glyphs are shown above in all seven weights. Although it may be hard to believe, the fourth line illustrates the simplified version.
Continue reading…