Posts in Category "Using Fonts"

Source Han Sans Version 1.002 Update

The Source Han Sans Version 1.002 update was released on 2015-04-20, which involved turning a very large crank on something that has a very large number of moving parts. The updated region-specific subset OTFs are also available on Typekit via desktop sync.

Google’s corresponding Noto Sans CJK fonts, which differ from Source Han Sans only by name, were also updated to Version 1.002 at the same time, and reflect the same changes.
Continue reading…

Collections… …of the OpenType/CFF Variety

Let it be known that the “OpenType Collection” (OTC) format was born on 09/21/2011 at Pho Minh Restaurant in Cupertino, California. Present from Adobe were the following: David Lemon, Ken Lunde, Sairus Patel, and Read Roberts. Present from Apple were Antonio Cavedoni, Julio Gonzalez, Yasuo Kida, Peter Lofting, and Tony Tseung. — Adobe & Apple

The above declaration paved the way for supporting (CFF-based) OpenType Collections in Apple’s OS X (beginning from Version 10.8) and in Adobe’s applications (beginning from CS6).
Continue reading…

Source Han Sans: OTF, OTC, Super OTC, or Subset OTF?

Before I begin the series of articles about what went into building Source Han Sans, I think that it is worth writing a few things about actually installing and using the fonts, including how to determine which of the four deployment formats best suits your needs.
Continue reading…

IDS + OpenType: Pseudo-encoding Unencoded Glyphs

For those who are not aware, there are twelve IDCs (Ideographic Description Characters) in Unicode, from U+2FF0 through U+2FFB, that are used in IDSes (Ideographic Description Sequences) which are intended to visually describe the structure of ideographs by enumerating their components and arrangement in a hierarchical fashion. Any Unicode character can serve as a IDS component, and the IDCs describe their arrangement. The IRG uses IDSes as a way to detect potentially duplicate characters in new submissions. All existing CJK Unified Ideographs have an IDS, and new submissions require an IDS.

This article describes a technique that uses IDSes combined with OpenType functionality to pseudo-encode glyphs that are unencoded or not yet encoded. If memory serves, it was Taichi KAWABATA (川幡太一) who originally suggested this technique.
Continue reading…

U+4E00 versus U+2F00

Not all PDF authoring applications are the same, in terms of the extent to which they preserve the text content of the original document. Of course, this is not necessarily the fault of the PDF authoring application, but rather it is due to a disconnect between the PDF authoring process and access to the text content of the original document.

The best example for demonstrating this is to create a document that includes the two kanji 一 (U+4E00) and ⼀ (U+2F00). The reason why these two characters represent a good example is because in mainstream Japanese fonts, mainly those that are based on the Adobe-Japan1-x ROS, both map to the same glyph, specifically CID+1200.

If you download and unpack the file, you will find two PDF files, an Adobe InDesign file, and an MS Word file. If you open the original documents and search for 一 (U+4E00), you will find only a single instance, which is the one that is marked by the Unicode scalar value. However, if you open the respective PDF files, you will notice a difference. The one that is based on the MS Word file now includes two instances of 一 (U+4E00), and ⼀ (U+2F00) is no longer included in its content. You can search a PDF file by Unicode scalar value by using the “\uXXXX” notation, such as \u4E00 for U+4E00 (一). (Note: Depending on the version of MS Word that is being used, the PDF file may instead include two instances of (U+2F00). I am using Microsoft Word for Mac 2011 Version 14.3.8.)

Adobe InDesign has a built-in PDF library that has direct access to the text content, and is thus able to inject it into the text layer of the PDF file that it produces. MS Word uses a different pathway for producing a PDF file, one that does not have access to the text content of the original document.

Some initial Adobe-Japan1-6 versus UTR #50 thoughts…

UTC (Unicode Technical Committee) Meeting #136 took place last week, and one of the significant outcomes was that UTR (Unicode Technical Report) #50 was advanced from Draft to Approved status. Congratulations to Koji ISHII (石井宏治), its editor, and also to Eric Muller, who took the initiative to start this project and served as its first editor.
Continue reading…


