Why Variable Fonts Will Succeed »

Third time’s the charm? Why OpenType Font Variations (variable fonts) will likely succeed where predecessors failed.

OK, this is kind of funny: a post I wrote in November 2016 that languished in my “drafts” afterwards when I was busy with work, waiting on illustrations/​graphics that I never did add. Just for fun, I’m going ahead and publishing it exactly as is, showing what I was thinking at the time, just after Variable Fonts were announced. The only other note I want to add is that if you want to play with variable fonts, check out Axis-​Praxis.

OpenType 1.8 was announced in September, featuring variable fonts. In short, variable fonts allow for packaging an entire family of fonts in a single font file, using master designs and interpolating between them, on what are called “design axes.” The type designer who makes the font can use this for whatever they like, but varying weight or width are among the more common standard uses.

What makes this exciting is that in a savvy environment, someone using the fonts can specify any in-​between variation they like, within the “design space” (dynamic range) covered by the font. So for example, in a font with weight and width axes, a user could dial in the precise degree of boldness and level of condensing or expansion they desire.

Font families built as variable fonts are vastly more flexible than before, yet can use less file storage than traditional font families—vastly less if you have large, complex families with a ton of styles.

More details:

• FontLab announces support for variable fonts
• Official variable fonts announcement article
• OpenType 1.8 specification
• Adobe’s announcement
• Google’s announcement
• Community discussions on TypeDrawers, including the main announcement thread.

Which is all very well, but this kind of tech has been tried twice before: GX Variations (the basis of the new tech) from Apple, and Multiple Master from Adobe. Neither ever got very far. Why should this time be different?

First, I will note that when it comes to traditional design, it is only when there is support for the designer/​user picking their own arbitrary instances from the design space of the font, rather than just relying on pre-​specified instances, is there a benefit to designers. This means that traditional desktop design/​authoring apps need to implement sliders or some user interface to reap the benefits of the technology (although this is not so much of an issue for the web).

Second, the other benefit of variable fonts, more compact representation of large families, was barely noticed the first time out. But with web fonts being a big deal and file size a huge concern, this is a newly important benefit.

So, right off the bat, it is clear that it is more work to make this work with desktop apps, and that the circumstances make the web benefit more and get easier adoption.

Speaking of adoption, it is worth noting that neither all existing nor all future font families need to be delivered as variable fonts for the format to be useful and successful. It may always be a minority of fonts available, yet still be a success with strong niche use in some areas (such as web design).

Why GX Variations Failed

Apple introduced what is essentially the same tech back in 1991, as GX Variations, part of TrueType GX. While many other aspects of TrueType GX survived in varying degrees, I can’t even find a good list of GX Variations fonts. I know only three offhand: the OS-​supplied Skia GX (by Matthew Carter), the Monotype demo masterpiece Buffalo Gals (by Tom Rickner), and Adobe’s Tekton GX (by David Siegel).

GX Variations, in its original instantiation, would have required apps to give up control of their line layout to Apple’s line layout engine. Of course, this would also mean that any such app would have been Mac-​only. Although there are certainly some Mac-​only design apps, the Mac-​only aspect meant that the relevant heavyweights of the era, Quark and Adobe, never supported it.

Apple supported GX with font dev tools, but they were largely command-​line based and hardly designer-​friendly. None of the font editing tools of the era supported GX Variations, either.

With only a tiny handful of demo fonts, no major app support, and no major font tool support, GX Variations has never seen much pickup.

Why Multiple Master Failed

Adobe developed their multiple master (MM) tech at the same time as Apple did GX Variations, but completely independently. MM is a slightly less sophisticated/​complicated version of the same concept as GX variations, handled as an extension to Adobe’s PostScript Type 1 format. The MM technology was even briefly (1996–98) incorporated in the original OpenType spec, although only for OpenType fonts with PostScript outlines.

MM did a tad better than GX Variations in terms of real-​world use. There were 27 families offered by Adobe in the MM format, one by Monotype, and about eight free families from four different independent designers. Adobe also used MM internally in Acrobat’s font-​substitution technology. Illustrator added “sliders” for MM fonts, but only just before Adobe pulled the plug.

