Welcome to Typophile Idris.
At the moment, only professional design programs support most of the opentype features. This covers the high end users tools fairly well but the typical word processor user will have a bit longer to wait. Depending on how much you believe the dates developers give you, somewhere around a year or so should bring OTF to the main stream.
Opentype will, in my opinion be around much longer than MM. If it goes away, I am sure it will be supported in whatever comes after.
Opentype does such a much better job than TT or Type 1 in supporting large character sets that it is hard to resist. This is a major boon to non-Latin scripts which need full coverage to be workable. The contextual options and attention to diacritics help even more.

You can search here, on the Microsoft site, and the Adobe site for many discussions on Opentype features and problems.

I hope you will continue to share your views and findings here in the Typophile community.

ChrisL

Hello! Some first links:

Despite its title, the thread http://typophile.com/node/16695 is about the OpenType font format and differences between CFF vs TT flavored OTFs.

It the above thread, there is also reference to http://blogs.adobe.com/typblography
where you can find three articles:

"Phasing out PostScript Type 1 fonts" at http://blogs.adobe.com/typblography/2005/10/phasing_out_typ.html,

"Increased expectations & OT font glyph sets" at http://blogs.adobe.com/typblography/2005/10/increased_expec_1.html

"Great Customer Expectations for OpenType" at http://blogs.adobe.com/typblography/2005/11/great_expectati.html.

These, including subsequent discussions, cover many aspects like phasing out of PS T1 and MM, or (meager) support of OTF by typesetting applications.

Best wishes, Karsten.

Someone has pointed out (I can't remember who) that OpenType is already much more successful than Multiple Masters ever was. There were only a small number of MM fonts built, mostly by Adobe, and you needed ATM to use them.

There are already thousands of OT fonts on the market by multiple vendors and they have OS-level support on both Windows and Mac (and Linux too I think). Application support is good (mostly Adobe for advanced typographic support, Microsoft for non-Roman script support) and getting better--the next version of Quark will rival the support you see in Adobe's offerings. Add to this the fact that there is one format for all platforms, something that was never true of earlier formats. I can't imagine how OpenType will do anything but become more widely embraced, given all it's advantages and support by the major OS/application players.

This was never true of MM, even though it was pretty neat.

for more insight on file types (including OpenType and the different flavors of OpenType fonts) see this thread called TrueType versus PostScript.

Thank you all for your very valuable comments. Someone also forwarded me the following:

http://www.opentype.com/html/opentype.aspx

It has some charts illustrating the degree of OpenType support in various applications...

Was disappointed to learn (from other references) that even InDesign is quite limited in its support of multilingual otf's...

Best
Idris

accidental post-)

This is my own principal critique of OpenType, and it is not a critique of the font format but of OpenType Layout. A lot of the OTL features were defined by Adobe and Microsoft long before either company implemented support for them in any products, and I don't think we've been left with the best set of features we could have had. Of course, it is possible to define new features, but what already exists has determined application functionality and it would now be difficult to revise the whole model.

At the moment we have some features that are identified as being on by default but possible to turn off (e.g. liga), some features that are off by default but possible to turn on (e.g. dlig), and some features that are on by default and impossible to turn off (e.g. rlig). The distinction between standard and discretionary ligatures is a useful one, but I don't think that it is useful to have a feature level distinction between ligatures that are always on and ligatures that are on by default but can be turned off; that is, I do not think this is a distinction that requires two separate features. I also find myself longing for an equivalent of the 'required' state of rlig lookups for other features. So I think it would be better for there to be a flag in the lookup that determines whether particular lookups within a feature, e.g. liga, are required or not, i.e. can be switched off or not. This would be a basic aspect of the GSUB and GPOS lookup types, rather than something that requires multiple features, and a single feature could include both required and non-required lookups. Some features, such as ccmp and locl, might still be presumed by applications and engines to be required, and no UI would be provided to turn them off, but it would be possible to include some required lookups within the features that users can toggle. So, for example, rather than splitting your Arabic ligatures between the rlig and liga features, you would put them all in a single feature and set the appropriate flags for individual lookups. I'm working on a project at the moment in which it would be useful to be able to mix required and non-required lookups in the 'calt' feature, because there are some cross-stylistic-set glyph combinations that could occur that are simply incorrect, ugly and colliding. I should be able to ensure that these do not occur while still allowing the user to turn off contextual alternates if this does not result in such combinations.

