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!?

It seems to me that the majority of users are interested in having fonts that are relatively simple to use and which work consistently across a wide range of applications, and this ease of use and compatibility is more important, for most users, than having fonts that do lots of clever things but inconsistently and only if the user knows how to operate them properly. Having sliders to perfectly fine tune a typeface for a particular size and output configuration sounds wonderful, but you are expecting the user to have the same expertise as the type designer in determining what that optimised font should look like. It seems to me that most users would prefer to have a simple font labeled ’Use this for ten point text on your 600 dpi printer’.

Hello ChrisL, I’m new here. I was wondering if you would be able to describe the terms you are using. I’ve heard of Multiple Master Fonts but I’m not sure what they are and how they fit in the scheme of things. Same senario for open face fonts. I new to the tech side of design. Thanks, Laurie7475.

“It seems to me that the majority of users are interested in having fonts that are relatively simple”

Bitmaps it is then! Whatever tuned you in to font format by democracy cripppled your though path. Sorry for ya!

“Having sliders to perfectly fine tune a typeface...”
You’re stuck on this I can see. If we had sliders for pair kerning, tracking and point size, would you run for the cover complexity too? Who said all users would be “expected to have the same expertise as the type designer”. Who?

“It seems to me that most users would prefer to have a simple font labeled ‘Use this for ten point text on your 600 dpi printer’...Nice thought, has ANYONE on this list ever made a 10 pt for 600 dpi? Any size for 600 dpi? Does anyone have plans to do so? Is is reasonable to expect founders to make fonts for the “general public” for a specific size/resolution? Have I suddenly walked into a we’ve-got-poop-for-dna club? I hope not.

I at the very least plan to look at high-resolution instructing of fonts - for 300/600/1200 and inkjet resolutions. Whenever I manage to come up with a design from which everybody else doesn’t run away from screaming, that is.

So what are you proposing, then, David? I’m having trouble following your argument. You want variations in fonts, yes? and I point out that variations imply users who are knowledgeable and competent enough to be able to select appropriate variations with some kind of user interface. Maybe there are enough such users to justify the development of some clever typefaces, but are there enough such users to interest mass-market software developers in supporting the technology? Are you suggesting a format specifically for professional, experienced typographers? If that’s the world you wanted to inhabit, perhaps you shouldn’t have started Bitstream and begun this whole democratisation of type mess :)

Given that the current companies developing and supporting font formats and related technology are mass-market software developers, I don’t think we can be surprised or very critical of what they’ve done. They are supporting technologies for their user base, which is people who don’t know much about typography. What’s the point on hammering at them? The only way they would change is if a really big OEM client came along who wanted something more and better and had enough money to make it worthwhile.

It seems to me that, although addressing a different set of issues, the SIL folk had the right idea with Graphite: if what MS, Adobe and Apple are producing is too limited for you, design your own font format or format extension, build tools to make it, and then build applications to use it. That is the only way you are going to get away from the lowest common denominator of mass-market software.

But I’m still not sure exactly what you think this wonderful new font format should do or how it should do it, or what the specific benefits are. Do you have a spec? You are very good at making gnomic criticisms of OpenType — I’m still not sure what the heck you were getting at with the Arabic comment —, and at telling other people that they just don’t get it when they can’t understand your oblique references, but what are the specifics? What should be in the great font format? And why are those features better located in the font file than in the development tool? And don’t presume that I’m smart enough to follow anything vague: spell it out for me.

Heck, if I understood you, I might agree with you.

Rather than a critique of OpenType, I’d like to offer an alternative, hypothetical model for a font format:

SPINE-BASED METAFONT

That’s spine not spline.
Each glyph’s ’artwork” would be the basic, un-stroked path(s) that lie at the centre, or spine, of the glyph’s stem(s).
These spines may be fleshed out by the type designer in a number of ways.
1. Most obviously, “expand stroke”; this would have sliders for width, contrast, and angle of contrast — and these values could be varied for different sections of the spine.
2. Terminal. These could be specified from a variety of boxes for different serif types, including “no serif”. Each of these options would be editable, for instance “no serif” could be varied between perpendicular and round.
3. Outline Style. This would be applied to the outline eventually generated by the user. Like the Adobe Illustrator feature. This could make a rough, size-scalable texture, for instance.

These values would not be applied by the font tool and forgotten, but would be part of the font.

Then rather than calling up an outline for each glyph, the font tables would specify values for each of the “fleshing out” variables. Variations of these values could be included in the font, specifically for different output devices. End users, should they desire, could over-ride the built-in values. Compare with the Edit Kern Table feature of Quark XPress, or Multiple Masters.

The spine-based model of font design is rather like character-building in a video game (or the recent South Park website, threaded at Typophile recently).

While it may not be as subtle as outlines in rendering display type, the spine-based format would be more amenable to joined cursive letterforms and ligatures.

It would be possible, for instance, for a display/output device to smoothly “force-join” spines that don’t quite line up.

The creation of characters missing from encodings not supported by the font could be done intelligently by the user’s application defaults — such applications would have a database of spines for all encodings, compare the font with the required encoding, substitute missing characters/spines as necessary, and apply whatever the “flesh out” values of the font are.

This idea isn’t new, but goes back to Donald Knuth’s pioneering work of 30 years ago.

Also, it could be connected to live streaming data, as per the LettError “Twin” typeface.

This mutable basis for a font format is more appropriate to the digital era than the present one of fixed outlines.

I’ve just come across the SVG font format, which seems to be along these lines?

“I’m having trouble following your argument”

Ditto. David, my issue is not that I am unimaginative or stubborn, or attached to a backlog of invested technology, but that I can’t understand you. Like John, I might find that you are actually saying things I agree with and could respond to. I find your messages very cryptic. Nevertheless, I’m very interested to know about your ideas.