And pull the plug, Adobe did, back in late 1998. Adobe was already moving away from Type 1 fonts, and they withdrew the MM functionality from OpenType. The then-​manager of the Adobe type group, Dan Mills, believed that OpenType adoption might be significantly hampered if we were telling people they had to support this major added complication in order to properly support OpenType. Plus, OpenType ally Microsoft had never been very enamored of MM and had no interest in the tech at the time. So, Adobe pulled the plug.

Why didn’t MM get better traction before that? Well, it was an Adobe invention competing with a similar Apple technology. The folks on the Adobe font team failed to realize early enough how important it would be to actively evangelize this technology to Adobe’s own apps as well as outside apps, and devote real resources to that effort. Because Adobe apps competed with third party apps, this hindered Adobe outreach to third party app developers. And few others were involved and supporting MM, outside the Adobe type team: it was an Adobe thing.

Axis-​based Fonts Behind the Scenes

Although development of new MM fonts ceased around 1998, many type designers saw that axis-​based font technologies were very helpful in developing large families. Crude support in Fontographer followed by more sophisticated support in FontLab allowed type designers to use MM capabilities to design fonts. It is simply easier to design two weights and interpolate the rest, than to design three, six or ten weights separately. If one adds in width variations or other axes as well, that can further multiply the savings in design work. One doubts that Robert Slimbach would have designed 156 styles of Kepler individually!

Even more sophisticated tools emerged in later years, such as Erik van Blokland’s Superpolator.

As a result, even while MM and GX Variations died off, and only about three dozen families used those technologies, scores more families have since been developed using the exact same concepts—just upstream in the design process.

Other Lessons

Two other font technologies have launched later, and were informative in their own ways.

The Microsoft/​Adobe collaboration on OpenType, which later widened further into an open standard, has done well and become the primary font standard for the future. Many choices made in that process reflected learning from the MM and GX history, and it shows.

More recently, the addition of color font support to OpenType has been more disjointed; I blogged about that at some length, explaining how this served as a bit of a wake-​up call to the big players as far as the need to cooperate and collaborate on variable fonts.

What’s Different with Variable Fonts

Variable fonts are being backed from Day One by a much broader coalition than ever got behind MM or GX. The same four players who came up with four different solutions for color fonts are backing a unified approach to variable fonts. Apple, Microsoft, Adobe and Google made the initial announcement jointly (at ATypI 2016 in Warsaw), with representatives of all four companies on stage and presenting. Every one of the major players in type design tools and related utilities (including my company, FontLab) have already started implementing support, many of us having started that work before the announcement.

Assuming Mozilla joins in, this stuff is just going to work in all the latest web browser versions in pretty short order.

Because of the ongoing behind-​the-​scenes role of axis-​based fonts in development of regular fonts over the past 15-​20 years, many type designers already know how to design type families in this way, understand the flexibility and power inherent in variable fonts, and even already have existing type families that could be “relatively easily” re-​issued as variable fonts (with varying degrees of added work).

There are no guarantees. The variable fonts story still has some weaknesses, notably around formatted text interchange, and of course with desktop app support for an interface to interact with the variability. But the odds are good of at least moderate success. The alliance supporting it is strong. There are significant benefits, albeit not as compelling as OpenType as a whole.

Some Predictions

