What I like about version 2.0 of the Times Reader is that it's quite easy to read, it's intuitive to navigate, and it looks very much like the printed version of The New York Times. In addition, the newsreader application makes good use of the capabilities that become possible with the adoption of a rich media environment, such as video, content update, and search. Also noteworthy are the ability to read off-line, the seven-day archive, and the interactive crossword puzzle. (It wouldn't be The New York Times without it, would it?) Being a visual kind of guy, I very much enjoy using the "News In Pictures" section and eventually click through to the related article whenever an image gets me interested.

There are two other features that rank high on my list of favorites. The first is the "Browse" mode; it allows you to get a bird's eye view of the content. This is great for quickly scanning the articles and jumping through sections, just as how you might do in a printed newspaper. The other nice feature is the adjustable layout; when you change the size of the window, the content (text and images) reflows and readjusts to the available area. And all of this happens while preserving the design characteristics of the layout. It's simply brilliant! (You can tell that it wasn't developed entirely by engineers...) All in all, I think that the Times Reader 2.0 greatly improves the user experience of reading the news on a digital screen. It did for me and got me hooked to reading on screen more often than before.

I was fortunate enough to have been a beta tester of the Reader, but more than that, I actually contributed directly to its production. The teams at both Adobe and the New York Times in charge of developing the Times Reader wanted it to have a similar look and feel similar to the printed edition, so part of that meant that they needed to use the same fonts. The problem was that the fonts were in the old Type 1 format (a.k.a. PostScript) and AIR does not support it, so they needed to be converted to OpenType. Luckily, Adobe has a Type Development team; they got in touch with us and asked if we were able to do the job.

I have enough things on my plate to keep me busy full-time (and then some), but as soon as I knew about this opportunity my first reaction was to volunteer for the task. How could I have passed on such a high-profile project that will be seen by millions of people? And how could I have ignored the possibility to contribute to improving the reading experience? At this point I had already seen some mock-ups and prototypes and they looked fantastic. So after getting legal clearance we got the conversion started, and this is where things became interesting.

Initially I did a straightforward conversion from Type 1 to OpenType, since we wanted to change the fonts' data as little as possible. But the Adobe team developing the Times Reader came back to us saying that the text set with the new fonts didn't look very good. (I didn't have access to the actual app to test the fonts in context, so they sent us some screenshots and the text needed improvements indeed.)

First test after the fonts had been converted from Type 1 to OpenType. Notice the 'v', 'w' and 'y' in Franklin Medium. The window is a basic AIR app.

I took a closer look at the fonts, and that's when things started to make sense. The alignment zones, the standard stems values, and the glyph hints were completely out of whack. It looked like they belonged to some other outlines, not the ones in the font. When fonts are rasterized at large size (e.g. 72pt) and/or high resolution (e.g. 600dpi), having bogus hinting data is not that much of a problem. But if the fonts need to be used at small sizes in low resolution environments -- as is the case of the Times Reader app -- they definitely need to have good hinting data, otherwise it does more harm than good to the rasterization result.

So I corrected the hinting parameters, re-hinted the fonts, rebuilt them and delivered the new batch to the Times Reader developers. They acknowledged that the text looked better, but there were still a couple of new problems. For instance, the bars on the lowercase letters 'f' and 't' were not aligning with the serifs of surrounding letters like 'n', 'u' or 'y'. The difference in height was just one pixel, which doesn't seem much. But if you consider that a lowercase 'x' is only seven pixels high when the text size is set to "Small" on the Times Reader, one single pixel is quite a lot. It's definitely enough to be noticeable and distracting when you're trying to read the news, that's for sure. In this case, to correct the problem I had to do minor tweaks to the outlines of the glyphs 'f' and 't'; their bars where raised to match the x-height.

Sample article and text enlargement showing the misalignment of the crossbar on the lowercase 't'.

All these adjustments confirmed once again that if something works for print it doesn't necessarily mean that it'll work for screen. What application developers often don't realize is that they cannot just use any font for their project's UI or its content. Some designs lend themselves better to that usage, but as you can see from the example above, the design alone won't guarantee that the font will perform well on screen. So here's a shout out to all you type designers and font developers out there: You need to realize that the fonts you put out should work well on screen, because the screen is increasingly the primary environment where your fonts will be seen.

One last thing the designers of the Times Reader struggled with was how fonts embedded with the new DefineFont4* format rasterize differently when compared with the previous format. The differences are often negligible, but in some cases the results are indeed noticeably different, especially when the text is set at small sizes. I've put together a little Flex app that tries to demonstrate it. The font used is Minion Pro Regular. Compare for example when the font size is set to 14 ppem. The x-height of the TextInput that uses the DefineFont4-embedded font is one pixel higher. What happens is that the x-height alignment zone that controls the top of the lowercase letters is forcing them to snap (i.e. to grid-fit) to a whole pixel. This ensures that the glyph features at the x-height stay aligned and don't look fuzzy, but unfortunately has the side effect of somewhat distorting the proportions of the glyphs.

Sample article where the text is displayed with hinting turned off (top) and turned on. Enlarged words (bottom) displayed with hinting turned off (left) and turned on (right).

This effect was something that the designers were not happy with, and their first reaction was to turn hinting off completely. I sympathize with them, since I don't like to see distorted designs either, and I understand that this doesn't happen with fonts embedded using the DF3 format. But at the same time I value DF4 hinted text more because the rasterization is superior, and generally that makes text more legible. In the end, what we all found out was that by simply using fractional font sizes we could have the best of both worlds: hinted text with virtually no distortion.

Check out the video with XD Senior Experience Design Manager Jeremy Clark and Senior Experience Developer Daniel Wabyick where they discuss their collaboration with the New York Times on the AIR-based Times Reader.

*Embedded Font Subsetting Using DefineFont4
SWF file format specification (version 10) | (PDF, 940K)

While some typeface designers do much of their work for corporate clients, this area was new to us. Robert & I met with the leaders of Adobe's Experience Design and Brand teams to develop a design brief. They wanted a 21st-century feel combined with an earnest readability. As the project grew, Christopher Slye led regular follow-up meetings with the client teams to keep them up to date and tease more input out of them. Robert's accustomed to aiming his work at the more general case, so it was an interesting challenge to have a very specific set of design goals. What he produced is as classic as all his other designs, but with an uncharacteristic blend of contemporary touches for on-screen rendering and a more "progressive" feel.

Of course Adobe Clean had to work really well at text sizes, including on-screen. Most sans-serif families aren't really designed for use in extended text, but Robert is a master at text and tuned the face to shine in these conditions. Text families require a subtle balance of harmony, rhythm and individuality, and Adobe Clean handles these remarkably well.

Another fairly unusual feature is the set of figure styles. There are four figure heights in Adobe Clean:
- one to align with the cap height,
- one at more traditional figure height for general mixed use,
- one to align with the small cap height,
- and of course one for oldstyle figures (both proportional and tabular).
The cap-height figures were a special case. Adobe uses a lot of product abbreviations like "CS4". Non-aligning figures in something like a product splash screen would look pretty awkward!

Robert developed a font with weight, width and optical size axes. This allowed us to play around with the exact values, to find a final set of fonts that worked well for specific uses. And as future needs come up, we can easily tweak the "look" with new instances. At the moment Adobe is using a series of weights at text size for printed material. We're working with the Brand team to help them think about other optical sizes, but it's a challenge to educate the many outside vendors who produce Adobe materials.

There's another set of instances for user interfaces, called Adobe Clean UI. (You can see early versions in the Adobe Media Player and Adobe TV.) Miguel Sousa did a lot of work in the Flash-based UI frameworks for Adobe's next-generation applications, to make sure that the UI instances were optimally adjusted for that use.

Naturally Robert designed our standard set of pan-European characters for our usual broad linguistic support, as Adobe products are localized for an increasing number of countries. (Although the text family has polytonic Greek, we removed the polytonic from the UI fonts; we figured monotonic Greek was plenty for user interfaces!)

This will be a phased transition, so for now most materials you see are still using Myriad. But if you keep an eye out, you'll see that changing over time. Product teams immediately asked when we'd have CJK support - and Arabic, Hebrew, Thai, and more. Maybe later! In the mean time, here's a teaser: Robert's nearly done with an equally-innovative Adobe Clean Serif, which may appear in promotional materials before long.

- David L

Thus far, we have published articles about SING, and about some of our CJK fonts. I plan to post an article about IVSes (Ideographic Variation Sequences), and how they can be leveraged in Japanese publishing workflows.

In any case, for those interested in all things CJK, I encourage you to visit, bookmark, and enjoy this blog.

Of course, comments are always welcome, and encouraged.

I grew up in the rural north-west corner of Arizona in a town of about twelve hundred persons, on the border of the Navajo Nation. At a young age I became fascinated with the languages and cultures of peoples at home and abroad, and poured over encyclopedia articles illustrating the writing systems of ancient civilizations. I studied Spanish and Russian languages on and off from middle school through college, although I would say that I am now only conversationally fluent in either. I entered Brigham Young University intending on getting my degree in Russian language. Part of the reason I attended BYU was that I wanted to perform with its International Folk Dancing Ensemble, which I did (just not on the tour team). It was while in college that I developed a taste for everything Indian: the food, the music, the festivals, and especially Bollywood cinema.

After two years of working on the type designs of others, I decided that the next step was for me to try to learn how to translate my own concepts and ideals into type. I chose to enroll in the Masters program at the University of Reading, in part because of its focus on designing for world scripts. It was during this year dedicated to experimentation and growth that I decided to tackle the challenge of designing a typeface for Devanagari. With the help of Gerry Leonidas, Fiona Ross, Gerard Unger and several others, I was able to develop the confidence in my own skills of perception and design that I needed to feel comfortable to go back into the world of type. While I was based in the UK, I took advantage of my location and tried to visit as much of Europe as was possible for a student. I visited Germany, France, the Netherlands, Belgium, and Russia. Italy and Spain are still on my ‘to visit’ list, as is much of Eastern Europe.

After graduation, I worked for a few short months with London’s finest at Dalton Maag before I was offered my current position at Adobe. I believe that I was offered this opportunity not only for my potential for becoming a skilled designer and technician, but also because of my interest and commitment in improving typographic options for people whose scripts are currently underserved by today’s digital typography. I am both humbled and proud to be able to work with the industry leaders in type design and engineering and look forward to being a part of the innovative work that will come from Adobe’s type team in the future.

This release finally brings the FDK tools fully up to par with the OpenType specification. The most notable new features are that the FDK now fully supports all GSUB and GPOS lookup categories, and can apply the feature file directives to TTF source fonts to build TTF fonts with OpenType layout tables. The power of the FDK command-line tools can now be applied to building fonts for all scripts, including complex scripts such as Arabic and Indic.

AFDKO 2.5 also supports several of the newer OpenType features: user-friendly names for stylistic set features, and expanded lookup flag settings for use with mark classes. In addition, for CJK fonts, the tools now support Ideographic Variation Sequences (IVSes).

If you're someone who builds or tests fonts, please try it out! (Installation is now working better as well, and there is a command file for Windows that avoids the earlier need to edit environment variables). Note that the AFDKO is tools are all command-line based, and and require some willingness to get technical.

- Read Roberts

Robert Slimbach has been designing typefaces for 25 years. He's responsible for the design quality of the type library in general and the Adobe Originals series in particular. Robert's designs have won numerous awards, including the Prix Charles Peignot and six TDC2 awards. He was instrumental in moving Adobe's fonts toward broader language coverage, and was an early promoter for contextual layout and support for optical sizes in text families. designer profile

Ken Lunde is an authority on East Asian text handling and font technologies. His book "CJKV Information Processing", now in its second edition, is a standard reference in the industry (catalog). Among many other accomplishments, Ken helped to define Unicode's first Ideographic Variation Sequence registry.

Read Roberts develops and maintains the tools we use to make our fonts, including the AFDKO (Adobe Font Development Kit for OpenType) that we offer for free download (AFDKO site).

Nicole Minoza is our program manager, moving various projects along when she's not running marathons or doing programming herself. She was a Political Science major (with a side in Computer Science) and is now working on her MBA.

Ernie March has worked on fonts for 25 years, many of them at Adobe. He handles most of our font testing, doubles as our release engineer, and occasionally finds time to help with font development.

Gu Hua is a recent addition to the team. She has worked on East Asian fonts for more than 12 years. Now she tests our East Asian fonts and related technologies.

Christopher Slye is the team lead for font development. He's both a typeface designer and font technician. He maintains the databases we use to build our fonts, and was responsible for overhauling all our fonts to bring them up to current best practices. designer profile

Miguel Sousa got his MA in Typeface Design in 2005 from the University of Reading, where his Calouste design won a TDC2 award. He helps develop our newer font families, and is our in-house expert on Flash & Flex. Miguel serves as the main "answer guy" for font technical questions both inside and outside the company in forums like Typophile.

Paul D. Hunt became fascinated with languages and cultures early in life. This eventually led to a BA in International Studies. Paul's affinity for languages and design then converged in typeface design. He landed an internship with P22, which turned into a multi-year job. Paul went on to hone his type craft at the University of Reading, where he graduated with merit from the Masters program in Typeface Design in 2008, then joined the Adobe team in January 2009. In addition to basic Latin, Paul has designed typefaces for Cyrillic, Greek, Devanagari and typefaces with extended Latin coverage to support African and American Indian languages. He is a frequent contributor to (and moderator for) Typophile, and helps maintain its wiki.

And of course I'm here too. I fell in love with letterforms in the 1970s, which led to a degree in graphic design. After working in the publishing industry I joined the Adobe type team in 1986, and have been involved with our font development, tools and technologies ever since. I originally hoped to design type, but found I could make more of a difference managing the team and doing things like helping to define the behavior of OpenType layout features.

Adobe also has a Type Development team in Tokyo, led by Taro Yamamoto with font technologist Masataka Hattori and typeface designer Ryoko Nishizuka. designer profile We'll have more about their work in another post.

We're all looking forward to more communication with each of you as our work here continues to evolve.

- David Lemon

Fonts embedded in the SWF or AIR application can get one of three different native Flash rasterizing modes:
- the original Flash outline rasterizer, available in all versions of Flash Player and AIR
- the Saffron rasterizer, available in Flash Player 8 and later, and in all versions of AIR
- the new DefineFont 4 rasterizer, available in Flash Player 10 and AIR 1.5

Support for the new DefineFont 4 embedded font format is new in FP 10 and AIR 1.5, and is only exposed by pre-release build tools at this time - such as the Text Layout Framework plug-in for FLash Professional CS4, and Flex "Gumbo."

There is a bit of a "gotcha" in this area that one of my colleagues on the TLF team wanted me to reiterate. With the current pre-release tools and environments available to play with TLF, the existing Flash TextField container doesn't support DefineFont 4 fonts, and the new TLF stuff *only* works with DefineFont 4 fonts, and doesn't support DefineFont 3 fonts. One can envision scenarios where a developer wants to use both TLF and TextField containers for the same font in a given file, in which case they would literally have to embed the font twice, once in DF4 and once in DF3 (or earlier). I think this is a good example of an area in which this TLF stuff is pre-release software. But gee, you can do an awful lot with it.

* * * * *

In unrelated news, this is my last post for this blog. I'm sorry to say I'm leaving all my amazing colleagues and cool work at Adobe. It's been a really great 11 1/2 years, and I count myself lucky to have been part of making some great typefaces and cool applications. If anybody is looking for me personally, as opposed to Adobe type, I'm I can be emailed at cal.berkeley.edu as tphinney at that address (alumni email will redirect to whatever my current email is). Don't worry, I expect my colleagues will keep the blog going!

What is the Text Layout Framework? It's an extensible ActionScript library for use with Adobe Flash Player 10 and Adobe AIR 1.5, It lives on top of the new text engine found in these products, and exposes the power of this text engine in exciting new ways, including:

- many layout and text flow features, hyphenation and justification capabilities, including advanced features for East Asian languages.

- supports DefineFont 4, the latest format for embedding fonts in Flash and AIR applications. DF4 supports OpenType layout tables, and is necessary to have embedded fonts that support the advanced typographic capabilities in question. Some of the new language support is also reliant on DF4 for embedded fonts. (Of course, you can also use device fonts which have the needed features.)

Check out the features with the cool, highly interactive Flash demo at the top of the TLF Labs page.

How can you author content for it? You can author for TLF using the public pre-release of Flex "Gumbo," or the plug-in component for Adobe Flash CS4 Professional (part of the TLF release).

Yes, this is the solution formerly code-named "Vellum," which was previewed a year ago at Adobe MAX, and at more length at this year's MAX (including in the keynote, and in talks by me and by lead engineer Robin Briggs). It was also seen at MAX in a technology preview of a news reader app created for the International Herald Tribune.

I am seriously excited about this technology. I can't comment about specific product plans, but obviously this is going to be a cornerstone of future text support in Flash, Flex and AIR.

For more details, see:
- the release notes
- the TLF team's blog
- the release on Adobe Labs
- the TLF Forum.
- the Flex Examples blog on embedding fonts in Flex Gumbo (added on 25 Nov 2008)

Typefaces you might have seen in CS3 that aren't in CS4: Arno Pro, Bickham Script Pro, Garamond Premier Pro. Further typefaces bundled with InDesign CS3 but not InDesign CS4: Bernhard Modern Std, Caflisch Script Pro.

There are more East Asian fonts, notably:
- Adobe Kaiti Std and Adobe Fangsong Std, additional simplified Chinese fonts
- With InDesign and suites including InDesign, the "Pr6N" versions of the Kozuka Gothic and Kozuka Mincho typefaces. These fonts have the Adobe-Japan1-6 character set, and are JIS-2004 savvy.

All in all, still a LOT of fonts, just a slightly smaller set.

ACaslonPro-Bold.otf
ACaslonPro-BoldItalic.otf
ACaslonPro-Italic.otf
ACaslonPro-Regular.otf
ACaslonPro-Semibold.otf
ACaslonPro-SemiboldItalic.otf
AGaramondPro-Bold.otf
AGaramondPro-BoldItalic.otf
AGaramondPro-Italic.otf
AGaramondPro-Regular.otf
BellGothicStd-Black.otf
BellGothicStd-Bold.otf
BirchStd.otf
BlackoakStd.otf
BrushScriptStd.otf
ChaparralPro-Bold.otf
ChaparralPro-BoldIt.otf
ChaparralPro-Italic.otf
ChaparralPro-Regular.otf
CharlemagneStd-Bold.otf
CooperBlackStd-Italic.otf
CooperBlackStd.otf
EccentricStd.otf
GiddyupStd.otf
HoboStd.otf
KozGoPro-Bold.otf
KozGoPro-ExtraLight.otf
KozGoPro-Heavy.otf
KozGoPro-Light.otf
KozGoPro-Medium.otf
KozGoPro-Regular.otf
KozMinPro-Bold.otf
KozMinPro-ExtraLight.otf
KozMinPro-Heavy.otf
KozMinPro-Light.otf
KozMinPro-Medium.otf
KozMinPro-Regular.otf
LetterGothicStd-Bold.otf
LetterGothicStd-BoldSlanted.otf
LetterGothicStd-Slanted.otf
LetterGothicStd.otf
LithosPro-Black.otf
LithosPro-Regular.otf
MesquiteStd.otf
MinionPro-Bold.otf
MinionPro-BoldCn.otf
MinionPro-BoldCnIt.otf
MinionPro-BoldIt.otf
MinionPro-It.otf
MinionPro-Medium.otf
MinionPro-MediumIt.otf
MinionPro-Regular.otf
MinionPro-Semibold.otf
MinionPro-SemiboldIt.otf
MyriadPro-Bold.otf
MyriadPro-BoldCond.otf
MyriadPro-BoldCondIt.otf
MyriadPro-BoldIt.otf
MyriadPro-Cond.otf
MyriadPro-CondIt.otf
MyriadPro-It.otf
MyriadPro-Regular.otf
MyriadPro-Semibold.otf
MyriadPro-SemiboldIt.otf
NuevaStd-BoldCond.otf
NuevaStd-BoldCondItalic.otf
NuevaStd-Cond.otf
NuevaStd-CondItalic.otf
OCRAStd.otf
OratorStd-Slanted.otf
OratorStd.otf
PoplarStd.otf
PrestigeEliteStd-Bd.otf
RosewoodStd-Regular.otf
StencilStd.otf
TektonPro-Bold.otf
TektonPro-BoldCond.otf
TektonPro-BoldExt.otf
TektonPro-BoldObl.otf
TrajanPro-Bold.otf
TrajanPro-Regular.otf
AdobeHeitiStd-Regular.otf
AdobeMingStd-Light.otf
AdobeMyungjoStd-Medium.otf
AdobeSongStd-Light.otf
AdobeKaitiStd-Regular.otf
AdobeFangsongStd-Regular.otf

Here are the fonts loose on disk with InDesign CS4 (includes all the fonts listed above, plus more):

ACaslonPro-Bold.otf
ACaslonPro-BoldItalic.otf
ACaslonPro-Italic.otf
ACaslonPro-Regular.otf
ACaslonPro-Semibold.otf
ACaslonPro-SemiboldItalic.otf
AGaramondPro-Bold.otf
AGaramondPro-BoldItalic.otf
AGaramondPro-Italic.otf
AGaramondPro-Regular.otf
BellGothicStd-Black.otf
BellGothicStd-Bold.otf
BirchStd.otf
BlackoakStd.otf
BrushScriptStd.otf
ChaparralPro-Bold.otf
ChaparralPro-BoldIt.otf
ChaparralPro-Italic.otf
ChaparralPro-Regular.otf
ChaparralPro-Light.otf
ChaparralPro-LightItalic.otf
CharlemagneStd-Bold.otf
CharlemagneStd-Regular.otf
CooperBlackStd-Italic.otf
CooperBlackStd.otf
EccentricStd.otf
GiddyupStd.otf
HoboStd.otf
KozGoPro-Bold.otf
KozGoPro-ExtraLight.otf
KozGoPro-Heavy.otf
KozGoPro-Light.otf
KozGoPro-Medium.otf
KozGoPro-Regular.otf
KozMinPro-Bold.otf
KozMinPro-ExtraLight.otf
KozMinPro-Heavy.otf
KozMinPro-Light.otf
KozMinPro-Medium.otf
KozMinPro-Regular.otf
LetterGothicStd-Bold.otf
LetterGothicStd-BoldSlanted.otf
LetterGothicStd-Slanted.otf
LetterGothicStd.otf
LithosPro-Black.otf
LithosPro-Bold.otf
LithosPro-Regular.otf
MesquiteStd.otf
MinionPro-Bold.otf
MinionPro-BoldCn.otf
MinionPro-BoldCnIt.otf
MinionPro-BoldIt.otf
MinionPro-It.otf
MinionPro-Medium.otf
MinionPro-MediumIt.otf
MinionPro-Regular.otf
MinionPro-Semibold.otf
MinionPro-SemiboldIt.otf
MyriadPro-Bold.otf
MyriadPro-BoldCond.otf
MyriadPro-BoldCondIt.otf
MyriadPro-BoldIt.otf
MyriadPro-Cond.otf
MyriadPro-CondIt.otf
MyriadPro-It.otf
MyriadPro-Light.otf
MyriadPro-LightIt.otf
MyriadPro-Regular.otf
MyriadPro-Semibold.otf
MyriadPro-SemiboldIt.otf
MyriadStd-Sketch.otf
MyriadStd-Tilt.otf
NewsGothicStd.otf
NewsGothicStd-Bold.otf
NewsGothicStd-Italic.otf
NewsGothicStd-BoldItalic.otf
NuevaStd-BoldCond.otf
NuevaStd-BoldCondItalic.otf
NuevaStd-Cond.otf
NuevaStd-CondItalic.otf
NuevaStd-Regular.otf
NuevaStd-Italic.otf
NuevaStd-Bold.otf
NuevaStd-BoldItalic.otf
NuevaStd-Light.otf
NuevaStd-LightItalic.otf
OCRAStd.otf
OratorStd-Slanted.otf
OratorStd.otf
PoplarStd.otf
PrestigeEliteStd-Bd.otf
RosewoodStd-Regular.otf
RosewoodStd-Fill.otf
StencilStd.otf
TektonPro-Bold.otf
TektonPro-BoldCond.otf
TektonPro-BoldExt.otf
TektonPro-BoldObl.otf
TrajanPro-Bold.otf
TrajanPro-Regular.otf
RyoDispStd-Medium.otf
RyoDispStd-SemiBold.otf
RyoDispStd-Bold.otf
RyoDispStd-Heavy.otf
RyoDispStd-ExtraBold.otf
RyoGothicStd-ExtraLight.otf
RyoGothicStd-Light.otf
RyoGothicStd-Medium.otf
RyoGothicStd-SemiBold.otf
RyoGothicStd-Bold.otf
RyoGothicStd-Heavy.otf
RyoGothicStd-ExtraBold.otf
RyoTextStd-ExtraLight.otf
RyoTextStd-Light.otf
RyoTextStd-Medium.otf
RyoTextStd-Regular.otf
AdobeHeitiStd-Regular.otf
AdobeMingStd-Light.otf
AdobeMyungjoStd-Medium.otf
AdobeSongStd-Light.otf
AdobeKaitiStd-Regular.otf
AdobeFangsongStd-Regular.otf
KozGoPr6N-Bold.otf
KozGoPr6N-ExtraLight.otf
KozGoPr6N-Heavy.otf
KozGoPr6N-Light.otf
KozGoPr6N-Medium.otf
KozGoPr6N-Regular.otf
KozMinPr6N-Bold.otf
KozMinPr6N-ExtraLight.otf
KozMinPr6N-Heavy.otf
KozMinPr6N-Light.otf
KozMinPr6N-Medium.otf
KozMinPr6N-Regular.otf

Monday night (tomorrow) at the InDesign User Group in London, England, I'll be doing an updated version of my favorite talk: Typography for Humans. "Traditonal typography was restricted by mechanical limitations. However, the digital technology of OpenType has spawned fonts which celebrate the human hand and the human mind, from random elements that mimic handwriting and calligraphy, to fonts that translate themselves, censor themselves, or predict the future. Along the way, fine typography is largely automated. But it is still easy to create typography which, in favoring aesthetics or tradition over legibility, fails to achieve its basic purpose of communication. Thomas Phinney explores and demonstrates these human and anti-human developments on the frontiers of digital typography, with typefaces created by himself, his Adobe colleagues, and others around the world."

Admission is free, and if it's like other IDUG meetings I've been to, so is the pizza. :)

October 18th, at the AIGA "Social Studies" conference (graphic design education conference) in Baltimore, I'll be doing a short talk on legibility in typography.

October 23rd, I'll be giving the same talk as the London one above, at my undergraduate alma mater, the University of Alberta, in Edmonton, Canada.

October 27th I'll be speaking at the University of Lethbridge (Canada).

As part of this late October road trip, I may also line up something in Calgary and possibly Vancouver as well... TBD. Let me know if you have any suggestions of people I should work with to arrange such a talk. :)

Users of many Adobe applications such as InDesign, Illustrator and Photoshop have been noticing for a while that the version of the four Arial Narrow fonts that ship with Office 2007 and Windows Vista had a problem. They didn't show up correctly in the font menus of these Adobe applications. Instead of four styles of Arial Narrow showing up, there would be just one. It was however under the main "Arial" family, unlike the older version of Arial Narrow.

Basically, Microsoft tried to enhance the font menu names for the family, but inadvertently gave all four fonts the same style of just "Narrow" rather than the needed "Narrow Italic" and so on. We worked with them to identify the problem and how to fix it, and they've now released the fixed fonts. These will doubtless show up in some future service pack(s) for Office and/or Windows, but until then, follow that link for a "Hotfix."

ADDENDUM: [added 12 Sep 2008] The process of installing the new fonts may confuse the Adobe font caches. As my colleague Dov Isaacs put it, "The trick is that you need to rebuild the Adobe font cache mechanism. First, exit all Adobe programs. Then, search and delete ALL files of the form AdobeFnt##.lst where ## is a two digit number."

In OpenType fonts, mark attachment is the GPOS (glyph positioning) rule which dynamically positions diacritical marks (accents and the like) relative to base characters or other marks.

The currently available version of Adobe’s Font Development Kit for OpenType (AFDKO) does not support OpenType mark attachment. Hence, other tools based on the AFDKO, such as FontLab or DTL FontMaster, do not support it either. We’re currently implementing such support, which will in turn determine the underlying code used by such third party tools. This also means extending the syntax of the AFDKO language to represent mark attachment. However, mark attachment is complicated, and gets even more so when one makes it contextual. The best way to represent it in the same style as other AFDKO code is not entirely clear. Here’s what we’d like your feedback on.

(Special thanks to Read Roberts, AFDKO engineer, for the remainder of this post!)

The syntax for a mark-to-base positioning rule ( GPOS lookup Type 4) is planned to be:

   position
        <glyph or glyph class> # The base glyph
        <anchor X Y>  # the anchor position on the base glyph
        mark
        <mark class name>;

Example:

# define a mark class
    mark [ acute grave] <anchor 300 0> @TOP_MARKS;

# use mark class name in a mark-to-base rule.
    position [a e o  ] <anchor 350 400> mark @TOP_MARKS;

Adding a contextual prefix and suffix to this is not obvious, as the input glyph in a mark-to-base rule ( that is, the glyph which is matched in the current text stream when the rule is applied) is the mark class rather than the base glyph class. The way that this rule is applied is that when the current glyph matches in the mark class for a mark-to-base rule, the application looks back in the input stream for a matching base glyph. (The lookup flag may also instruct the application to skip other mark glyphs when doing so).

Some possible representations:

position
    <context prefix: none or more glyphs or glyph classes>
    <glyph or glyph class>"
    <anchor X Y>
    mark
    <mark glyph class name>'
    <context suffix: none or more glyphs or glyph classes>

• Write the complete stand-alone base-to-pos position rule
• Add double-quote to the base glyph or glyph class, to show that it is NOT part of preceding context.
• Add one single quote to the mark class name, to show that this is the input that needs to match the current glyph position
• Add the contextual prefix sequence before the base glyph
• Add the contextual suffix after the mark class name

Why do we support EOT? Our surveys of web designers and font developers have made it clear to us that users want an HTML/CSS font solution that allows them to use any font they want, and most of them would like to do so legally. In particular, they want to be able to use regular retail and OS-bundled fonts. With original fonts on web servers, hardly any retail or commonly-used fonts could legally be used; only freeware and open source fonts, some shareware, and a handful of retail fonts.

Some open source advocates argue that there are enough and good enough free/libre and open source fonts available that retail/commercial fonts are unnecessary. Whether they are right in principle or not (and I think not, given how few such fonts are decently made and come in even a basic set of four styles with bold, italic and bold italic), it doesn't matter: the web designers who make web sites want to be able to use a vastly wider variety of fonts, and companies and organizations that have a web presence want to use their existing visual identity online, or at least a close adaptation. Being able to use 50% of the world's fonts instead of 5% comes a lot closer to meeting these needs.

Why is it so? EOT comes vastly closer because many more type foundries and type designers are comfortable with EOT than are comfortable with original fonts on Web servers. And that includes Adobe.

As far as protection of the fonts (something type designers and font vendors care about), the situation is not that much different from fonts embedded in PDF or SWF (Flash) files. The fonts are there, the specs are public, and in principle somebody can rip off the font. Doubtless a few people will. But I honestly expect the same thing will happen with EOT as with these other formats: even a mild barrier is enough to keep most people honest. Think of it as equivalent to a traffic signal: most people will stop at the red light. That’s good enough for us, and for many other font designers/vendors as well, it seems.

Another way in which EOT is not a DRM format is that it is not the sole or even the primary format an end user can license. Although some font vendors may see an interesting opportunity to license fonts directly in the EOT format, customized for each user and web site, I don’t see this possibility as eliminating sale of licenses for “regular” fonts. Certainly at Adobe we intend to continue to license OpenType CFF fonts, from which users can then derive EOT fonts for their HTML/CSS projects, just as they do various embedding operations with those fonts.

If you're a web designer wanting to use fonts in HTML/CSS, let's compare this to the music DRM situation. This is not like you buying a protected music file that you can’t move to another machine and can’t copy freely. This is instead like providing an interchange format for your music files that gives you a new option for letting your friends listen to about half your music files legally and legitimately... while you still have the original unprotected file as well! Sweet! It doesn't stop you from copying your original files and giving those to your friends (likely illegally), but it does give you an additional option that lets you share your music. (I can already hear some of you saying, "okay--and this is a bad thing why? Which is of course exactly my point.)

So that's why calling EOT a DRM format as a pejorative or as a scare tactic is misleading at best: it implies a bunch of things that are not true of EOT, at least not any more.

* * * * *

On August 28th, an absurd post went up on Slashdot, which is in many ways typical of the kind of FUD going around about EOT. Here are my comments on that piece:

- There is no requirement to subset in EOT, and hence no requirement to regenerate EOT files when a page changes. However, subsetting may be a good idea for download size reasons! The availability of subsetting as an option is an advantage of EOT over unprocessed original font files. Microsoft's existing WEFT implementation may subset by default, but users can override that as they wish, or customize the subsetting (hmm, not going to need all that Greek and Cyrillic support on my web page!). Of course, if the font license allows, one could do subsetting of native fonts as well, but that has complications because of the fact that you're spinning off incompatible fonts into the wild. Keeping web fonts separated from general-use fonts is a Good Idea if you want to have the option of subsetting.

- Although the original incarnation of EOT required the EOT font be tied to some particular URL/domain, the spec submitted to the W3C specifically removes this requirement. EOT fonts which omit this informationa are still compatible with Microsoft's existing EOT support.

- The primary reason EOT has been “largely ignored” is because it was a Microsoft-only “standard”; making it an open spec avoids this problem. Nothing to do with subsetting.

- Having a public spec (already available now) EOT is no longer a DRM format in the traditional sense, as described earlier.

- EOT can do a much better job of "breaking Microsoft's forgotten monopoly" (on web fonts) than original font files; many times more fonts are or will be legally usable with EOT than as OS-native fonts on web servers.

My previous web font posts on web fonts and EOT:
- First comments on the Web fonts problem (March 2006)
- Comments on original fonts vs EOT format for Web fonts, and survey (November 2007)
- Initial results of my end user survey (November 2007)

Unicode ranges often have available character slots which are as yet unassigned, and each new version of Unicode commonly assigns some of these. This makes supporting entire Unicode ranges a bit of a moving target for a font developer. I could release a font tomorrow that supports a bunch of specified Unicode ranges, and then when the next version of Unicode comes out, I might find that there are now more characters in those ranges.

An encoding is a standardized system, across multiple computers and fonts, which maps numbered codepoints to characters. Those numbered codepoints are used as an access mechanism for those characters, by software and operating systems. Unicode is the main encoding in use these days, though there are many others. I think of an encoding as a set of slots (characters), and a font as having glyphs which fill some or all of those slots (default glyphs for various characters). Some glyphs may not be encoded at all (not in any slot), or may not fit neatly in a single slot (many ligatures are unencoded), or may be alternate forms for a default glyph (maybe tied by a string to the default glyph sitting in the slot?).

A code page is an encoding, typically a single-byte encoding, specific to some group of languages. Within any given system of code pages, the same code points are generally recycled over and over so they have different meanings in different code pages. For example, the Windows code pages work that way, as do the Mac OS codepages. These days, code pages are mostly obsolete for their original purpose, because code pages are largely supplanted by Unicode as a single universal encoding. But code pages they serve as a convenient shorthand for indicating character set coverage. Thus some of Adobe's font readmes have talked about what Windows and Mac codepages are supported by particular fonts.

A character set is a term sometimes applied to a glyph list as well. But strictly speaking, each one entry on the list should be a single codepoint. So, Microsoft's WGL-4 is a character set, as is H&FJ's

A glyph list is a slightly broader term than a character set. It can include glyphs which are not characters, or do not correspond directly to a single character. For example, there are some combinations of a base letter and an accent which do not exist as single characters in Unicode, but could be represented by a single pre-composed glyph (or by two separate glyphs). For that matter, there are cases of single Unicode characters which might be handled by two or more glyphs. If the listing happens to include such cases, it suddenly matters whether it's a "Character set" or a "glyph list."

This post owes a special thanks to my colleague Miguel Sousa, who spent many hours compiling lists based on my spreadsheets and directions, and checked my data repeatedly in various ways. Any errors are probably mine, but he created the linked tables of HTML which are linked from this page, as well as the tab-delimited text files which are linked in turn from those pages.

What is "Latin" anyway? That's the writing system used for European languages including English, but also everything from Portuguese to Turkish, Lithuanian to Italian. Many languages written with the Latin writing system use accented characters, and some unusual letters peculiar to only one or two languages, such as the eth, thorn and yogh. Some countries have switched to (or from) Latin versus other writing systems at various points in history; for example, in recent years there have been a number of former Soviet bloc countries which have switched to Latin from Cyrillic for political reasons.

I should also point out that there's a bit of a misnomer in the title and body text of this post: I refer to "characters" and "character sets." Why is this a problem? A "character" is a fundamental element with its own unique codepoint in Unicode. A "glyph" may represent a single character, several characters (as with a ligature), or even just a part of a character that combines with other glyphs to create the full character.

The distinction becomes relevant because the larger of these character sets start including glyphs which are not encoded by themselves, but really represent combinations of Unicode characters. Fonts consist of glyphs, and support characters. But I'd already gone down this path in my post on Cyrillic, and even the type industry usage is usually to talk about "character sets"... so there is some imprecision of wording in spots. But usually I'll be more careful/precise in my word usage (and you should be too, if you're working in this area), okay?

OVERVIEW

As part of the exercise to name the new character sets, I also codified and renamed some existing ones. I'm hoping this is short-term awkwardness with a long-term gain, but feel free to complain if you think it's a boneheaded move; it's not written in stone yet. Here's our hierarchy of Latin character sets, with the more rationalized naming scheme.

Adobe Latin 1 = 229 glyphs, formerly ISO-Adobe
Adobe Latin 2 = 250 glyphs, formerly Adobe Western 2
Adobe Latin 3 = 329 glyphs, Adobe Western 2 + CE, the basic western "Pro" font charset
Adobe Latin 4 = 616 glyphs, Adobe Western 2 + CE + most of WGL-4 + Vietnamese + (a few things)
Adobe Latin 5 = 1119 glyphs, all the Above + more accented characters + phonetics and transliteration needs

Existing public charset info is here: http://www.adobe.com/type/browser/info/charsets.html

What's covered here, and what's not?

These character set definitions cover Latin characters, accented forms, and symbols commonly used in countries using these characters. They also cover phonetics where the phonetics are closely based on Latin letterforms (e.g. IPA and APA).

Fonts with character sets covering Adobe Latin 3 (or bigger) may also support Greek and/or Cyrillic, but that character coverage is not included in the AL-3 definition (nor in AL-4 or AL-5). It would be pretty improbable that we'd ever do an AL-4 or AL-5 typeface without Greek and Cyrillic, however. Certain currency symbols which are closely tied to non-Latin countries, such as the Ukrainian hryvni, are also covered in the appropriate other character set and are not here.

Other symbols such as math and technical symbols are covered here in the Latin character sets rather than elsewhere.

Adobe Latin 1
(ISO-Adobe)
AL-1 is the original character set we ended up with for Type 1 fonts, including the later addition of the euro, for 229 glyphs plus .notdef. It covers major Western European Latin languages (a.k.a. "Roman" languages) and some minor ones: Afrikaans, Basque, Breton, Catalan (without the l-dot, added in Adobe Latin 3), Danish, Dutch, English, Finnish, French, Gaelic, German, Icelandic, Indonesian, Irish, Italian, Norwegian, Portuguese, Sami, Spanish, Swahili and Swedish.

(Note that the term "Roman" is to be avoided! It has multiple independent and often conflicting meanings in typography: upright vs italic/oblique, single-byte Latin vs CE/other, or in the style of classical Roman lettering vs not.)

Adobe Latin 2
(Adobe Western 2)
AL-2, 250 characters plus .notdef, is the most basic OpenType character set for Adobe fonts, the minimum for "Standard" fonts with western language support.

AL-2 is Adobe Latin 1 plus: uni2113 (litre), estimated, the 14 Mac "symbol substitution" characters (uni2126 (ohm/omega), pi, partialdiff, uni2206 (Delta), product, summation, radical, infinity, integral, approxequal, notequal, lessequal, greaterequal, and lozenge), and 4 characters using duplicated glyphs from other characters (uni00A0 from space, uni00AD from hyphen, uni02C9 from macron, uni2215 from fraction, and uni2219 from periodcentered).

Adobe Latin 3

AL-3, 329 glyphs + .notdef, is the union of the AL-2 character set and the Adobe CE character set, which includes major Latin-based Central European (CE) languages. AL-3 is the minimum character set for western "Pro" fonts.

AL-3 covers the same languages as AL-1/AL-2, plus 79 characters to cover Croatian (Latin), Czech, Estonian, Hungarian, Latvian, Lithuanian, Polish, Romanian, Serbian (Latin), Slovak, Slovenian and Turkish.

Adobe Latin 4

AL-4, 616 glyphs plus .notdef, is the character set that will be used for future mega-families on the scale of Hypatia Sans Pro, Arno Pro and Garamond Premier Pro. Not all new Western typefaces from Adobe will necessarily be AL-4, although we expect many will be.

Compared to AL-3, it adds 287 glyphs to support: Afar, Azerbaijani, Belarusian (Latin), Chichewa, Esperanto, Gikuyu, Greenlandic, Guarani, Igo/Igbo, Kuskokwim, Luba (Ciluba), Malay, isiNdebele, Oromo, Pilipino/Tagalog, Setswana, Sidamo, Somali, Sotho (Northern and Southern), Swazi, XiTsonga, Tuareg, Uzbek (Latin), Vietnamese, Welsh, isiXhosa, Yoruba, and isiZulu. For Latin-based transliteration, it supports several schemes for Indic and Arabic, as well as Cyrillic and Pinyin Chinese.

We've long had Latin character sets beyond AL-3, but their definition has been fluid and has grown over time. All our fonts that are significantly beyond AL-3 should "at some point" be upgraded to full AL-4. But don't hold your breath, okay? Some things that are in some of those current fonts are not going to be part of the official AL-4 definition either; not everything that's in our existing Latin coverage will make it into AL-4 and future mega-fonts.

Adobe Latin 5

AL-5 is a massive Latin glyph complement of 1119 glyphs (plus .notdef). We currently intend to use it in only a couple of core typefaces.

Additional languages supported in AL-5, by adding 502 glyphs over AL-4, include: Bambara, Baule, Northern Berber languages (Tarifit, Kabyle, Tachelhit, Tamashek, etc.), Bislama, Cornish, Dinka, Fula, Hausa, Latin, Luxembourgish, Malagasy, Maltese, Marshallese, Mende, Sami, Venda, Wolof. For transliteration, it adds support for International Phonetic Association (IPA), Khmer, Mongolian, another Hindi scheme, pan-Athapaskan native American languages, and the Americanist Phonetic Alphabet (APA). Note that most of the added glyphs are actually supporting transliteration and phonetic needs.

>Supplemental Spreadsheet, 470K Excel file

This spreadsheet shows the additional characters/glyphs in the Adobe Latin 4 and 5 character sets, and which languages need which, but only over and above the characters already supported in Myriad Pro version 2.0 (the current version in 2007-08, shipped in CS3). Being based on "what's extra over some arbitrary typeface" makes it a highly Adobe-centric document, and I hesitated to upload it at first. But I concluded that it was better to give more information (however awkward it might be for non-Adobe folks to use it), than to not give enough.

[Updated spreadsheet Aug 29th to add a note on Croatian digraphs (only supported in AL-5) and unhide some rows.]

One column in there shows which of the characters in question are supported by Hypatia Sans Pro. The asterisks in that column are for things needed in AL-4 that aren't in Hypatia Sans Pro. I was wondering what it would take to upgrade Hypatia Sans to AL-4. The answer as it turns out is "enough that it's not going to happen as part of the release of the full family" (when the italics are done). Right now I don't even have time to finish the darn italics. sigh.