Laurie,
The Cliff notes version is:
MultipleMaster fonts were originated in the 80s by Adobe as a way to generate variations of different fonts based on axis (or master). A pair of axis might change weight from light to bold. Another pair of axis might change condensed to extended, Users could dial in anything between the extremes designed into the axis pairs. The idea was to let the user select the degree of boldness or extendedness, or whatever. After several years of production, Adobe abandoned the concept as an end product. However, Multiple Master (MM) axis are used today by type designers in programs like FontLab to help generate variations of weight, etc.. It is now mostly an interpolation tool and assumes some degree of cleanup by the designer afterwards but much less than starting from scratch for each variation. I am sure there is a much better explanation on the Adobe site. You can also do a search on this site and find insightful dialogue including people who have had a role in MM development.

OpenType is a developed set of standards put together by a combination of groups. The two most influential being Adobe and Microsoft. The consortium worked hard to address the shortcomings of previous standards and came up with a cross-platform solution which addresses multiple language and script usage along with including what used to be “Expert Sets” for small caps and oldstyle figures and stylistic alternates, ligatures, and contextual alternates. The real info on opentype is best read from the Adobe and Microsoft web sites.
A Google search will get you more than you ever dreamed of as resources. Again, search this site as well where you will find plenty of comments from Adobe and Microsoft staff as well as some very savvy Indi font designers.

As a start, here is a wikki entry on Opentype:

http://typophile.com/wiki/OpenType

ChrisL

A small correction, Chris: not a pair of axis (sic - the plural is axes) but a single axis between a pair of principal masters. So a single-axis MM font had two masters. A two-axes MM font had four masters. And so on. The maximum number of axes allowed by the format was four, i.e. sixteen principal masters. [I use the term principal masters, because in later versions of MM, Adobe introduced the idea of intermediate masters, i.e. a master part way along an axis between two primary masters, which would affect the interpolation on either side of it.]

Thanks John! I hope Laurie reads you correction too.

ChrisL

PS: I was hoping the Axis was not evil :-)

No. These are the Axis of Owl.

“So what are you proposing, then, David? I’m having trouble following your argument.”

Progress. Do you John, Simon, Thomas, others, take the OT format to be your legally wedded format, ’till death do you part? (Not a rhetorical question).

“That is the only way you are going to get away from the lowest common denominator of mass-market software.”

I had no idea that was the goal, making “the lowest common denominator of mass-market software” font format. All this time, I thought: all those scripts, all that resolution, all those customers, devices, and all that type design, were going to require the highest common denominator. /\/\/\:-o (head Scratch.)

“But I’m still not sure exactly what you think this wonderful new font format should do or how it should do it, or what the specific benefits are. Do you have a spec?”

Spec? I’d need to see, or hear, source code for OT-TT & AT&T & the rasterizers, again?

Thoughts:

Reading everyone’s comments, it seems to me that, as far as the long-term (maybe long-long-term->) future is concerned, we need something like an OOo (OpenOffice.org) approach. Something as important as a universal font format should be an open source as well as openly developed thing. For example, the state of Mass. (following an international trend) has just mandated switching to open document formats for electronic communication.

Between the work of people like the Letterror crew, creative ideas like those of Nick Shinn and SIL, and the cooperation of font creation developers/managers like Adam and George Williams, there is no reason why the type-developer community cannot or should not take the lead here. If the community acts proactively, and unites around a common aproach, the commercial interests will follow its lead in the end, and help to make it successful.

A nice thing about OOo is that, since it’s open-), developers can use it as a real life testing ground for ideas; there is no commercial interest to stop you. For truly high-end typesetting there is TeX, also open to hack and develop.

If we get an open standard going, meeting the needs of both the average user and the high-end typesetter, commercial interests will not wait long before jumping on the bandwagon...

Idris

is this the type of thing you’re alluding to?:
OpenType, now more open

umm... dberlow, can you explain some things? Like who that new spec would be useful for? How one would decide which parts of opentype are the insufficent ones? What would convince the app writers who have so far hardly embraced Opentype that something new (in fact something new with hardly any font support) was going to be worth their while? What would convince font foundries (doesn’t matter if small or large) to support it?

Hi Paul,

is this the type of thing you’re alluding to?:

That is a start, but I was also referring to a concern that has come up in this thread, including dberlow’s comments, viz., that the format was designed largely with commercial interests in mind. If so, then typographers and high-end typesetters should take the lead on the Next Big Thing (tm), and not merely follow the lead of the commercial giants. OOo and TeX provide free, open source platforms for testing new ideas in both the mundane word-processing world and the high-end typesetting world, so we don’t have to “wait” for the commercial interests to act first; let them follow the community’s lead.

Best
Idris

Hi Sander,

Caveat: Obviously, I do NOT speak for dberlow;-)

who that new spec would be useful for?

high-end typesetters perhaps? average users who need more flexibility?

How one would decide which parts of opentype are the insufficent ones?

Open Source community style, focusing on the needs of typesetters and interested users.

What would convince the app writers who have so far hardly embraced Opentype that something new (in fact something new with hardly any font support) was going to be worth their while?

Use OOo and TeX for testing and implementation, and the commercial app writers will follow suit, if only to compete.

What would convince font foundries (doesn’t matter if small or large) to support it?

If a few foundry owners are involved in designing the spec, others will come along. The present format was developed by “companies who are overwhealmingly not type founders” to quote David. Ok, then get the foundries involved!

Best
Idris

Coming late to this thread, I would like to make a few corrections and observations and apologize in advance for length:

John Hudson writes,

’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).’