• Variable fonts will see rapid adoption in a few very high-​impact and high-​visibility places, including as system fonts.
• Variable fonts will take a little time to become popular or widespread on the web, but some sophisticated and design-​intensive web sites will love them.
• Within three years, variable fonts will become a common format for many new fonts, particularly for large or sophisticated families from major foundries and high-​end boutique foundries. But for (at least) the next few years, the same families will usually be issued as static (non-​variable) fonts as well.
• Success of variable fonts is partly dependent on app support. Thanks to subscription models for Creative Cloud and Microsoft Office (and live app updates for Google Docs), any support from apps will be rapidly seen by end users, but… these big companies tend to operate in fairly siloed ways. Cool though this tech is, it is unlikely to attract the attention that results in a top-​down dictate from on high that everyone in the company must support it. This means that the Adobe, Microsoft and Google fonts teams’ support for the fonts is no guarantee at all of front end app support by Creative Cloud, Microsoft Office or Google Docs. Such support, or the lack of it, will influence type foundries in their adoption.
• Because Apple’s existing GX Variations represents a large subset of the variable fonts technology, system-​level and desktop app-​level support for variable fonts is likely easier for Apple than for just about anyone else. Yet I still won’t bet on how quickly Apple will support this in iWork (their Keynote, Pages, and Numbers apps).
• Very few foundries, and no large ones, will release what Ben Blom calls “static variable fonts” that in essence prevent interpolation and work like a family of old static fonts while preventing user interpolation. It misses on the big advantage of variable fonts, which is the ability to pick arbitrary points in the design space. The sole advantage of such fonts is smaller file size, but potential (or actual) user confusion will cause most foundries and users to avoid this experiment.
• Variable fonts will not be the majority of retail font revenue ten years from now. They will not completely displace static fonts any time soon, if ever.

The Lesson of Color Fonts for Variable Fonts »

Today’s announcement of variable fonts in OpenType 1.8 represents a renaissance of the functionality of multiple master and GX Variations capabilities in mainstream fonts. With the announcement made jointly by Microsoft, Google, Adobe and Apple, it also marks a surprising and new level of multi-​company cooperation in font standards, at a level I for one have never seen in my nearly two decades in fonts.

The need for increased cooperation has been brought home in the past couple of years with the lurching and dispersed movement towards color fonts. The idea with color fonts is that there are uses for being able to spec multiple specific colors in the glyphs of a font, whether for colorful emoji or multi-​color letters. For color fonts, there were four different approaches that all deployed and are now in OpenType. Microsoft invented one, Apple another, Google a third, and Adobe plus Mozilla a fourth. One can debate the merits of each approach, but clearly developing them in isolation and putting four competing approaches into the OpenType spec has not helped the adoption of any or all of them. (Apple originally said their approach was only intended for internal use and did not submit it for OpenType standardization, but changed their mind and submitted it at the last minute for OpenType 1.8, so the spec just went from three to four color fonts approaches.)

In the end, although developing separately allowed for the secrecy and control, it did not yield an ideal long-​term outcome. Sure, each vendor can make fonts that work in isolation in their environment, but it should come as no surprise that users and font creators have been slow to embrace these color font solutions that worked with only  platform and limited browsers.It seems clear that the decision-​makers and reps of the companies involved were at least somewhat chastened by this outcome. I believe this lesson helped inspire increased cooperation on variable fonts.

 

More reading:

• FontLab announces support for variable fonts
• Official variable fonts announcement article
• OpenType 1.8 specification
• Adobe’s announcement
• Google’s announcement

Fabulous Adobe font/​format history article »

The good folks at Adobe just posted a huge article by Tamye Riggs covering Adobe’s type history from about 1991–2006 or so, focused especially on the invention and later abandoning of multiple masters and the rise of OpenType. It features the first and only public comment from Carol Twombly on her departure from Adobe and type design. It also has several quotes from me. 🙂

In general this is a really comprehensive article. Still, I am thinking I will write some more about the reasons OpenType succeeded where GX and MM did not.

(Note: Tamye’s series of articles on Adobe Type has been released as a full book. Very nice. Copies were in the conference-​goers’ goody bags at TypeCon 2015 in Denver.)

Fontmageddon? Windows security patch KB2753842 of Dec 11 (fixed!) »

OpenType /​ PostScript font support killed in many apps (FIXED Dec 20, 2012)

(UPDATED repeatedly, first with more details and then because of the Dec 20 fix.)

Was it Fontmageddon? For users who use fonts in some applications (see below), Windows security update KB2753842 of Dec 11, 2012, caused more harm than good. Luckily MS got it fixed and re-​released it nine days later. The current version of the patch does NOT have the problem, and can be installed over the original release to fix the problem caused by the original.

