Miguel Sousa, David Lemon and I attended Linotype’s “TypoTechnica” conference recently. Here are our presentations, followed by a review of the conference and some talks.

Facelift presentation (150K PDF). My talk on why we’re revising the entire Adobe Type Library, and what kinds of technical tweaks we’re making.

Font naming presentation (2 MB PDF). This talk explains a lot about font names and style links in OpenType fonts. It seems I do this every year or two. I realized in giving this talk that I needed to update some of the slides with newer FontLab screen shots, so I did that, and it’s the updated slides that I am posting.

Glyph naming presentation (100K PDF). Another perennial favorite, which I covered in the same session as font naming.

Font Production at Adobe (150K PDF). Miguel Sousa gave this first in-depth look at the current Adobe OpenType font production process.

Font testing at Adobe (2.3 MB PDF). Miguel looks at the range of tools and procedures needed to test OpenType fonts.

QE Outputs (250K PDF). Samples of output from testing tools, goes with Miguel’s Font Testing talk.

TypoTechnica conference, April 27-29 2007 in Frankfurt, Germany.

Linotype Library (now a division of Monotype Imaging) produces this European type conference every two or three years, aimed at font designers and developers. This year there were perhaps 100-150 people. Linotype acts more as a font publisher rather than a font producer. This allows them to put out more fonts with less staff (which I’m envious of), but not doing major “production” work in house on most of their fonts, they need their type designers to do this in addition to the design work. In the new age of OpenType, technical education is critical to good font production. Linotype opens attendance to all comers, getting a broader variety of speakers and enhancing the sense of collegiality in the industry. For Adobe, we participate in TypoTechnica because our applications benefit from having third party fonts be as reliable and consistent as possible, and also out of a sense of collegiality in the industry.

This year, our attendees were:
– David Lemon (Sr Manager, Typeface Design & Engineering)
– Thomas Phinney (Product Manager, Fonts & Global Typography)
– Miguel Sousa (Type Design & Font Production)

All three of us contributed to this report, but you can blame me for anything you don’t like.

HIGHLIGHTS

Font production technical issues are as prominent as ever. There’s no sense among third parties that this is a “solved problem” for them. Indeed, if anything overall interest is rising as OpenType has become a fully “mainstream” format for font developers but many of them are new to it. We really felt that our talks and presence were relevant and provided key information to attendees.

Although typographers and type designers are aware of OpenType, the bulk of our type customers (creative professionals, especially graphic designers) are not getting the word very effectively. (Note: Education of graphic designers via conferences they go to was already a significant priority for me before attending TypoTechnica, so this just reinforces that need. Of course, attending a few conferences and talking to a few hundred people is just a tiny start, but these things have a ripple effect, and we do what we can.)

DETAILS

See also the final schedule PDF (2 MB).The full list of speakers.

Keynote: “we’re halfway there” – Christian Schwartz

– Christian Schwartz is a well-known type designer who does a lot of custom work for major magazines/newspapers (Houston Chronicle, Manchester Guardian) and large corporations (Bosch)

– OpenType is great, but a lot of users don’t entirely understand it (or app implementations/limitations).

– users often select “optical” auto-kern in InDesign, because “metrics” doesn’t communicate “font’s own values” (I passed this on to InDesign team.)

– Users (and corporations) think/know that they “need” OpenType, but don’t really know what it is. When Schwartz said to one customer he would deliver some fonts in OT format, the customer replied “but we don’t need swashes.” Aaagh!

– Users want “straight-forward fonts”; they want the designer to put the most appropriate glyph-form in the default slot, so that they don’t have to worry about choosing alternates most of the time.

– Office users want to get true small caps when they press the small cap button. Secretaries will use small caps in a letter or a memo, if the style guide says so. The only “show-stopper” is application’s lack of support. The lack of Microsoft Office support for OpenType typographic features kills interest in OT in many corporate environments. We need advanced typography support in Microsoft Office to sell OpenType typography features and fonts to an even broader audience, but are not holding our breath.

– Despite this, the need for extended language support still drives many large companies to adopt OpenType (e.g. recent work Schwartz did for Bosch).

– Note: lack of support for automatic optical size selection is a problem for both office users and graphic designers, too. Even Adobe’s apps don’t do this, as yet. (InDesign does it for the now-abandoned multiple master Type 1 format, but not for OpenType.)