John, a moment’s reflection will make you realize that this statement is untenable. All MMs are extrapolable. Think about it. There is nothing in an MM font that prevents this. All you need is a ’Creator’ app that will allow the user to extrapolate. Adobe did, indeed, have a version of ATM (could it have been 2.4?) that permitted extrapolation. The feature was taken out because it was felt that the instances were unpleasing and did not reflect Adobe’s quality image - always the risk with extrapolation. But any app developer that wished to could write a ’Creator’ that did extrapolation. In other words, this is not an issue of the font format, it is an issue of the software used to support it.

’What should be in the great font format? And why are those features better located in the font file than in the development tool? And don’t presume that I’m smart enough to follow anything vague: spell it out for me.’

Let me explain why David is so impatient, John, with the thinking behind this remark. This goes back to the late 1980s and Sumner Stone’s reign at Adobe. It had long been realized that multiple axes were a desirable design tool, thanks to the pioneering work of the late Stephen Harper (among others - and have I got his name right?). But it was Sumner who had the idea of putting variable type in the user’s hands, and not just the type designers, and then went on to sell John Warnock on the idea. Warnock did indeed eventually embrace it, and of course MM is still a critical component of Acrobat and for that matter any Acrobat-alike, such as OS X Preview. In other words, it is already 20 years ago that someone had the idea of putting variations and other features into users’ hands. Having lived through this 20 years ago, David is naturally surprised that the issue should still be up for discussion.

Mark Simonson writes ’There were only a small number of MM fonts built, mostly by Adobe, and you needed ATM to use them.’ Mark, I am unaware of any MM font that cannot be used by any app in XP, OS 9 and OS X. ATM is ’hard wired’ into XP, OS 9 and, roughly speaking, OS X.

On the other hand, it was as difficult as you like to use the fonts to their fullest capabilities. In this sense you are quite correct.

Thomas writes,

“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).”

I disagree with this. One program and one program alone ever had the MM interface down to the point where anyone could enjoy using MMs: Lari Software’s Lightning Draw GX which worked on System 7.5 through 8.1 and perhaps beyond. Unfortunately, although the revelatory LightningDraw feature set has driven the bulk of Adobe Illustrator improvement from versions 7 through 9, Adobe itself never got the interface right. The problem wasn’t evangelism. The problem was that Adobe never showed app developers how to do it right, and never helped font editor developers to make MM development easy. The reason it didn’t help font editor developers was because it wanted to keep all good MMs to itself. But Adobe really shot itself in the foot by not committing interface engineers to showing everyone, especially its own app developers, how to make MMs both easy and fun to use. This is really a pity. And of course, as David points out, MMs are hopelessly primitive compared to Variations and other successor technologies.

Paul D Hunt writes,

“dream format: multimaster opentype fonts”

Paul, way back in the infancy of time, say 1997-2000, this was the format that everyone expected to have. MM was withdrawn from the OT spec because Microsoft believed it would be too much trouble for its app developers to support. This is right in the sense that it would be difficult to app developers to support well, in the absence of built-in OS support such as Apple had demonstrated with GX. But it is not right in the sense that the beauty of MMs is that the app doesn’t have to know it is looking at an MM. As far as the app is concerned, an MM can be any other font. And in spite of all of that, MS deserves credit for being the first app developer to support the optical axis in MM fonts automatically (as in mid 1990s versions of MS Word). Another word for your dream format is Apple’s GX, from the late 1990s, which did just about everything in MM and OT, and quite a bit more. GX almost became a dual Mac/Win standard, but there were some last minute hitches over money. This time around, instead of getting USB2, which really works, we got OT, which really doesn’t.

What David is really talking about is that there is no provision in type technology for optimally implemented type. And that’s because, as he instances, few here have ever had to design a 10 pt type for 600 dpi rasterization. Few here have any concept what a type can, and should do, beyond its basic unitary design. Type needs to be better, and at the same time it needs to be more fun.

I think it is unnecessary to spend time on the issue of MMs and OT, because I think it is clear, as some at Adobe and other companies believe, that MMs will rejoin OT as soon as OS’s and apps run out of other features and need some novelty. In two years, five years, or ten years, we will see MMs in OT again. But, as David would point out, what is the point of doing something so old-fashioned when so many more advanced things could be done? It should be happening now. The painfully simple technology we have today has a bad effect on designers because it doesn’t challenge them to go to the extremes of their craft.

I was asked to critique the open type format, and I did. Now, I’ve been asked to tell you who would use this stuff, and I already did. You should r e a d it again if you didn’t get it, but I firmly believe that real Chinese and fancy Arabic CANNOT BE MADE for TEXT & DISPLAY, or for SCREEN AND PRINT, to the standards of even metal, with OT. I pointed this out several ways, including to say that I think anyone who believes they are doing the same for Latin is a Lier. Even the great Verdana, e.g. is not suitable for anything but screen and printer agate.

Should a “Standard” be thus so limited? I have asked a dozen questions here and gotten no answers, just more baby questions :)

I have a question. Earlier, Thomas spoke of how big an advance OT is, how it shouldn’t be surprising that apps can’t deal with it yet (10 years later), how ’difficult’ everything is.

Wait a minute, Thomas. Apple did this all with GX in the mid 1990s, and they had the code for both Windows and Mac. So where’s the difficulty? Where’s the ’advance’? In another ten years we might have a bit more OT progress, a bit of MM, but what is that compared to what Apple coded for both platforms in 1995? Something is wrong with this picture, because here we are ten years after OT and neither MS nor Adobe yet supports it fully in their own apps. Under these circumstances, why would, and how could, anyone else support it? And as David points out, if it really is useless for Chinese and Arabic ... what’s the point?