Kudos to Microsoft for fixing it quickly and including interested outside parties in testing it. I was able to seed Extensis tech support manager Romeo Fahl with the fixed patch, so we participated in helping verify it worked.

WHAT THE BAD PATCH DID

(1) installing the update breaks some very tiny number of fonts at the system level and for all apps, including potentially malicious fonts. That’s what it was supposed to do. BUT ALSO….

(2) with the original version of the update, for certain apps text set in all PostScript Type 1 (.pfb/.pfm) and OpenType CFF (.oft) fonts became invisible. This can even affect font menus when the app has a WYSIWYG font menu.

FIXING THE PROBLEM

Installing the revised version (2.0) of the patch from Microsoft will fix the problem caused by the original release.

If your computer is part of a domain administered centrally by an IT team, you should alert them that the issue is fixed, so they can decide whether to roll it out now that the patch is safer.

 

PROGRAMMER DETAILS

The apps that were especially affected are those that use the GetGlyphOutline() API to grab font outlines of PostScript fonts (both Type 1 pfb/​pfm fonts, and OpenType CFF .otf fonts). With the bad version of the patch, that API no longer returned the memory size needed to get the curves, but instead returned a bogus value of zero. This effectively renders some apps unable to render the glyph on screen. At least, at 15 points and higher.
I gather there are other APIs apps can use, but that GetGlyphOutline() works all the way back to XP, unlike the alternatives.

AFFECTED OS VERSIONS AND SOFTWARE

I strongly suspect that in many more applications than those listed, “convert to curves” functions will fail or result in lost text. I also suspect that in most cases where a current version of an application is affected, so are older versions not listed. What we know is that affected OSes and apps included:

• Windows: All desktop and server versions of Windows from XP to Windows 8, it seems.
• PowerPoint, but only in presentation mode (an especially dangerous failure, as a user might think things were fine… until they tried to do an actual presentation)
• QuarkXPress 7, 8, 9.5 (but only affects fonts at 15 pts and larger)
• CorelDRAW X3 to X6. Workaround: view in “draft” mode works because it does not use the problematic API.
• Serif PagePlus
• Adobe Flash (authoring at least, probably not the running of Flash apps?)
• Flexi and SignLab (signmaking apps)
• Avid Marquee (video titling)
• Bentley MicroStation (CAD /​ information modeling)
• The Secret World (Alternate Reality Game)
• Inkscape (vector drawing)
• Xara Designer Pro X (vector drawing) and possibly other Xara apps

MICROSOFT RESPONSE
The MS Knowledgebase article has a standard section for “known issues.” On Friday Dec 14, 2012, Microsoft updated it to read: “We are aware of issues related to OpenType Font (OTF) rendering in applications such as PowerPoint on affected versions of Windows that occur after this security update is applied. We are currently investigating these issues and will take appropriate action to address the known issues.”
On Thursday, Dec 20, 2012, Microsoft released version 2.0 of the patch that fixes the problems in the original. The “known issues” section now reads: “The original version of security update 2753842 had an issue related to OpenType Font (OTF) rendering in applications such as PowerPoint on affected versions of Windows. This issue was resolved in the version of this security update that was rereleased on December 20, 2012.”

Boing Boing Redesign Uncovers Web Font Ignorance »

People keep on sending me links to this article  “Boing Boing’s Redesign Uncovers Dark Side of Web Fonts,” about problems Boing Boing had with their new web font implementation. Only thing is, the article has a substantial dose of nonsense mixed in with the perfectly good analysis. I don’t blame the writer, though. This web font stuff is actually really complicated, and information has been hard to come by. Heck, I even briefly forgot a basic point in a first pass at this article. But nonetheless, I am fairly sure that Boing Boing could have fixed their problems easily, if they knew how. Here’s the story:

WHAT HAPPENED

The background here is that there are new ways of using fonts with web sites, and Boing Boing tried the simplest approach of just hosting a free font on their own web server and pointing at it, but the on-​screen results were not as good as expected.

“…the font it settled on — specifically BPreplay — ended up looking terrible for most users.”