As to whether OpenType will go the way of Multiple Master, no, I don't think so. But I think some poorly conceived OTL features will never be implemented, and may be formally deprecated, e.g. the 'rand' feature.

It has some charts illustrating the degree of OpenType support in various applications…

Not very accurate or uptodate. There is no mention of Adobe's ME or J products, which have much advanced multilingual support. The chart says the multilingual support in Word on Windows is limited to TTFs, but I have made CFF complex script fonts (Arabic, Adobe and Thai) that work fine in MS Office 2003 on Windows.

John,

I agree with you that set of features registered in OpenType spec is not ideal. I also agree that feature descriptions are confusing sometimes because they are largely a mix of requirements/recommendations/hints for app/font devlopers without clear indication of what is what.

But I do not agree with your method of solving inconsistencies in feature set by introducing new concept of required and not-required lookups within a single feature. Not because it will require changing all implementations
of OpenType layout in the world :). It is not actually many features that will require both required and not-required lookups. 'liga', 'calt', 'kern' - what else? I do not see it is worth to introduce new concept in OpenType layout format. This concept may be very confusing and hard to define behavior for - basically, for the same reasons why we do not recommend using required feature now.

Your approach may be useful in tools, though. Particular tool may provide a feature that will assign "required" lookups from one feature tag to some other (if tool is smart about relations between features). But it is not about OpenType layout specification.

Thanks,
Sergey

OT is lacking or deficient in the following:
1. It is missing variations, MM or ANY KIND. All styles are descrete outlines and that's just so 1980's. Size axis are cut off, and resolution axis, sheesh, they don't even know what you're talking about.
2. OT relies on the old TT composite method, which combines bitmaps after they have been rendered to bits, (too late for combinatorial hints.).
3. OT as John Points out, the features are limited by Adobe's and MS's desire/footprint. But the real bummer is that the UI hooks to these features are "hardwired" into app(s), so the end of spreadable creativity in this area comes up pretty fast. I.E. An update is required so that the feature tables include the UI names of features, so they can be passed directly thru apps. to users.
4. There are no options for encrypting anything, so all of your work goes public. when you publish it.
5. And the worst thing about OT? The format is privately held by companies who are overwhealmingly not type founders so it's inevitable that the format would be cast with second-rate concepts, by inexpert technocrats, into very solid concrete.

>The format is privately held by companies who are...

Not for long - http://www.microsoft.com/typography/links/news.aspx?NID=5033

"Not for long - http://www.microsoft.com/typography/links/news.aspx?NID=5033"

Oh good, one down (mylist), 4 to go. But, Merry Christmas! here's your font standard(s!) for the next XX years, we know it's incomplete, (made so by the inability of technocrats to maintain momentum in type technology), but if you want a better one you'll need to wait for some.gov/ubertoolmaker.com to fix it? Or is someone gonna have to start from scratch and sue their way to completion of a new format? Either way, the (my) "western" notion of continual progress is not being served. If Anyone Else who has benefited from the 1984-92 burst of typographic technology is "man" enough to continue that progress on the $100's of millions earned from the incorporation of technology others invented and developed to fruition, please stand up. (grimface)

What do people here think of SIL's Graphite? It appears to be especially strong for complex scripts, but so far doesn't seem to have caught on much.

What do people here think of SIL’s Graphite?