Here’s my dummy’s question. Simplifying the issues to an extreme, is it roughly true to say that the philosophy of GX was to make advanced typography features easily available to app developers whereas by contrast, with OT, the burden is on the app developer to implement advanced typography features himself?

And if OT really is a cock-up, as it appears it is, isn’t it better to admit that now and try to fix it before any more app developer time is lost? We’ve had ten years of excuses. That isn’t good enough.

And finally, isn’t it time for everyone - Adobe, MS, and even Apple - to look at GX again as a model? GX was not just about type, after all. The point of GX was to provide built-in code for all advanced graphical application development so that, for example, an Illustrator-quality app could be built to version 2.0 quality in six months and to version 8.0 quality in 12 months, and this by a tiny team. I give just one example. LightningDraw was the first bezier curve program to offer transparency. That’s because GX had it built in and all the app had to do was call it. That happened around 1996. It took Corel, Adobe, and Macromedia another three years or so of phenomenal effort to get transparency into Illustrator, Draw, and Freehand. What a waste of intellect and shareholder dollars.

Now look at Adobe and MS and their investment in their own complex apps which now enjoy near-monopoly status. And you wonder why they don’t really want to make things better for other app developers.

Now look at Berlow’s comment roughly to the effect that foundries have to all intents and purposes been effectively excluded from OT development.

Now ask yourself: if you’re going to stealth in a closed type situation, what better thing to call it than _Open_ Type?

What a complicated situation this is. Where do we go from here? Where are the people of intellectual calibre adequate to lead us out of this mess?

Hello, Bill. I don’t think anyone is going to look at GX again, least of all Apple. But this relates back to what I said earlier in the thread, that you can’t divorce type technology from the strategic and economic interests of OS developers unless you take full responsibility for the entire rendering model, plugging into the system resources only when you need to or find it efficient without compromising what you want to do. There are good examples of software that does this, mostly specialised software dealing with e.g. music layout or mathematics typesetting. I mentioned SIL’s Graphite as another example: a model that allows SIL to provide support for scripts and languages without waiting for support from MS or Adobe and without being limited to the Mac OS and AAT support.

The great thing about the sfnt file format is that it is so readily extensible and is a great basis on which to build new stuff. There is no reason at all why one couldn’t spec new tables to support things one wanted and no reason why one couldn’t make tools to build such tables. And now that OpenType is becoming an ISO standard (as part of the MPEG standard) there is a mechanism for having such tables formally recognised as part of the OpenType format withouth relying on MS or Adobe (although the international standards process is not for the the impatient or easily frustrated). But getting something into a font spec, or even getting the tables into a font, is not the same thing as getting the layout behaviour supported in applications. This is where you run up against the strategic and economic interests of the software developers, and so long as you are relying on them for the software to actually use the font you will have to deal with this problem.

So perhaps the answer is to consider high quality typography as a specialist software goal (which is basically what TEX did, although the results were not always so high quality), and not something we should expect from mass market software.

This is where you run up against the strategic and economic interests of the software developers, and so long as you are relying on them for the software to actually use the font you will have to deal with this problem.

This is exactly where alternatives like OOo and TeX can play a very fruitful role. Free and open source.

So perhaps the answer is to consider high quality typography as a specialist software goal (which is basically what TEX did, although the results were not always so high quality)

In the case of TeX, I think we have to distinguish the capabilities of TeX from the limitations of its users, who are not generally typographers. Also, LaTeX makes high-end typography difficult because many things are hard-wired in that format (though the relatively recent memoir package alleviates this).

Any high-end software can be used to make mediocre output. Yet few if any layout programs can match what a competent typographer/typesetter can do with TeX-) particularly in some areas like critical editions and similar complex layout, including control of orphans, widows, typesetting on a grid, etc.

The newer format ConTeXt gives non-programming users a degree of access to typographical sophistication with TeX that was previously accessible only to expert TeX programmers. When added to the microtypography features of pdfTeX there is little that ConTeXt cannot do when it comes to hq typography; it is truly an amazing engine and perhaps the best kept open secret in the high-end typesetting world.

Here is a draft manual explaining and illustrating some high-end typesetting control capabilities of TeX:
http://www.pragma-ade.com/general/manuals/style.pdf

See especially pages 29—38

It’s not your grandfather’s (or even your father’s) TeX anymore;-)

Best
I

’I said earlier in the thread, that you can’t divorce type technology from the strategic and economic interests of OS developers unless you take full responsibility for the entire rendering model, plugging into the system resources only when you need to or find it efficient without compromising what you want to do. There are good examples of software that does this, mostly specialised software dealing with e.g. music layout or mathematics typesetting.’

John, I want to reread carefully what you’ve said earlier - perhaps tomorrow. For now I just want partially to parse the passage here. Today, two principal app makers - MS and Adobe, have indeed taken full responsibility for the entire rendering model. MS, because it’s in full control of the rendering model for Windows, and Adobe, because of its no-longer-so-top-secret plan, Project Whatever it is called, which has now been fully implemented, whereby each Adobe app (e.g. Ill, PShop, InD) has its own entire rasterizing system built in. Yet in spite of all this control their own apps don’t have anything near full OT support, and indeed, far from full support, each app seems to support a different and, remarkably, exclusive subset, if I at all understand what is going on. People are being remarkably careless with their claims here. For instance, earlier Thomas claimed something to the effect that when OT came out, more apps supported it than supported MMs when they were discontinued. But partial support is not full support. It is also possible to say, and I did, that every app on Mac and Windows supports MMs to this day. And they do: but partially, not fully.