[This (Simplified) Chinese version of the May 1, 2013 Typblography article entitled Adobe contributes font rasterizer technology to FreeType is courtesy of Gu Hua (顾华).]

今天我们很荣幸地宣布Adobe向FreeType提供了CFF字体光栅处理程序。可测试的代码已经包含在最新的FreeType Beta版中。该开源项目是由Adobe,Google和FreeType三方合作,旨在改善使用FreeType的设备和环境上的CFF字体渲染质量。

现代字库有两种字形轮廓格式可供选择—TrueType或者CFF。TrueType是Apple于1990年开发的,而CFF(Compact Font Format)格式是Adobe基于1984年首次发布的Type 1格式(常称为PostScript字库)衍生出的第二代格式。无论是TrueType还是CFF都可被用于OpenType字库中。它们有很多共性,但也有两个主要区别:它们使用不同的数学运算方法描述字形曲线,以及使用不同的hinting技术(Hinting:提供光栅化提示,以确保在有限的像素里尽可能地准确显示每个字形)。TrueType侧重于在字体中构建指令,而Type1和CFF更多地依赖光栅器的智能处理。这使得光栅器质量显得尤为重要,对于这次合作,Adobe期望在使用FreeType环境上能显著改善CFF字体显示效果。
Continue reading…


[This Japanese version of the May 1, 2013 Typblography article entitled Adobe contributes font rasterizer technology to FreeType is courtesy of Hitomi Kudo (工藤仁美).]


近年のフォントは、TrueTypeかCFFどちらかのフォーマットを使用するのが通例です。TrueTypeは1990年にアップルによって開発されたフォーマットですが、CFF(Compact Font Format)は、アドビが1984年にリリースした(PostScriptフォントとして知られている)Type 1フォントフォーマットの第2世代にあたるフォーマットです。OpenTypeフォントでは、TrueTypeとCFFどちらも使用可能となっています。この二つのフォーマットは多くの共通点がありますが、最大の違いは次の2点です。カーブの表現に違う数式が使用されること、そして「ヒント」の形式が違うことです。(「ヒント」とは、限定されたピクセル数の中でも書体が最適の条件で表現されるようラスタライザーに指示を与えること)TrueTypeは殆どのヒント情報をフォント内のデータとして保持していますが、Type 1やCFFフォントの場合は高度なインテリジェンスをもつラスタライザーに多くを依存しています。
Continue reading…

Adobe Blank: Another Adobe-Identity-0 Implementation

As I wrote nearly a year ago, the Adobe-Identity-0 ROS is useful for building special-purpose fonts, especially CJK ones whose glyph coverage does not match one of our public ROSes. Our latest Adobe-Identity-0 ROS font is the open-source Adobe Blank, whose purposes and implementation details are described on our sister blog, Typblography.

Adobe-Japan1-6 Unicode Version 6.1 Tables

Years ago, I wrote a Perl script, called, that takes a fully-qualified PostScript name—composed of a CIDFont resource name, two hyphens, and a UTF-32 CMap resource name—then generates a PostScript file that can be distilled into a PDF. The resulting PDF file is a Unicode table, arranged in groups of 256 code points. If the UTF-32 CMap resource includes even a single mapping for a particular group of 256 code points, a page is created.

I have prepared examples that are based on the UniJIS2004-UTF32-H and UniJIS-UTF32-H CMap resources.
Continue reading…

Making “Character Codes” Look Better

In my work, I need to deal with character codes on a regular basis, such as Unicode scalar values and hexadecimal values for legacy encodings. This includes writing documents that include them. For most purposes, especially when used in tables, tabular figures work best because they are monospaced. Of course, one could simply choose to use a monospaced font. But, unless a different font is actually desired for character codes, using the same typeface design is usually preferred, because it better matches the surrounding text. The issue is that very few, if any, fonts include tabular glyphs that support hexadecimal notation, specifically referring to ‘A’ through ‘F’ (or ‘a’ through ‘f’ for lowercase). Luckily, I was able to solve this particular dilemma.
Continue reading…

Adobe 网络字体登陆WebINK

