Posts in Category "Testing Fonts"

Introducing IVS Test

Yesterday morning I came up with the idea to produce a font for testing the extent to which applications and other text-handling environments support IVSes (Ideographic Variation Sequences), and ended up devoting the better part of this Easter weekend assembling, testing, and releasing the font as open source on GitHub. The font is named IVS Test, and as usual for me, it is an Adobe-Identity-0 ROS CID-keyed OpenType/CFF font.
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 4E00vs2F00.zip 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.

CSS Orientation Test OpenType Fonts

I am pleased to announce that the new CSS Orientation Test OpenType Fonts open source project was launched on Adobe’s open-source portal, Open@Adobe, today. This open source project consists of two OpenType/CFF fonts that were developed at the request of Koji Ishii (石井宏治), the editor of Unicode’s forthcoming UTR #50 (Unicode Vertical Text Layout). The purpose of these fonts is for developers to be able to more easily test whether glyph orientation in their implementation is correct or not.
Continue reading…

Thank you to all our Chinese and Japanese community translators

In the past few months we’ve had a lot of activity by the Chinese and Japanese communities on our Community Translation project (over 100 accepted translations). We are very pleased to see all of this activity and want to publicly thank the following five individuals:

Ying Ning
Tonny Xu
Vincent Ding
Hai Liang
Takesato Hayashi

Without them, and all of the other individuals we mentioned in previous posts, this program would not be a success.

To learn more about the Adobe Type Community Translation program, refer to Typblography project page. If you have any questions or requests related to the Type Community Translation program feel free to reach out to us at type-translations@adobe.com.

A very useful AFDKO ‘tx’ tool command line…

For those AFDKO users who use, plan to use, or would like to explore the broad capabilities of its tx tool, here’s a command line that is very useful when building new versions of existing fonts, especially when only a small number of glyphs have changed:

% tx -bc -sha1 -z 400 <font_file>

The <font_file> portion of the command line can be any type of font file, such as an OpenType font, a CFF resource, a CIDFont resource, or a name-keyed Type 1 font.
Continue reading…

Always Check Your Outlines

The photo below, which was recently taken by my long-term Adobe colleague Dirk Meyer in Beijing, serves as a not-so-gentle reminder that intersecting outlines can result in very obvious printing errors:

The photo depicts the two ideographs 出口, which represent the word meaning exit. The glyphs are obviously designed through the use of components whose outlines necessarily intersect, and under some circumstances—including the circumstance that led to the printing of this signage—can result in a negative or reverse fill.
Continue reading…

An “Extreme” OpenType Font

I like building fonts. I especially like building fonts with a large number of glyphs. Fortunately, my job entails developing OpenType CJK fonts, which means that I need to deal with fonts with thousands or tens of thousands of glyphs.

I built an “extreme” OpenType font last year, and spent the morning making it even more extreme. Given that “extreme” fonts are useful for stress-testing software that consumes fonts, I figured that this post would be a good opportunity to make it available to developers who may benefit by testing with this font.

Did I mention that I like building fonts? ☺
Continue reading…

用脚本实现字体安装

Windows的“字体文件夹”提供了安装新字体的功能, 具体方法是打开“控制面板”中名为“字体”的文件夹, 选择“文件”菜单中的“安装新字体”选项进行字体安装。如果系统盘是“C”盘,字体文件夹的目录就是 “C:\windows\fonts”,我们也可以直接手动拷贝字体文件到该目录。拷贝完成之后,字体文件夹会自动安装该字体并向系统发送字体更新的消息,所以字体文件夹具有自动安装字体的功能。但是通过指令(比如 copy指令)拷贝字体到字体目录是无法实现自动安装字体的,因为这类指令实现的仅仅是文件复制的过程,无法触发字体文件夹安装字体的功能,如想使新安装的字体有效,必须通过重新启动电脑来识别安装新字体。

Continue reading…