I would also like to say that nothing can be more confusing to the user - certainly not slider bars - than any OT font, because there is no standard character set. You know the argument: what do I get new when I buy Adobe Bodoni in OT? Answer: not a single new glyph. Ah, but wait a minute. Answer me this: why did I have to buy a new set of Utopia OT because I couldn’t get Utopia Type 1 to work in InDesign CS?

uh - er - umph. Gotta run.

DB: I firmly believe that real Chinese and fancy Arabic CANNOT BE MADE for TEXT & DISPLAY, or for SCREEN AND PRINT, to the standards of even metal, with OT

I don’t know enough about Chinese typography to comment on that, and I’m not sure how you compare SCREEN typography in OT with what was available in metal type — a singular case of apples and kumquats —, but I do know quite a lot about Arabic typography. What can be done with OpenType for Arabic is better that 99% or more of the metal typesetting of Arabic ever produced. In fact, there is really only one example of metal typesetting that surpasses what has currently been done with OpenType, and that is found in one half of one book printed in the Ottoman Empire near the turn of the 19th-20th centuries. It is only found in one half of the book presumably because the system was so difficult to get right that the compositors seem to have stopped paying attention in the second half; perhaps they had a deadline to meet and couldn’t spend so long selecting the appropriate special sort to use in each instance. I have not analysed this edition, but I would be surprised to find that there was anything in it that could not be modelled in OpenType. As long as you are dealing with a discreet set of fixed shape sorts that are positioned relative to one another, there isn’t a lot you can’t do in OpenType with some ingenuity in the layout lookups. What OpenType cannot do is the kind of thing Tom Milo is doing with his Arabic engine, but then no previous Arabic typesetting system has been able to do what Tom is doing, which is to directly model both the rules and the order of the classical calligraphic styles. This involves dynamically adjusting the glyph shapes on the fly and breaking the text string into stratified layers and writing them successively, anticipating what will be the int subsequent layers. Neither of these things can be done in OpenType, but then they couldn’t be done in any other typesetting system either.

Tom’s technology is another good example of a specialised typesetting system, appropriate for a high end publishing system employing the classical script with all bells and whistles. And it is crucially important that such technology exists, but you wouldn’t necessarily want to use it for your Arabic e-mail. There are technologies and levels of implementation that are appropriate to different circumstances, and the level of complexity that you want for one purpose might simply be an inefficient processing overhead in another situation.

“The great thing about the sfnt file format is that it is so readily extensible and is a great basis on which to build new stuff.”

:) @ack

“I don’t know enough about Chinese typography to comment on that, and I’m not sure how you compare SCREEN typography in OT with what was available in metal type — a singular case of apples and kumquats”

Yes...Well, here’s the way it works. The keys tinkle different, to begin where all such discussions of “universal” font formats should, with the users. First, the users who input, and then the users that read the result. (Assuming that the mill of commerce has taught the former to obey the latter even before being told to do so by the Central Party;)).

In this alternate key tinkling universe, the individual characters (40,000 or so), representing what we call words or phrases, are build up of a small number of strokes (18 or so), representing the not-so-long-ago abandoned manual strokes produced with the hand. These small number of strokes play out into hundreds of variants as they are combined into radicals, (parts of whole characters closest in Latin to something like a letter, syllable, or word), and again slight variations occur in strokes and in radicals as they are combined to form complete characters. But back at the input, there are a number of ways to accomplish it; from hunting for the complete character, to typing a phonetic translation in another script to built radicals up to characters.

The broadest method coming into general use is the input of radicals to form complete characters, and the future trend is towards the most intelligent computer-aided input possible, which would allow several parallel and instantly selectable systems, (i.e. The user can float amongst hunt and peck, input by phonetic, or by radicalanji). And what the readers want is fine Chinese, which is to say as much refinement to the strokes as the designer can provide to “even out” the great variety of density and complexity in the Characters. That is the market for text, where I think all “universal font format” critiques rest, but those ideas exend to nearly all applications. The important message I took away from learning this is/was, that the best and future input method, and best output result are both achieved by careful preparation of fonts to make them able to react through the underlying strokes and radicals of the characters,,, to the input and to the output conditions — then making a font by combining the parts in the font tools and removing overlap is obviously the wrong solution for the long term, (a long term which happens to be now relative to when Apple published their Eastern Scripts the first time...).

Why? “I firmly believe that real Chinese and fancy Arabic CANNOT BE MADE for TEXT & DISPLAY, or for SCREEN AND PRINT” — would be obvious to anyone who’s designed or claimed to design baby scripts like Latin for multiple size use (and/or low resolution). In addition, when you throw the resolution problem at stroke and radical unaware Chinese fonts, well, its worse than having an elephant squat upwind of you in a hurricane... e.g... I once was asked to estimate “where it might be safe to rasterize the simplest Chinese design without hints, grey scale, or dropout control, so I proofed the first two levels of the Japanese Industry Standard character set (14,000 or so), and located a character with 33 transitions, e.g. 16 black strokes, and 17 white spaces. So the answer was 67 and that is what I still give as an answer for all scripts when anyone asks about that sort of number for any script...67.

This is why I critique this format so harshly: A. Without the use of more intelligent composites and the capability of variations at input/output, not fontput(!), OTKaput 20?? in China. B. Without the employment of more intelligent people in the driver’s seat, or intelligent and talkative passengers, we only have the best “Latin First!” font format in OT.

And...Metal is not the object, it is a Marker.

Okay, so it turns out I know more about Chinese typography than I thought, since none of this was new to me.

The broadest method coming into general use is the input of radicals to form complete characters, and the future trend is towards the most intelligent computer-aided input possible, which would allow several parallel and instantly selectable systems.

If this is true, then it will presumably drive technologies to support such input, including font technologies.