An interesting approach. I prefer something like what we do in the TeX/Omega/Aleph world: filters which select font features and which the user loads at will. I have been playing with Arabic Typesetting (arabtype.ttf: MSOffice 2003 proofing tools or Windows Vista) and, in MSWord at least, the features are set in stone. (Caveat: I don't use Word for typesetting; maybe there is a way to select/change desired font features that I could not find.)

For example:

i. Turn ligatures on/off;

ii. Have a choice of ligature sets. For example, at small point sizes certain ligatures don't work well. The typesetter should be able to choose which ligature set works best for the task at hand.

iii. Turn vowelization on/off, perhaps even control diacritic-vowel positioning;

iv. Alternate character control;

Other features, like character substitution based on interword spacing within a paragraph, require a better typesetting engine, like TeX or InDesign (which uses TeX's h&j algorithm, but I have no idea if this feature is available in InDesign; have not yet had the opportunity to use that program).***

To summarize: For advanced typography and typesetting of complex scripts, opentype alone will not do (from what I have learned so far). A postprocessor engine that gives the user more control over font features in a variety of contexts is needed. The font format itself should provide "hooks" (like anchor points for a given feature in otf) from which the postprocessor then creates a myriad of typographic possibilities.

Happy Holidays
Idris

*** I have noticed that Donald Knuth is rarely given the credit deserved for the h&j algorithm. Even Bringhurst (e.g., p.191) seems to go out of his way to avoid mentioning TeX...

PS

I was pleasantly surprised to see that arabtype.ttf apparently works in OpenOffice2.0, even the cursive attachment features!

I have been playing with Arabic Typesetting (arabtype.ttf: MSOffice 2003 proofing tools or Windows Vista) and, in MSWord at least, the features are set in stone.

To be fair, this is a limitation of Word, not of the font format. There is a good deal more feature flexibility and UI options in the Middle East version of Adobe InDesign, but no support for the attachment feature. Arabic typography support is currently caught between the varying priorities of the application developers, but this should be resolved over the next couple of years.

By the way, Idris, this may be of interest to you: www.kitabat.org

I think many (though not all) of the criticisms of OpenType made here are valid and reasonable. However, there are a couple of things worth keeping in mind:

A) Even if it's imperfect, OpenType is a huge advance over plain old Type 1 and TrueType.

B) It's a huge amount of work to develop a font format, and a font format needs support from OS and application developers. The only reasonable alternative to having OS and app developers do it themselves is a consortium or standards body - which is where OpenType is moving anyway. Font developers can't do it by themselves.