Quality in Design & How to Manage It – Akira Kobayashi & Atilla Korap

– Linotype staffers gave the talk. Akira is the lead type designer at Linotype, known for a variety of his own typefaces as well as collaborations on new versions of classic designs.

– Although it was interesting, the talk didn’t really address the nominal topic as such, we thought. Atilla demonstrated FontLab Studio macros for producing small caps automatically, and diacritics positioning in all the faces based on the positioning of the Regular face. Atilla couldn’t say if the macros would be made public. The small caps macro was fine as far as it went, but did not make certain adjustments that we thought of as key for quality.

– I thought the demo didn’t compare well to what Tim Ahrens has done for automated small cap creation using MM technology in FontLab Studio (although Ahrens’ version requires the source fonts to be set up with an MM weight axis, which is certainly a limitation). We’ll see more of the Ahrens’ work at the ATypI Brighton TypeTech Forum (disclaimer: I am coordinating content for the TypeTech Forum).

OpenType Status – Jürgen Wilrodt

– PDF of the talk available. [Added this 31 May 2007 – T]

– What’s not working in OpenType today? There’s a spotty matrix of support of various aspects of OpenType. Both Microsoft and Apple don’t support full OpenType kerning well. Adobe and Apple do poorly on language-related OpenType functionality for non-Western languages (e.g. Indic languages). From the end user perspective, Microsoft looks like the main offender for general typographic functionality – there’s a whole bunch of OpenType typographic support Microsoft has added for WPF, but until WPF applications come out, it doesn’t really reach end users.

– Jürgen made a plea for applications and operating systems that do font caching to note font version numbers, and flush the cache for different versions. Provide cache-clearing capability in normal applications. This is an especially big issue for font developers, but affects normal users as well. [The OS X font cache in particular tends to get messed up, though sometimes Adobe’s font engine caches do as well.]

– observation: Adobe set up Turkish ligature behaviors in our “Standard” fonts – which don’t support Turkish! This is a benign excess data bug, but certainly looks sloppy. We’re fixing it in our next revision of these fonts.

Indic scripts – Christopher Chapman

– much explanation of the complexities of Indic text processing. Pretty intense stuff.

– Windows has some useful free tools for Unicode and multi-lingual text input: ISIS (Indian Scripts Input System), BabelPad, BabelMap text entry systems (work with Uniscribe)

Next-generation font formats – open discussion (speakers only, then results reported back to general audience the next day)

– This got off to a somewhat rocky start, as those of us from Adobe and Microsoft thought that the main theme was to be on replacing OpenType with “something else.” Our general view is that it takes a *lot* of work to get a font format widely adopted, and we’re still trying to finish the work of OpenType adoption. It turns out that the title was intended more broadly than that, and the discussion ended up focusing on what people wanted in OpenType moving forwards.

– Some folks said customer difficulty choosing between CFF and TTF outlines is blocking sales, causing complaints for some fondries. Some vendors wish there was only one outline format. But neither TrueType nor CFF (PostScript style outlines) is going away – neither flavor’s backers is about to give up their preferred format, because each has significant advantages. The real source of the problem is an app/OS support issue, not inherently a problem with having two different outlines. If both flavors were perfectly equally supported, there’s be no ptoblem. This is an area of OpenType support that Adobe is in pretty good shape on. We asked vendors to send customer complaint info to MS Office, Windows, and Mac OS as appropriate.

– font developers feel left out of development of the OpenType spec as such. They want regular updates, and visibility into what’s coming. Ideally, they’d like input via some sort of consortium like CSS or Unicode.

– complaints about 64K glyph limit in OT format. Although the needs are not frequent, the attendees believed there are occasional and important uses for fonts with more than 64K glyphs in them. However, assumptions relating to the 64K glyph limit are pervasive in operating systems and other applications, and would be hard to change.

Font Production at Adobe – Miguel Sousa (links to 150K PDF)

– Miguel showcased how we mix our own publicly available tools (Adobe Font Dev Kit for OpenType, or “AFDKO”) with FontLab and custom scripts.

– it was attended by 40+ people in a lab set up to seat ~15-18. People were very intent to learn Adobe’s font production process in detail.

– Realized FontLab needs to have some sort of “Intelligent Scaling” mechanism to be used when generating instances from a MM source, to ensure equal counters and stems.