“Okay, so it turns out I know more about Chinese typography than I thought, since none of this was new to me.”
:) I know, You ignore this wisdom in Latin type too.

“What OpenType cannot do is the kind of thing Tom Milo is doing with his Arabic engine, but then no previous Arabic typesetting system has been able to do what Tom is doing, which is to directly model both the rules and the order of the classical calligraphic styles”

:) In some parts of the world, and I know I’m not saying anything new here, there is a great deal of interest in skipping metal typographic influence, going straight from calligraphy to computer composition. I see this need in Every Culture. The problem for Arabic is one that you don’t see, even though you’re staring Milo’s stuff in face?

ISO, (aka, I Surrender, Okay?) didn’t get hints, features, interpreters or rasterizers did they? Did they get anything more than Kontours and Kerning? (ISO gets hand-me-downs that no one thinks afford more competitive efforts). These “assets” are then frozen in a bureaucratic Tar Pit, while the important things, mentioned as not in ISO’s sticky lit’le hands, will continue to divide and retard. The boat has been rocked biannually, as I promised a long ago.

Nothing to do with the topic of the thread, but a correction:

>not-so-long-ago abandoned manual strokes produced with the hand

>coming into general use is the input of radicals to form complete characters, and the future trend is towards the most intelligent computer-aided input possible

AFAIK, neither of these statements is accurate. I was recently in China. Everybody is trained to do decent looking characters—which are not easy—and I was struck that every broken-down shop has hand-written signs and posters that generally look quite competent, and sometimes excellent. The tradition of writing characters is strong, and alive. (They generally don’t understand that roman characters look wrong when written with a round brush, but that is another matter.)

The current method of inputing Chinese characters into the computer is through the romanized phonetic Chinese, Pin Yin. You type the phonetic pronunciation in roman characters, hit the tone number (1-4) and the character pops into your text. Everyone in China is now taught Pin Yin writing along with Pu Tong Hua (Mandarin), so all young people can use use the computer in this manner, if they have gone through elementary school. There is no reason to think the inputting through strokes or radicals is the wave of the future.

The traditional education involved simultaneously teaching water color painting and calligraphy. I thought I heard that this is being dropped, and the use of romanization for the computer in this way may threaten the general excellence of Chinese writing. By the way, you can’t judge Chinese graphic design by the horrible examples you see in China Towns in US cities. The general level of graphics in Chinese cities is much better. How they handle words in roman text and logos, which are fashionable, is often clumsy, though.

The problem for Arabic is one that you don’t see, even though you’re staring Milo’s stuff in face?

Our difference is that I see the need as being particular to circumstance, and I’m not convinced that the technology required to do what Tom does is the same technology as I need for other kinds of Arabic text processing. This is not simply because his technology is slower than OpenType, but that OpenType itself is too slow when it tries to emulate (imperfectly) calligraphic models. The problem is in using processing models of great complexity where a simpler model is appropriate to the particular circumstances. You might be willing to wait for a page of the Qur’an to be slowly rendered in immaculate emulation of the calligraphic norms, but you don’t want to wait the same amount of time for an email using a much simpler style of the script to be displayed. This is why I favour multiple technologies tailored to different circumstances, rather than a one-size-fits-all technology, whether that is OpenType or something else.

[UPDATE 1 May 2007 : the above comments about the relative speed of OpenType vs Tom Milo’s ACE layout engine were based on secondhand claims. Tom challenges them, and I have not had the opportunity to make a direct comparison myself. Tom’s new Tasmeem plug-in for InDesign ME will hopefully provide such an opportunity, and I’ll be more than happy to withdraw the above comments. For now, they should be taken as reportage of what I had been told, with full acknowledgement given to Tom’s disagreement: ’ACE beats OT hands down. It was already fast on a 4Mhz computer in 1986. In Tasmeem there is no apreciable difference in rendering speed between ACE and OT - yet the ACE tasks are far more elaborate.’]

I recently made an OpenType font that supports correct display of the Hebrew Bible text. In order to handle the complexities of the Biblical text, my font ended up being many times slower to process than a typical Hebrew font designed for use in modern Hebrew. The trouble is that my font remains that much slower even when used for modern Hebrew text. This is an example of what I am talking about: complexity that is appropriate for the circumstances of typesetting the Hebrew Bible is not appropriate for reading Hebrew email. In this case, the complexity is within the font, but in Tom’s case the complexity is in the rendering engine. In either case, the complexity is excellent and necessary for its intended purpose, but is an ineffeciant overhead when the technology is employed for other purposes.

>ISO, (aka, I Surrender, Okay?) didn’t get hints, features, interpreters or rasterizers did they?

ISO gets the complete OpenType specification 1.4 (which is already part of MPEG) with some implementation specific text and company names and trademarks removed - that’s their rules. Once its an ISO standard I wouldn’t be surprised if Apple proposes the addition of their variations stuff. I look forward to seeing what you, Erik & Just, Bill and others propose too.

Is an ever more perfect rendition of calligraphic arabic according to centuries old rules really the future (and end-all) of Ararbic typesetting?

Hi Sander:

Is an ever more perfect rendition of calligraphic arabic according to centuries old rules really the future (and end-all) of Ararbic [sic] typesetting?

There are two schools of thought on this. One school, perhaps the dominant school, says, “Hey, let’s adjust Arabic-script typography to fit Western digital typography technology; forget the manuscript tradition”. The other says, “No, let’s create a technology that can bring the manuscript tradition into the age of digital typography just as it was brought into the age of metal-type at the turn of the 20th century”.

In my own opinion, there has been very little that comes out of the first school that is aesthetically pleasing at all. The first school represents a defeatist attitude that is unfortunately quite common. It is also unfortunate that the only available book on Arabic typography promotes this defeatism.