“The result was hordes of angry Boing Boing fans complaining that the new headline font was “ugly,” “an abomination” and “plain nasty.” Of course, the culprit wasn’t really the font, but rather how different it looked depending on which browser and operating system the viewer was using.”

FINDING THE CULPRIT?

This is where things get tricky. I will update this post as I learn more. But, as best as I can tell, if that link to the font is right, and the font wasn’t modified by Boing Boing, the culprit really was in large part the font. But first let’s follow the trail of the previous article and make some corrections….

“The problem is that while modern browsers, like the latest versions of Safari, Firefox, Opera and Google Chrome, all support @font-face, the Windows XP operating system often doesn’t have anti-​aliasing turned on by default.”

Not true. Anti-​aliasing is on by default in XP. What isn’t usually on by default in XP is ClearType, Microsoft’s enhanced anti-​aliasing for LCD screens. Sometimes a computer vendor will turn ClearType on for the computers they sell (particularly if they are laptops or come with an LCD monitor).

But what makes this even less meaningful is that (again assuming the linked font is the right one), the font in question is in OpenType CFF format. Such fonts are always anti-​aliased in XP, even if you turn off anti-aliasing—the setting change only affects TrueType fonts. Even ClearType doesn’t affect how these fonts are rendered (rasterized) in web browsers, either. Same thing in Vista, and as far as I know in Windows 7 as well.

“The rule, which is still part of CSS3’s draft specification, is also not supported by any version of Internet Explorer. So, as cool as your font might look when properly anti-​aliased, on Windows XP it looks, as Rob Beschizza, head of Boing Boing’s redesign puts it, ‘like ass.’”

I’m not sure how those two sentences are related. That’s a mystery to me. XP can get good anti-​aliasing as well as Vista, and Internet Explorer is bundled with Vista and Windows 7 as much as with XP. But even taking those points separately….

The @font-face rule was actually in CSS 2 way back when, and removed in CSS 2.1. Internet Explorer has supported @font-face in every version from IE 4 to the current IE 8, but the catch is they support it only with Microsoft’s “.eot” font format (a wrapper around a TrueType font), not with regular desktop fonts. But there’s a good reason for not supporting regular desktop fonts directly: font vendors mostly won’t license their fonts to be stuck “naked” on web servers without any additional protections. Sure, there are free fonts, but, well, we’ll talk about those in a few minutes.

If Boing Boing simply put up the naked .otf font file, and didn’t do anything for Internet Explorer users (and people running older versions of other browsers), then what font actually got displayed to those users would depend on what Boing Boing specified as the fallback fonts and whether the people actually had those fonts (and thanks to Ben Kiel for reminding me of this in passing). Now, if the fallback stack relied on fonts that most XP users would not have, but Vista users would, then there might be a difference that was at least partly based on operating system. But of course it would simply be up to the folks constructing the CSS for the web site to pick reasonable fallback fonts, and not really the fault of the operating system. Perhaps as a first-​level fallback from their desired font they specified one of the so-​called “ClearType fonts” such as Calibri or Corbel, which are bundled with Windows Vista and Office 2007. Not quite right to blame XP for not having the font, but that would explain how somebody could mislabel it as an XP-​specific problem.

Other than that, whether you are using Windows XP or not has little to do with whether or not the font looks “like ass.” Turning on ClearType can further improve rendering for fonts with TrueType outlines, but would have no effect on this particular font. Being on Vista instead of XP would make no difference at all for any web browser rendering OpenType CFF fonts such as this one.

Side note: The font wouldn’t even be seen in Internet Explorer, because Boing Boing didn’t use its .eot format as far as I know. Any further problems in IE would then be due to a poorly-​specified font fallback stack in the CSS. However, if they had used .eot and TrueType outlines…. Although XP has ClearType off by default, newer versions of Internet Explorer turn it on just for the browser, so there isn’t much difference between IE rendering of TrueType fonts between XP and Vista.