– Developers asked about the need for decomposing SEAC glyphs. SEAC is an old and very limited composite glyph mechanism from the Type 1 format. It only works if both the accent and the base character are in Adobe StandardEncoding. SEAC has been deprecated in CFF and OpenType, and is not well supported in all enivronments today. If using FontLab, go to the preferences for “Generating OpenType PS (.otf)” and make sure the option to “Decompose all composites” is on.

– many attendees showed interest in the FontLab macros Miguel used, which will be included in the next version of the AFDKO; they were particularly interested in the one that generates the GPOS ‘kern’ feature

– the presentation “demystified the AFDKO” said one developer

fontIO library – Dave Opstad & Atilla Korap

– This is an impressive Python-language library for handling font data. It is similar to the ‘fonttools’ open source lib, but supports even more tables. Like ‘fonttools’, ‘fontIO’ allows specific table edits without recompiling the entire font. The font is loaded into a Python object and stays in memory; then each parameter can be edited before writing the font back to a file. It requires Python 2.5. Monotype intends to make the library available to third parties, but does not yet have the licensing details worked out.

PhotoFonts (& Flash) – Yuri Yarmola (FontLab Ltd)

– FontLab continues to push their full-color scalable-bitmap font format. It has a public spec as well. Essentially the format is based on XML & PNG, supporting RGB + alpha transparency. They have free plug-ins for Photoshop and apps that use Photoshop plug-ins, to allow the fonts to be used there.

– New is added photofont support for sIFR, allowing photofonts to be embedded in the Flash SWF format (requires Flash 9). An InDesign plug-in is reportedly coming later this year.

Why OpenType kerning can be cumbersome and how to deal with it – Adam Twardoch

– General problems/approaches are well known. Adam explained them well, but he didn’t present a straight-forward or cleanly reliable solution.

– Adam gave a ‘recipe’ based on FontLab’s operations, but Karsten Lücke and Miguel were concerned it could create incorrect kerning. Lucas de Groot confirmed that to get acceptable results in an OpenType ‘kern’ feature from FontLab, the kerning classes need to be ordered in a specific way (perhaps he got this clue from Miguel’s presentation in Lisbon), but the code will require additional (painful) manual work.

– some attendees complain about FontLab’s buggy handling of the kerning data; either import or export (forget which) of AFM files can lose data

– complaints about 64K limit of lookups in the OpenType format: it makes the ‘kern’ feature difficult to create as the feature may overflow this limit.

– developers generally don’t know how to solve subtable overflows, or make subtable breaks; there’s no current solution. (The new AFDKO macro will help here)

KernMaster – Frank Blokland, Dutch Type Library

– Frank demoed some of the DTL FontMaster tools

– Miguel was the most impressed with KernMaster, a tool for auto- kerning a font. You just have to provide a font and the list of pairs that would like to see kerned. Frank said that this tool uses an adaptation of an Ikarus algorithm. Miguel and Frank did an experiment with HypatiaSans-Bold and the results were very interesting; upon comparing some of the kern values generated by KernMaster and the values in the release font, Miguel thought that KernMaster’s job was as good as his first manual pass, before further refinement. (We only looked at a few Latin pairs, however.)

MORE INFO

Sunday visit to library archives: collection of type specimens
– including Engelnoff-Berner sheet

– Microsoft’s “VOLT” tool for adding OpenType layout tables to fonts only works with TrueType flavored OpenType. We discussed with Microsoft how it might be extended to cover OpenType CFF as well (PostScript style outlines).

Miguel writes:

“I really enjoyed the conference, not just from a speaker POV, but also as an attendee and participant. I had the opportunity to meet and talk to people related with this industry (font developers, application developers, type designers, and users).

“I could definitely feel that Adobe’s presence in these venues is indispensable. Adobe is still seen as a leader in this field, and everyone respects us. People stop to listen about what he have to say, and expect us to come up with solutions for their problems.

“People want to know what we do and how we do it, so that they can make their own decisions.”

Frankfurt was unseasonably warm for April – the 85 degree highs would have been a heat-wave even in summer.

Speakers and staff: Thomas in the middle with white shirt, resting his hand on David’s shoulder, with Miguel to the left of David. Just above Miguel are famed type designers Hermann Zapf and Gudrun Zapf von Hesse.

“Type cowboys” – David Lemon and Dave Opstad
http://www.flickr.com/photos/ralf_herrmann/476831638/