There is a perhaps hidden subcontext to your question that needs fleshing out: The relation of calligraphy to manuscript writing in Arabic is a bit different than that relationship as it exists in European history. Although Islamic civilization was aware of printing technology before Europe, it was hardly accepted for serious works until the 20th century. It was never a matter of technology but of aesthetics. In the context of a Muslim civilization that maintained its territorial and intellectual independence, there was the spine to accept metal press technology only on its own terms. As Imperialism took root and the new coopted intellectual classes begin to worship everything European, that backbone gave way to the defeatist attitude that dominates so much of Arabic typography to this day.

I cringe when I read Arabic books today, just like Knuth cringed when he saw the first printing sample of one of his books using the then nascent digital typography. But instead of being defeated, Knuth spent ten years designing a system that can be programmed to implement the bulk of traditional typography plus be ready for future developments.

That is exactly what Arabic needs today, so that books can be enjoyable to read again. And so I can get on with my own critical editions...

Thomas Milo takes the second approach; opentype capabilities help as well.

By the way, one can take a proactive approach to traditional Arabic-script typography without being reactionary. Once the proper rendering algorithms, etc. are available, we can build on tradition and move into the future from a truly authentic foundation, as opposed to one based on the limitations (wrt Arabic-script) of Western digital typography technology.

All the best
I

There is something called Adjacency. The issues of Adjecency manifest themselves in different ways in each of the major scripts. Having separate technologies to deal with them, is as stupid as I’ve ever heard, but Cutting Edge Luddites have their entertaining moments don’t they!? :) Is there a type word beyond more kerning pairs, for typographic adjacency,,, please?

With Latin, and with the exception of connecting scripts and a few other type styles, in our everyday working fonts we’ve herded our adjacency issues into Kerning Pairs, and, standing by our love of long-necked “f’s” we do all sorts of things. This had been a nontrivial exercise from Gutenbaby’s time until mechanical composition nearly killed even the f ligatures. Later, just to make sure we didn’t find ourselves behind in an adjacency crisis, we let the beast spread from the simple problem of adjacent characters in a font, to the far more profittable and complex problem of adjacent style issues. Chinese, solves its adjacency “upfront”, in a sense, caching all the combinations with a myriad of parts into each character, and solving the issues well enough to set characters in any direction and dimension or on any curve, without kerning or substitution.

Arabic, has a few styles without adjacency issues, mostly simplified, scratched and modern, I think. It also has some with moderate, or easily predictable adjacency that I’m sure are solved from metal to OT. But the further, back (or forward !;) ) you go, perhaps in relation to some “golden age” of leisure time (or a future age of super computing power in a pack of gum), you find what I’d call roiling adjacency, where, yeah, it’d take a little while for the final forms to settle as issues resolve themselves among the input (BUT SO WHAT!). It could be unique when it finally stood still, depending on that input. But we’ll not know for while yet, we’re still making up our dumb “a**” logos. ;)

The important think (!) to remember, as this seems to such cause great shirking in the name of progress, is that when you put a trailer hitch on to the back of your car it does not automatically slow your car down. In fact, you have to hook it up to something for that to happen. Another important think to remember, even though you probably didn’t know it before, is that this problem could be defeated much like the towing problem, by adding a hook that allowed composite parts to be stacked (like trailers rollin’ down the highway), instead of being processed independantly, and all existing fonts’d still work JUST FINE. In addition, real designers would also be able to make parts react to composition the way the brain sometimes wants to read ’em.

“That (stack-based composites and variations), is exactly what Arabic needs today, so that books can be enjoyable to read again. And so I can get on with my own critical editions…”

Sorry for joining in late... I’ll try to be quick as there’s a lot to be said and never enough time.

>There are two schools of thought on this. One school, perhaps the dominant school, says,
>“Hey, let’s adjust Arabic-script typography to fit Western digital typography technology;
>forget the manuscript tradition”. The other says, “No, let’s create a technology that can
>bring the manuscript tradition into the age of digital typography just as it was brought >into the age of metal-type at the turn of the 20th century”.

There’s another approach to this and it fits neither schools: we are here to solve problems. If the design problem is a new one, then the solution will be new. If it’s an old problem, then old solutions would work. I refer here to the aesthetics and not the technology as rendering calligraphic designs is still a work in progress and still unavailable to a large audience.

Example 1: An Arabic signage face for an airport is a new problem (ie 20th century and later) and as such, when you design it, you don’t think: hmm, what would the Ottomans do? Rather, you look at what the problem is (legible from distances etc...) and then see what style of the script fits best and how can you make sure that it fits the design brief. Obviously, not a Thuluth or a Nastaliq.

Example 2: An Arabic face for the setting of a poetry book. Well, there’s a large repertoire of script styles for that, wonderful! Call Tom Milo and you’ll be happy.

I think we miss out on a lot if we say that one or the other is a better school of thought. The important thing is that the type needs to function.

A slightly off-topic note: one does not need complex technology to make good Arabic typefaces. The heritage of “unhappy” design solutions is not just because of the technology. It has a lot to do with the designers as well. Take a look at Tim Holloways’ Markazi font. It can be easily represented with OT today and it is one of the most avant garde and fresh designs that has ever been designed for Arabic, absolutely wonderful. It is obvious that he is a talented designer and understand 2 important things: 1- the nature of the script, 2- what a typeface needs to do.

Hi Nadine,

U r right of course, we are here to solve problems. The “two schools” thing is a meta issue wrt the best way to approach solving the problems. What some of us believe is that, even in designing e.g. an airport logo, technological access to the tradition is important, and new trends can be developed on that basis. And one need not be reactionary, as Mohammad Zakariya points out.