In researching what went wrong, it doesn’t help that Boing Boing backed off from the font change part of their redesign, so we can’t look at it and test it. Looking at this screenshot, however, shows pretty clearly what was going on. This screen capture was definitely taken on Windows, and the font in question is still anti-​aliased. However, it has some pretty crappy artifacts in how it’s rendered on screen, at least some of which are related to it being unhinted. When I see things like a single pixel sticking out of the bottom of a round shaped letter, that’s a dead give-​away that the problem is likely hinting (or more accurately, lack thereof).

“Hinting” is essentially extra code in the font that improves its rendering at screen resolution. Apple’s rendering approach largely ignores hinting, but Microsoft’s rendering still uses it a fair bit. Passable hinting can be done automatically by font editing tools, so there’s no real excuse for leaving it out of a font (as with this one). In fact, pretty much every commercial font on the planet is hinted, as are most free fonts. But this isn’t even an average free font. Yes, the terrible spacing is pretty typical for free fonts, but being unhinted is uncommon. Maybe it was converted by somebody else.

Bottom line: the font sucks. This should not be a surprise. Most free fonts do. Don’t get me wrong. There are a few great free fonts out there. But 98% of free fonts suck badly, and maybe about 20% of typically-​priced retail fonts suck badly, so set your expectations appropriately.

THE “DIRTY LITTLE SECRET”

But there’s another problem that might have led to complaints and concerns even if the font was made decently, but still in the same format. The “dirty little secret” of the font world is this: Windows GDI rendering of OpenType CFF and “PostScript” Type 1 fonts on screen just sucks, compared to its rendering of TrueType fonts.

Typophiles have long ignored this fact, because in the environments they’ve cared about, Type 1 and OpenType CFF fonts render perfectly well on screen:

• Just about any application on the Mac OS.
• Adobe Acrobat, InDesign and Illustrator, on any platform.

Unfortunately, Windows GDI rendering is what 90% of people see in web browsers and office applications today. (Yes, Safari for Windows also has the option to use its own rendering system, but that’s a tiny minority.) Internet Explorer sidesteps the problem simply by not supporting OpenType CFF fonts in .eot format, only TrueType (though one can convert). But it’s not like .eot ever caught on with web designers, anyway.

The future could improve. There is much better OpenType CFF rendering, even applying ClearType, available for applications using Windows Presentation Foundation and  DirectWrite, but very few applications use these modes today, so it is sadly not very relevant… yet. My recollection is that the technical preview of Office 2010 for Windows has dramatically better rendering of OpenType CFF, so perhaps it is coming. Maybe Internet Explorer 9 will get there too, supporting both outline formats in .eot or some new web font format. Perhaps in five years decent support for OpenType CFF rasterization on screen will have reached the strong majority of web browsers….

CONCLUSION

So for me it’s a toss-​up as to whether I blame Windows GDI rendering, or the fact that Boing Boing used a crappy free font (BPreplay) because they couldn’t legally use the retail font they wanted to (VAG Rounded). My first take is that I think Windows GDI just made worse something that would have been a problem anyway. Somebody who knows what they’re doing could spend ten minutes and either fix the font’s hinting in BPreplay or convert it to the TrueType flavor of OpenType—if the license permits it, I’d be happy to try either for them. But then again, maybe the complaint is more about the fallback font, a factor easily controlled by the web site author.

So yes there are some pitfalls. Obviously things would be better if one format worked across all browsers. But there’s also the question of whether one can use the fonts one wants, which tripped up the Boing Boing folks. What happens with that depends on what font vendors decide to do with the fonts they control the licensing for; many foundries are still trying to figure out how to approach the web fonts conundrum. Will they license fonts for use on web servers directly? Will they do so but specify security requirements that can’t be met by sticking regular desktop fonts on web servers, meaning that we’ll have to wait for new web font formats to be widely adopted, such as WOFF? Will they instead rely on a font serving process that involves something centralized, either run by themselves, or by a third party (such as TypeKit or Kernest)?

How exactly this will play out is still TBD today. What I do know for certain is that within a few years, web fonts will be a reality for the average viewer and the average web site. Many or even most web sites will pick specific fonts that aren’t necessarily already on the viewing computer, and those fonts will get used to display the desired text. Font selection will become part of branding for the web the way it has been in print. We’ll also get an explosion of awful font choices on web sites, particularly small personal ones, much like when the masses first got access to a wide variety of fonts they could print on their home computers. But overall, it will be a Good Thing, and I relish the thought of a more typographically rich web world in a year or three.