原文 Adobe Web Fonts now on WebINK

我们非常高兴地宣布与WebINK 的合作,从今天开始 Adobe 将通过 WebINK Extensis 的网络字库服务为大家提供超过180款的Adobe网络字库。如果您已是WebINK的用户,那么现在就有更多更炫的字体等待您的选择。如果您还未使用过Adobe网络字库,那么现在就又多了一种途径可以应用Adobe字库。

这186款字库中包含了22款新字库,这些新字库都可以通过我们的合作伙伴 WebINK Typekit运用到网络上,另外我们还增加了三个新字体家族到Adobe Web Font collection.
Continue reading…

关于Creative Suite 5 (CS5) 捆绑字库的介绍

作者:Nicole Minoza
• Adobe Arabic (4 种粗细风格,阿拉伯文字库)
• Adobe Hebrew (4 种粗细风格,希伯来文字库)
• Adobe Fan Heiti Std (1 种粗细风格,”Bold”,繁体中文字库 )
• Adobe Gothic Std (1 种粗细风格,”Bold” ,韩文字库)
• Ryo Display PlusN (5 种粗细风格,日文字库)
• Kozuka Gothic Pr6N (6 种粗细风格,日文字库)
• Kozuka Mincho Pr6N (6 种粗细风格,日文字库)
注意:Pr6N 版本的日文字库支持完整的Adobe-Japan1-6 字符集、IVS(异体字序列)及JIS2004字形。

Continue reading…

Symbol & Pi Fonts


  字库就象一个容器,在这个特定容器中,不仅可以存放字符也可以存放图形,两者并不冲突,因为文字本身就是从原始图形演变而来的,表意文字的演变就是一个很好的例证。文字和图形的最大区别是字符在信息化过程中被分配了统一固定的编码,而图形的随意性、多样性决定了它没有也不可能有固定编码,解决方法是为其分配编码,并将其包装成字库的格式,这类字库就被称之为Symbol Font 或Pi Font。根据图形的用途或侧重点不同,又可细分为不同种类,比如Ornaments Font(侧重花边装饰),Dingbats Font(侧重符号、标识)。

Continue reading…

“字形” 和 “字型”

“字形” 和 “字型”(zì xíng) 两个词的读音完全相同,但在用法上却有差异,下面是一个简要总结。

Continue reading…

Adobe CS4 & Mac OS X Snow Leopard

   Mac OS X 10.6 (Snow Leopard) 发布在即,很多用户非常关心Adobe软件与Snow Lepopard 的兼容性问题,关于一些热点问题的答复即将发布在Adobe的相关网页上。

Continue reading…

如何排查Mac OS X上的字体问题

 在Mac OS X 上有可能会遇到字库无法正常使用的情况,比如已安装的字库不显示在软件的字体列表中、或者字库无法正确显示字符,再或者字库安装之后软件无法正常运行。该如何排查这些问题呢?总的来说,可以从五个方面进行排查。

Continue reading…


在InDesign 中日韩版本的“ 首选项”调版中提供了更改度量单位的选项(“ 编辑”>“ 首选项”>“ 单位和增量”(Windows) 或“InDesign”>“ 首选项”>“ 单位和增量”(Mac OS) ),其中关于文字大小的单位有三种选择,它们分别是‘点’(pt)、‘级’(Q)、‘美式点’(ap)。

Continue reading…

Create Your Own “招財進寳” Glyph

When the Spring Festival comes, Chinese people have many traditional customs to create a warm and festive atmosphere. One of these customs is to plaster a large ideograph “福” on the door, to wish good fortune and happiness throughout the New Year, and some businesses would like to plaster their rooms with a special character bao.png to wish plentiful money and treasures to come in the New Year. This glyph is composed of four characters that are “招財進寳”, “財” means money, and “寳”means treasures. Actually, this glyph is not a real or genuine hanzi, and no character set includes it, so we can not enter this glyph directly via standard fonts. Fortunately, SING (Smart INdependent Glyphlets) technology offers us a way to create and use this character. Please follow these DIY (Do It Yourself) instructions for this glyph.

Continue reading…



Continue reading…