Could you point me to a sample of Tim Holloways’ Markazi font? I’d like to see it-)

I do not deny that good work can be done even with limited technology. But with appropriate (as opposed to “complex”) technology one is even better situated to solve problems: one has more choices.

BTW: I am sure I’ve seen Nastaliq airport logos before, in Iran, Pakistan, maybe even Kuwayt...
-))

Thank you for your comments!

Best
I

Hi David,

Could you flesh out your adjacency/stack-based-composites-and-variations idea a bit more? I have forwarded your ideas to the people working on the next generation of the TeX engine; would you be willing to consult on making these ideas more precise for us?

Feel free to contact me off-list to discuss this. It is all open source but there may be a funding option-)

Best
I

David, yes. What you are saying now is much less vague (thank you), and I agree.

Idris, you can see a sample of Tim’s Markazi type in the awards section of Language Culture Type. I rate Tim as one of the greatest living type designers, but his work is often overlooked because it has been exclusively in the realm of non-Latin scripts. If you have the Adobe Acrobat 7.0.5 upgrade, which implements support for Arabic, Hebrew and Thai, you should have the new Adobe Arabic fonts somewhere on your system. This new design by Tim is a good example of what Nadine is talking about: Arabic type design starting from a question of purpose (in this case the quite broad application of modern business communications in a wide range of languages — the sample below is Persian).

Hi Idris,

“Could you flesh out your adjacency/stack-based-composites-and-variations idea a bit more?”

I can try. Once you have the composites on a stack, you have two sorts of opportunities to deal with; One are additional design issues, how and when the different parts are called and what else you can do to them in combination with x-y movement, scaling, rotation, location in variation space and hints, all at your disposal to best solve the “local” marking and adjacency issues and improve to either a wider range, or a more precise target of quality, for output. There’s a lot more to say about that though to make it clear in detail, but the singular most important thing is without the right APIs, the founder must precache all the “arrows” he or she wants to “target” to “users”. The second opportunity is of course in the output, how does the stack with interacting components and variations get the best possible transformed image to the rasterizer, and then to the user, who presumably asked for it in the first place, completing a loop with the type designer, if they’re good. Today’s font API’s don’t dare ask much of the user, os or beyond, and therein lies the barrier, a sparsely populated loop of possibilities that practically no one can breech for the masses of PC users.

TeX, bless it’s heart, has been applied to every single script, application and occupation, but has never made a mass audience happy. I will gladly help you in and out of list, but not for hire. Nadine, John, and many others have said that the spec. comes from the users. I think that the spec. “they” need, (i.e. for what could be advertised as a “World Wide Operating System”) is what we’ve got now, plus, a “few minor tweaks” a new old table or 3, and an API adjusted here or there to “ask more.” The major problem lies in the will of three companies, Yes, I can arrange some sort of thing with ISO all by myself to change the Written Spec., but it’d be so much more effective if the companies who were making billions of users wear the typographic equivalent of cardboard shoes to formal occasions Actually do it. They are the API Barons and without really getting them overboard, as I’m sure SII can attest if the Seahawk Bowl hasn’t completely consumed his reason, canoeing without a paddle comes to mind.

And John, (thank a higher deity of your choice), agrees with me fully, or at least I’ve rocked enough so he can see over the side,,,;) which means I can call my brain surgeon off defcon 4, where he was fully prepared to downgrade me to a clam shucker, or pack me off to a grape stomping school, he’s not quite sure, my brain surgeon having received a C- in the phrenology of type from the University of Southwestern Kamchatka at Murlké. This Arabic Specimen is absolutely gorgeous! Crisp, Clean and Precise. For numerous applications, I’d think it’d be perfectly suitable. But on the other hand, I could easily imagine applications where it would be cold, monotonous and inappropriate. But I can also see a relative of this type squirming and twitching around slightly into 37 different word spaces, 4 different 2-dot-accent variations, 246 versions of the 75 glyphs present, not just for better line endings, but then it’d be appropriate for something else, and then something else...for something else.

This Arabic Specimen is absolutely gorgeous!

I’m very pleased to report that today we received word that Tim’s Adobe Arabic design was selected in the TDC type design competition.

Hi David,

I can try. Once you have the composites on a stack,

Thnx for the clarifications. I also got some feedback from the pdfTeX team on your original suggestions, which I will forward soon.

TeX, bless it’s heart, has been applied to every single script, application and occupation, but has never made a mass audience happy.

With ConTeXt there is now hope-)

I will gladly help you in and out of list, but not for hire.

That’s fine, it’s all open source anyway-) Thank you very much for offering your help. I turned my email setting on so you can contact me directly (and i don’t need to invite spam by posting it publically):

http://typophile.com/user/10590/contact

We are preparing for heavy movement in the pdfTeX team so now is the best time to get things right-))

Thank you again David.

Best
I

Idris: There are two schools of thought on this. One school, perhaps the dominant school, says, “Hey, let’s adjust Arabic-script typography to fit Western digital typography technology; forget the manuscript tradition”. The other says, “No, let’s create a technology that can bring the manuscript tradition into the age of digital typography just as it was brought into the age of metal-type at the turn of the 20th century”.

But do you see these two sides as the only two possible sides? Besides, aren’t these technological sides, and not really font design and looks related as such? Is part of what you are saying with bringing the manuscript tradion into 20th century is akin to being able to properly spell naïve? Or am I confused?

I’m still also mystified at the lack of the evidence in form of additional features (which can do pretty darn anything[1] with just the existing lookup types) for a push in the direction of change. After all, if it is being held back, surely pressure for such with accompanied patches for pango / qt would cause some to exist by now?

[1] and by anything I mean that you can make a virtual machine equivalent to Turing machine