C) It's also a huge amount of work to do all the support infrastructure for a font format, especially the layout stuff in apps/OSes, the tools, and so forth. This infrastructure stuff is like a huge ship - it turns very slowly when it needs to make a course correction. This means that any new format takes years to get everything in place and iron out the kinks and bugs in the support.
TrueType had a slightly rough start back in the early 90s, and that tainted it for over a decade in the eyes of the professional publishing industry. Type 1 MM never got wide application support (I'm the one who pointed out that we had more active OpenType support in applications before shipping any fonts than we had for MM when we stopped making new ones). OpenType has had a fine start, but it's taken quite a few years to get to where we are now, and we're still not quite "there" yet - though we're close.

So, I think that all of these factors mean that the costs and difficulty of trying to change directions to "something else" are pretty large. Is it worth waiting another 5-10 years, and scrapping and re-doing the existing infrastructure investment?

Comments on a few specific things:

> 1. It is missing variations, MM or ANY KIND. All styles are descrete outlines and that’s just so 1980’s. Size axis are cut off, and resolution axis, sheesh, they don’t even know what you’re talking about.

Yes. Unfortunately, our experience with MMs was that applications were not very interested, and users did not easily "get it." Of course, one could put this down to insufficient evangelism (my own explanation of it).

> 3. OT as John Points out, the features are limited by Adobe’s and MS’s desire/footprint.

Well, although the existing spec has accepted a number of proposals from other parties, it's now becoming an open standard so this won't be true in the future, if it ever was.

> But the real bummer is that the UI hooks to these features are “hardwired” into app(s), so the end of spreadable creativity in this area comes up pretty fast. I.E. An update is required so that the feature tables include the UI names of features, so they can be passed directly thru apps. to users.

In a global environment, the choice is one between having the feature names hardwired into the applications, or saying that the font developers are responsible for translating the feature names into all possible languages. If you come up with a new feature, are you up for translating its name into every single language supported in the Mac and Windows UIs? I know I'm not....

> 4. There are no options for encrypting anything, so all of your work goes public. when you publish it.

It's possible to stick an encryption mechanism on top of any font format, including OpenType. I know that some Asian font developers have used PACE technology (http://www.paceap.com) to do encrypted OpenType fonts on Mac OS. Not sure if their Windows stuff will do fonts as well, could be.

That being said, I think that encrypted fonts that are tied to a user's computer are a bad idea for a whole bunch of reasons. But that's another topic.

Cheers,

T

>the font developers are responsible for translating the feature names into all possible languages.

It would be nice if the OpenType format supported "developer's naming" for stylistic alternates, which would also be supported by layout apps. Give developers the choice to translate their feature names or not.

Failing that, developers can always do a special font for a special feature. For instance, "Caslon Historic" could implement historical forms as an always-on contextual alternate; the feature is a legitimate OT feature, but is not AFAIK supported by any layout apps.

In fact, the OT feature tag definition of Contextual Alternate is somewhat one-dimensional (something about scripts) for what its actual capabilities are.

"If you come up with a new feature, are you up for translating its name into every single language supported in the Mac and Windows UIs?"

Apparent Reasoning: "if Adobe Doesn't want to do it, (translate features into UMPTEEN languages), then why would anyone want to do anything at all about the issue?" Answer, they wouldn't, I wouldn't. I'd call it "Cap Figures", it'd pass through the suddenly genius app, and the user would see it "Cap Figures". . . I'm not trying to please the whole world, just a few endowed customers. The rest of the wolrd would never even need to know that Adobe was doing the right thing.

"That being said, I think that encrypted fonts that are tied to a user’s computer are a bad idea for a whole bunch of reasons"

Reasoning: "The only way to implement encryption will make all customers unhappy." Adobe did it that way, released encrypted fonts as Retail Products...but that does not mean Encrypted fonts do not have a huge audience of customers who simply do not want their fonts wandering off with every change of Art Director. And, NO ONE is holding a gun to either the founders or the buyers head to make or use Encrypted fonts. It is called a choice...heard of that have you? Only the people who wanted it would ever need to know it existed...

Problem: MS, Adobe, and Apple seem unable to see type in the Bigger Picture.
A technical plateau, now, 14 years old, is not a good thing.

"Is it worth waiting another 5-10 years, and scrapping and re-doing the existing infrastructure investment?"

ALL of crit points I made are font format issues in the hands of OS font management software. Apps, would need to make zero changes, or just erase code and turn it over to the right authority, the OS...That has been the No.1 issue from DAY ! of OpenType, pka TT Open. Adobe has no OS, so it wanders back and forth. Apple and MS could not work out a way to share what they share, and MS STILL doesn't have OT implemented at OS level, despire warnings that implementing App by App for "competitive reasons" was just plain bone headed, YOU HEAR ME SHAMEN? ;)

And variations, well, I guess that's just "too hard," it's much easier to toss a thousand fonts into a menu and let the user swim, or sink.

dream format: multimaster opentype fonts.

hmmm i kinda like that i just called multiple master multimaster, heh.

dream format: multi[ple]master opentype fonts.

I was a bit disheartened by something Erik Blokland communicated to me:

MM in itself can do a lot, but only when administered by skilled Adobe engineers. In FontLab the highest goals are much more mundane.

Could one of you explain this in more detail?

Happy New Year

Erik is likely referring to the intermediate masters technology employed by Adobe for a small number of their later MM families (Adobe Jenson and Kepler, I believe, but I'm not sure about others). David Lemon at Adobe described to me their attempt to model the Kepler design space: it sounded like a cross between Frick and Watson's famous DNA model and a Kalder mobile, with sixteen primary masters and intermediate masters between some of them. FontLab only supports primary master interpolation (but as a design tool it also supports extrapolation, thanks to Adam Twardoch, which is a nice feature that MM didn't have).

MM are Junk, were junk and will always be junk, next to 64 potential axis, 64 potential intermediates per axis, of TT variations. AND! the ease of development (for normal everyday designers) that were presented by variations technology in combination with Mutator and Fog...was simple as pi. Anyone who ever made a TT variation and MM font knows what I'm talking about. Everyone else is in le dark. MM was, for those of us who did both, like trying to control a puppet's mouth with strings attached only to its arms and legs. Variations allowed strings for each tooth, if ya wanted. Erik's work is to make variations again, of which MM is always, and only, a subset.

David, could you please explain how you use Mutator? Manipulating outlines is straightforward, but when you try to save the changes, Mutator crashes. I'd appreciate it if you could help me to solve this problem.

GX/AAT Variations are great fonts. Zycon, Jam, Chunk and Buffalo Gal show the amazing things that can be done with a font outline. Skia looks good and for layout work and logo design, its condensed and extended variations provide useful options.

If creating GX/AAT or MM variations was easy, more designers would have built their own variations fonts, but it's not and most people probably give up in frustration.

If Adobe's MM fonts are not counted, only a handful of MM fonts have been released since the format's introduction in the early 1990s.

To my knowledge, apart from the fonts that were commissioned by Apple, no GX/AAT variations fonts have been released.

Designers do use MM and variations; my local council's logo was nicely redesigned in Skia Condensed. Sadly, OSX does not make it easy to use MM and AAT variations. The OS supports the format, but in OS 10.4, few applications display the variations sliders.

After giving up the battle to create a variations font in Mutator, I reluctantly decided to create a Multiple Master font instead. After much fiddling with point directions, obscure error messages, baffling dialogue boxes and inadequate documentation, I eventually managed to build a MM font in FOG. It worked, but the process could have been much easier. The Type 1 format doesn't allow for special characters like ligatures and swashes, so for me, a GX Variations font similar to Skia would have been a better solution.

Creating GX/AAT substitutions with the classic Apple Font Tools is relatively straightforward, but the newer OSX Unix command-line tools are beyond me. I suppose I'll get it, eventually, but why have the techniques become harder? Is this progress? The documentation, which seems to be written by programmers for programmers, may be ideal for engineers, who have the training and aptitude, but the people who really use fonts—graphic designers, illustrators, etc—are expected to wade through page after page of academic theory and PR which describes the amazing things the technology can do. I don't want to be told what's theoretically possible; I want to know how to do it! In an ideal world, designers would figure it out for themselves, but in the real world, they don't.

Finally about OpenType; at the moment, the OT format is too messy. The specification needs to be finalised and all the features built into the operating systems. After that, the various platforms and OS' must be compatible. After that, users need a font tool that enables OT features to be specified without lots of coding. I wonder if this Nirvana will ever happen?

After that, users need a font tool that enables OT features to be specified without lots of coding.

VOLT. Zero coding. All visual. Of course, if you want to edit the background lookup syntax you can, but for the most part the only things you need to type are glyph names, numbers, and the occassional ->

"David, could you please explain how you use Mutator"
Not really. I mean, I can flap on about drawing a style and drawing another style with identical points, and then about making an axis, assigning its granularity, and then about outputting polations of various kinds, editing them and re-vacuforming them, but...Apple does not support Mutator, in fact, they revised the application ('99 or '00 I think), not to work, or at least since their revision it has not worked for me or anyone I know. Beating a dead horse comes to mind.

The only way these things will be put into a future font standard, is if all three companies suddenly wake up, realize they are in old mud, and TOGETHER, plan a better future for type. That, for the last ten years, has seemed to me like illuminating a black dog on a dark night, knowing that the dog is there, and trying to get other people to see it.

"TrueType had a slightly rough start back in the early 90s, and that tainted it for over a decade in the eyes of the professional publishing industry."

ollol ...I think that's one point of view.

Another, would be that "Font Wars" occurred because Adobe went 1-r-2 negotiations too far in trying to have a monopoly on Type and Page Descriptions, and... Interpreters ;). Apple developed TT and offered it to MS with nice binding provisions. Then, Apple and Adobe Agreed that Apple wouldn't use no stinkin' PS Clone, and Adobe Would put TT into Its interpreters. So, peace came to the foundries, and OS...but, because MS and Apple Didn't bind, and Adobe Didn't really let TT in for a while, the war damages moved to the users where they continue in a lingering fester of occasional mishaps, like Courier ending up in an airport poster, with really bad spacing, like, it was substituted.

Another, completely different point of view, would be that Adobe had a very narrow sense of quality in type — high quality for print and 300 dpi, only. TT came along and offered both Higher and Lower, in addition to High Quality type. This caused great, and to me hilarious, consternation. Still does. But at the time, unfortunately, decisions were being made about type on the web, and based on one format being incapable of delivering web quality type, and the tainted quality of TT, we got the web all the way up to proportional bitmaps as good as a typewriter of no particular distinction, in no time flat. ;)

I don't mean to pick you at all Thomas, its three whole companies and their imagination-free trudge on, head down, devotees.

Before anyone else outside of Microsoft had the right to VOLT, FB made the right stuff available in fonts for customers who wanted future OT compatibility. We as a company, and I as me, are/is — all for, all formats, all the time. Being without sin on this issue,, I'm left with the obligation to throw rocks. :) We (founders), have Got enough sticks: broad character sets, a plethora of rasterizers (2 being 2/3 of a plethora in this case), a resolution range from here to kingdom dumb (can you do 7 ppm?), not to mention the moving target of fashion and We also have to erase a barrier that divides us from users: where we do more of their composition, and they put better butter in the fridge, as directly as possible, if not in person. Where, exactly are the carrots?

"for the most part the only things you need to type are glyph names, numbers, and the occassional ->"

Wow! I can't wait to define glyph substitutions myself! I sounds so...fulfilling. It could possibly mint thousands of new type designers with all the skills of a ...typist.

We really do need a higher standard, shared by ALLLLLLLLLLLLLL, that allows even higher quality and even lower quality, even more functionality and even less functionality, than the "modern" formats. Scary? Big Deal, The things I list for additions to a new font format are enough to directly and indirectly cause universal employment, at least. Otherwise, we're letting the 15th anniversary year of the "peace(s)" slide by, and you're indicating that a "consortium" of some sort is going to cast the current plateau of rather inflexible and tainted technologies into broader standardage than it already is? ...sounds like old fish stew with fresh greens.

David,

Do you see UFO/RoboFab as a step in the right direction?

Uh oh! David you left the volume up on this thing.

Ah, but I bet I can turn it down.

But I can also go back to one of my earlier posts and really mess with the formatting. It this a bug of a feature?

John, I went back and closed David's bold tag… but your funky italic thing is from two weeks ago. Can you edit your post and turn it off, or do I have to go hunting through the archives for you? ;-)

I would have happily done so, Dan, but it looks like you found it. I was disappointed that the 'code' tag only applies to single paragraphs :)