[Updated for minor clarifications 2009-​10-​12, reformatted 2009-​10-​13, added a bit on font fallback 2009-10-13]

Greek Support in Fonts: Truth & Lies »

A recent thread over on Typophile prompts me to explain why one sometimes sees OpenType CFF fonts that don’t actually support Greek, claiming that they do (by means of the Unicode Range and Codepage bit settings).

Originally, when Adobe converted the Adobe Type Library to OpenType, in the early stages we were thinking we wanted to be as compatible as possible with the Type 1 versions of the fonts.

In the absence of codepage bits and the like in Type 1 fonts, Windows GDI used to do a test for specific codepoints in the font to determine whether given codepages were supported, I believe one codepoint per codepage. I believe the codepoint to determine Greek support was the one for the “mu”… but it was definitely a test for a character that was present in the basic ISO-​Adobe character set (now Adobe Latin 1). This even though the character set didn’t really support Greek, it just had a few Greek characters because of their use as math symbols.

So, the Type 1 fonts were (arguably erroneously) detected as supporting Greek by GDI. The idea at the time was that the OpenType fonts with the equivalent character set should behave the exact same way, and therefore the determination of whether to give them the flag saying they support the Greek codepage should be based on the same test… so basically all the fonts would claim to support Greek, even though they really didn’t.

Somehow, even though the idea of near-​perfect compatibility between the OpenType fonts and their Type 1 predecessors was abandoned, this principle stuck during the initial conversion of the Adobe Type Library (“Alchemy”). Unicode ranges were set more-​or-​less in compatibility. Additionally, the AFDKO “makeOTF” tool used to build fonts would automatically do this, unless specifically over-​ridden. So you could see third-​party fonts doing this as well if they were made with older versions of Adobe tools.

I thought this was a mistake, and eventually convinced other folks of my opinion, so this decision was changed in the revision of the Adobe Type Library (“Facelift”) a couple of years ago, released about October 2007. The AFDKO was changes as well, to match this new preferred behavior.

So, you’ll find that the 1.x version of Adobe Caslon Pro built in 2001 has bits set to claim it supports the Windows Greek codepage and the Greek Unicode range, but this claim was dropped in the 2.0 version of 2007.

Video: OpenType, cross-​app text, Flash, etc. »

Worst Presentation EVAR

I almost didn’t blog about this, because it was probably the most messed-​up presentation I’ve done in the last many years. I was trying to do a PDF-​based presentation interleaved with a demo in InDesign, but my keyboard stopped working completely when I was in full-​screen mode in Acrobat… meaning I also had no way to get out of Acrobat to do the demo! So I had to reboot, re-​order my presentation on the fly, and improvise talking through from memory some stuff I had intended to do with accompanying slides, while waiting for my computer to complete the reboot and then for InDesign to launch (which last took 3x as long because I had rebooted while it was running). I also had a cold, so I am clearing my throat every 30 seconds. On top of that, the guy doing the presentation in the next room was REALLY LOUD and somehow his presentation included loud heavy metal music…. Which you can’t hear it on the recording, but I and the audience could hear it very clearly, and it was seriously distracting. Aaargh!

All of which threw me off my pace a bit, even if I seem to be handling it with aplomb on the recording. So even after I’m out of the part where my computer is totally hosed, I’m not at my best.

That being said there’s still some decent stuff in several spots of this AdobeTV recording from Adobe MAX, November 2008. See below for key bits to watch:

• Preserving OpenType alternate glyphs across apps: 5:25 – 8:20 (audio only)
• OpenType typography features: 13:30 – 35:40 (video)

• Just don’t expect me to be at my scintillating best on this one, okay?

  Share this:

  • Email
  • Print
  • Twitter
  • Facebook
  • More

  • Reddit
  • LinkedIn
  • Pocket
  • Tumblr
  • Pinterest