John hacks his own font for posting :-)

ChrisL

Apparently through Georgia, John's happiness can't be expressed fully. ; )

"Do you see UFO/RoboFab as a step in the right direction?"

Yes. In this way, all of the functionality that should be in the font format can at least be in the tools. Unfortunately, this will not help Adobe, e.g. to stop putting hundreds of extra characters e.g. the many accented "ass" (that's a.s.s. to sidestep the typocensors ) ligatures into fonts, nor will it get indigenous complex Arabic type going or stop the Chinese from making the improvements they need to make the format they want. So we're stuck with 3 American cos. sitting sweetly upon their hands, blaming the size of the ship for its inability to turn. On the bright, all those in need, please report to the starboard bow, we're gonna eventually make some ice.

David: How is the present state of affairs (OTF, RoboFab/UFO) deficient with respect to, e.g., getting "indigenous complex Arabic type going"?

Second question: What, in yours or others views, is a set of necessary and sufficient conditions that a font format/specification/implementaion/whatever needs in order to meet the needs of the Chinese, Arabic-script, helping Adobe with bloated character sets, etc..

This is not all merely abstract speculation: we are working on developing new approaches for TeX to deal with opentype etc., and a clear understanding of the problem and its abstract solution is important.

Best

In this way, all of the functionality that should be in the font format can at least be in the tools.

I've never been convinced that interpolation belonged in the format, whereas it is very important that it be in the tools, and the tools should not be limited by the specifics of the format. The attractive thing about Erik's superpolator is that it isn't trying to conform to a particular format's notion of masters or variations.

nor will it get indigenous complex Arabic type going

I suggest spending some time on the VOLT community website to see just how much indigenous Arabic font development is happening. A lot of it is pretty rough, some derivative, but they are definitely getting going. The largest VOLT user groups are, by far, indigenous Arabic and Indic script developers.

"The largest VOLT user groups are, by far, indigenous Arabic and Indic script developers."
Neccessity is the mother of invention.

ChrisL

David,

Maybe you could respond more specifically to what John has mentioned; I can't quite pick apart what you feel are essential components of the actual font format (suppose you enumerate what the dream format includes), and what tools you feel should be made widely available and used by type makers. I agree with John, I'm not completely sure MM or other 'mutating' font capabilities need to be delivered straight to the user. This is In the same sense that we're all spending a LOT of time hashing out how to program various complicated OT features, though the goal is still robust, intuitive, complete fonts, not mini-programs that make the user cry.

Unfortunately I don't know much about Variations, but I have a lunch date with my co-worker who I think can help explain it (Dave Opstad).

Today's NYT editorial 'Working Together for the Average Joe' criticises the electronics industry for releasing incompatible products. The writer's comments could be applied to font formats, font engines, operating systems and platforms.

The article is here;
http://www.nytimes.com/2006/01/07/opinion/07sat4.html?th&emc=th (registration necessary).

Some quotes;

"People would be willing to spend even more [on electronics goods] if the industry bothered to make their products work with one another. …companies are losing a combined $3.8 billion in estimated sales of additional products, content, and services by selling stand-alone devices and leaving consumers to make them work together or - as is more often the case - not work together. It predicts that such lost sales will rise …if things don't improve."

"Tech visionaries love to wax poetic about the networked home, straight out of the Jetsons. Maybe if you're Bill Gates. For most people, the reality is a Babel of devices and technical-support staffs that blame other companies and don't help. Computer owners have to become security experts, network specialists and troubleshooters. So people buy less."

"The rewards are rich, and first isn't always best. The iPod wasn't even close to being the earliest digital music player on the market. Now it's the leader because average people found it usable."

"Still, Apple would do well to ditch the closed-circuit approach and cooperate with other companies better - or risk repeating the mistakes of the past."

Quite… The key words are 'cooperate' and 'usable', but will the industry listen?

> The writer’s comments could be applied to font formats,

Not really. Maybe the font world isn't perfect but what other technology rolled out in the late eighties works as well as TTF or Type1 on modern computers running every major OS (Mac, Linux, Symbian, Windows, Xbox, etc.,)?

The fact that users expect old fonts to work is what's holding back the people from inventing new font formats.

Si

"what other technology rolled out in the late eighties works as well as TTF or Type1 on modern computers running every major OS (Mac, Linux, Symbian, Windows, Xbox, etc.,)?"

Condoms?

There is an old Zulu saying that comes to mind: "The good description of a big steaming pile of elephant shıt, is much better than meeting the real thing in bare feet."

"(Dave Opstad)"
Say hi for me...
"I can’t quite pick apart what you feel are essential components of the actual font format"
Please see above list?

"Maybe you could respond more specifically to what John has mentioned;"
John doesn't know what I'm talking about. But I'll try.
"I suggest spending some time on the VOLT community website"
When I'm also convinced that the millions standing in line for welfare, means "we doing a good job to end poverty" I'll do what you suggest. Meanwhile, mine eyes have seen the gory of the coming of Caflisch. This is one of the best designs I've ever seen, but whoa unto he who must maketh the light. It's also simple enough to sit and wait for our Arabic brethren to hit the wall(s) on the 4th or 15th style, no? Making connecting typography (!), with these tools and this format, regardless of script, is a loser business that only stupid, temporarily curious, or rich people can afford. Is that the way it should stay?

"I’ve never been convinced that interpolation belonged in the format,"
I know John, but you have a narrow view of what fonts are unable to do. E.g. Describing Variations as Interpolation is like describing love as sex. Try this John, Forget about variations, for style, as an attraction on a web site, or if you just want the floral ornaments in your stationary to reflect the changes in the seasons.....leave all the future behind and go back to the past (recent as that may be): Design a font to work for text and display, in high resolution and very low resolution, and for all rasterizers, in one outline... not just sayin' so, but knowing in the design and production that it will be so without even having to look, then call me and tell me what problems you had. :) Imagine, e.g. never having to say "this italic is too light for the Roman, in print, because I made it work for ClearType," or, "I chose these serifs because they work best at small sizes on the screen and larger sizes on the screen are... okay too...sort of."

Siiiiii....
"The fact that users expect old fonts to work is what’s holding back the people from inventing new font formats."

Really? So if I promise to get rid of all those lagging slugs, can we make a new format? I think not. I think MS, Apple and Adobe are users who expect old fonts to die and with a dsig here and a bunch-o-practically useless other stuff there, we'll call it a new format and that is that.

The writer's position is pretty dim.
He should go to a hardware store and try to buy a light bulb.

I don't think anyone at MS thinks that gsub and gpos are useless, but I don't think anyone at MS sees OpenType as a 'new' format, it's always been TrueType +.

David, you've described to me why variations are an attractive type design tool to address optimisation for diverse different size and resoluton conditions. I don't doubt it. But the question is whether this is something that belongs in the font format, as something shipped to the user that he is supposed to figure out how to make optimum use of with sliders or other UI options, with the caveat that only some applications may support such features? Or is it better implemented as a tool to develop discreet instances tailored to particular conditions and licensed as individual fonts?

I think font formats should be pretty simple containers into which richly developed content can be poured (and yes, I know that I've left myself open to another elephant shіt metaphor). We've seen how long it takes software developers to support OpenType Layout properly, and this is a level of additional complexity that is necessary to support most of the world's written languages in even a basic way. We could define the world's most wonderfully featured font format, that would do everything we want and do it better than OT or AAT or Graphite or ?, but if those features end up supported by one minor start-up application in a corner niche of one platform with a tiny share of the market, so what? A font format is one part of a text processing and graphical layout architecture, and it is the whole thing that needs to be overhauled, not just the font specification, which is so much virtual paper by itself.

The best and most damaging critique of the OpenType format is is level of acceptance, esp. the number of apps that implement any / a significant portion of the layout features. Being at a point where the "current" font standard is too advanced - for app writers anyways - there appears to be little point in dreaming up newer and even whackier ones. Similarily, unless there is a long queue of not yet registered new feature tags that are about to come out in a new revision of the standard the font designers are not really pushing the envelope with OpenType either.

We don't need hyperdrives - we need the trains to arrive on time.

We need the trains to arrive period.

ChrisL

"I think font formats should be pretty simple containers into which richly developed content can be poured"

Can you explain how you came to this ideal? I mean, the goal, man, is Rich Content. No!?