Critiques of the OpenType format?

ishamid's picture

Hi all,

This is my first message to this forum. I look forward to getting to know this community!

OpenType fonts are all the rage today. Are there any critiqes of the format, or discussions of its limitations?

How many typesetting applications can actually take full advantage of opentype fonts?

What are the chances that OpenType (at least some of its advanced features) will go the way of MultipleMaster fonts?

Context: I am working on a Classical Arabic-script typesetting system with very high-quality typographical standards. I primariliy use TeX and ConTeXt.

Best to all
Idris

Rob O. Font's picture

From the links to the ISO story we have this:

"This allows, [mpeg’s adoption of OT] for example, for the streaming of text in a format based on 3GPP Timed Text providing a low bit rate solution for subtitles or karaoke-like applications growing in popularity worldwide."

... a huge relief. It’s been bad type that’s kept me from being a professional Karaoke instructor.

From Adobe on the same topic:

"OpenType fonts have been embraced by creative professionals worldwide, who recognize the benefits of multilingual support and the new levels of creative control they have when delivering high-impact text for print, the Web, and a wide variety of computing and display devices," said Digby Horner, senior vice president of Engineering Technologies at Adobe. "The ability to compress and embed beautiful resolution-independent text as part of an MPEG-4 application will expand the creative options open for everyone working with a broad range of multimedia technologies."

Yow. Now that is a lot to live up to: compressed and embeded beautiful resolution-independent KANJI IN MOTION at text sizes...

When anyone can show a demo of this, I'd be interested in singing along.

Si_Daniels's picture

Karaoke is a technology 99% of the world can relate to, but some would argue that quality captioning text for translated subtitles or captions for the hearing-impaired are more important.

MPEG previously used OpenType as an externaly referenced proprietary spec, but other standards (digital TV, high-def DVD etc.,) require the standards they reference to be open standards. As MPEG had already accepted OpenType it was decided that OpenType should be standardized through ISO's MPEG sub committee (SC29).

If you'd like a copy of the PPT we presented on this at ATypI I'd be happy to forward it.

Cheers, Si

Rob O. Font's picture

"Karaoke is a technology 99% of the world can relate to"
I would say that number is really closah to 19%, if realte to means "use", but I don't wear a helmet, I'm not an over-the-top marketing expert, and I don't fall on my head much anymore. LOGO is, IMHO, the closest to 100% in universal relatability, and TEXT is next at 80-90%.

"copy of the PPT"

Thanks! Does any MS document list all of the potential arguments, or variables, that can be asked of a font and used by the API(s?). Greg's old mantra, Script, Language, Character, Glyph...but complete? Does this now include speed and direction of text?

Thomas Milo's picture

I recently noticed this statement:

“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 is not true. We - the DecoType team - set out to design Arabic typography, not calligraphy. By closely inspecting Middle Eastern typesetting and reading their own statements we learned that these craftsmen modeled their work after the ubiquitous Arabic script grammar. With hindsight, that is the only thing one could have expected: it happens everywhere. For normal text use, type designers have always reproduced script, not redesigned it.

Presently, our engine does _exactly_ what previous Arabic typesetting systems used to do. Not the Dutch or the Italian ones, but the Turkish and the Lebanese ones, of course.

As for calligraphic styles, these are beyond our competence, we don't touch them. We deal with scripts that were in use as metal typography: naskh, ruqah, nastaliq and, to a lesser extent, thulth.

As for the fact that Open Type cannot deal with Arabic typography in this sense, it's not our fault. We did not impose or raise the standard, we just implemented it.

I hope that clarifies the matter.

t

Thomas Milo
DecoType
www.decotype.com

gohebrew's picture

I don't know the details of what Thomas Milo is doing for Arabic in OpenType, but it must be, as the Israelis say: "Mamash."

I have heard outstanding praise from one whose opinion I value a lot, and can imagine that he's doing something like I would want to do, but my focus is not Arabic, but Biblical Hebrew, Nikkud Hebrew for poetry, students, and children, and invitational Hebrew for birthday, bat mitzvah, and wedding invitations.

I think that MS VOLT and OpenType is the tool and font format to let our imaginations go wild. Contextual replacement is the key to everything, as I imagine that Thomas is exploiting for Arabic.

On a different topic, I think Multiple Master technology failed because certain letterforms, like the m and w need wider widths and radical design changes at small point sizes in one direction, and a totally different set of rules for narrower widths and different letter designs for larger point sizes in the other direction.

DBerlow, is this what you had in mind in part?

gohebrew's picture

Somebody asked me in private. I gave this explanation, and thought that others would wonder the same thing.

>> "I don’t know the details of what Thomas Milo is doing for Arabic in
OpenType, but it must be, as the Israelis say: 'Mamash.'"

> What does this mean?

I am sorry for not explaing myself earlier.

"Mamash" is a Hebrew term for "actual" or "real".

The Israelis use it as a super-complimentary explaim about something which they consider very great, something like the Americans say: "Wow, cool!" Or in yester-year: "Keen!" "Groovey!" [Dis people really say that?] Or the British: "Jolly good!"

But for the Israelis, it is even more superior. I am sure in Europe or Arabic, you have an equivalent term.

=====
NOTE:
=====

Like most every Hebrew term that Israelis use, "mamash" has its origins in Biblical writings. In this case, "mamash" originates in the Biblical commentary of the great medieval sage, Rabbi Shlomo Yitchaki, who questioned how G-d was able to fool Abraham to think that his guests were ordinary Bedouins when actually they were angels? Rashi (as he is known by this acrostic of his name) explained that G-d dressed the angels in human bodies, using the phrase: "the 'mamash' of the angels".

["Mamash" also has a negative connotation among well-versed Chassidic Jews. Rashi's comment: "the 'mamash' of the angels" refers to the "waste of the angels", based upon a profound kabbalistic teaching that this world results from the waste or excrement of the spiritual world above it, and that spiritual world results from excrement of the spiritual world above it, etc. As this can be interpreted derogatory, I specified how the Israelis use it, to emphasize only the positive meaning] :)

billtroop's picture

Hi Israel, just for the record, I want to clear up the point you raised here:

>On a different topic, I think Multiple Master technology failed because certain letterforms, like the m and w need wider widths and radical design changes at small point sizes in one direction, and a totally different set of rules for narrower widths and different letter designs for larger point sizes in the other direction.<

The design differences for m and w over large axes are not so great that they have not been resolved by slight compromises in design at the axis extremes -- or even without compromise. However, when the letter really does need to change, Adobe (but almost nobody else) used an intermediate master. This was first implemented in ITC Garamond MM for the w.

An impeccable source who would probably prefer to remain unnamed has definitively explained Microsoft's historical reluctance to support MM in OT. One major reason was that neither MM nor Variations gave Microsoft the kind of hinting quality it was looking for. Microsoft thought that optical variations could (for which you might read would) add much to their quest for better screen quality, but not until they could be hinted better.

That is an entirely understandable position to take, especially given the vast amount of work MS has put into screen quality. Adobe didn't come up to the plate on that. Another point, but one I find less acceptable, is that "proper support" (by which Microsoft really does mean proper support) would mean 'we needed to seamlessly integrate it throughout the whole font API in Windows. This would mean adding additional "font state" for every API, and/or adding additional APIs (ExtExtTextOut was just too much!) This would have been a large testing/architectural hit for, in my opinion, something not used by many customers. (I agree that this is a catch-22 situation)'

That's not so easy to accept because adequate (if not proper) support for MM was already automatically present for all Windows apps via ATM (built-in or not). But Microsoft's hinting concerns _were_ important.

Finally, when you consider that while Microsoft was not willing to dump its MM customers (to the extent that Vista still supports MM via ATM 4.1 if UAC is turned off), but that both Apple and Adobe are willing to dump MM customers, you can see where Adobe would prefer to sit on its hands rather than do any extra work for other companies. This has been a traditional cultural problem for Adobe: it wouldn't support MM development in Fog; it wouldn't support MM usage in anyone's apps; it wouldn't add value to OT STD fonts because that would benefit other foundries; it wouldn't support ATM or MM in OS X; there are countless other examples of its cutting off its nose to spite its face -- but they can all be understood when you realize that Adobe's gut allegiance is to closed standards. Never forget that John Warnock cried when he made the public announcement that the Type 1 spec would be released. Time and time again, for 16 years, I have heard the same thing from dozens of companies: "Adobe wouldn't give us the support we needed." And that's of course why ATM is built into Adobe's apps: that way, MMs can work within Adobe's apps (though not elegantly) but not necessarily in other companies' apps. Obviously, the last thing we want is a font format that only works in Adobe's apps.

Dropping MM support was not a popular move, and the executive who made the decision, a tosser (as they say in England) called Dan Mills, was soon thereafter let go.

So whatever the reason MM or a superior technology is not, at present, with us, it's not because of the shape of m and w.

Anyway, that's why MM lost out in the late 90s. But going back in history, there are other reasons. Apple's GX supported both MM and GX variations superbly and fully at the OS level. GX gave you all of that plus essentially everything that OT provides.

Microsoft strongly desired to license GX for Windows 95. So we could basically have had everything we want and still don't have in font technology on August 24, 1995, except for one thing:

Apple wanted too much money -- even for Microsoft -- and there were some other fancy restrictions they wanted to place on the technology. But they were within a heartbeat of agreeing on a deal that would have benefited us all colossally (not just as regards fonts; GX made much of advanced application programming ridiculously easy).

Remember how Apple wanted too much money for Firewire? That's why we have USB2, which nobody wanted to design.

Apple lost out -- because GX didn't ultimately benefit it -- and MS lost out because it had to redevelop the technology in a much less elegant manner that 13 long years later is still not there. (GX took only 4MB of additional memory!)

What's the greatest argument in favour of MM? Well, today, it's that I just sent a font to someone. He asked, 'could it be a little darker?' -- sure it could, if he wasn't on a Mac.

I suppose the moment will never come again when there could be a unified graphical technology and programmer toolbox for MS and Apple.

What a pity! It was so close!

k.l.'s picture

When this old discussion was revived I read all of it and was a bit surprised how DecoType's ACE was completely misunderstood. I consider one misreading as particularly serious because it obscures ACE's biggest advantage compared to OT.

In a couple of comments throughout this discussion I see this inference at work:
(1) "Complex script" OT fonts are hard to make, & slow in performance when used.
(2) ACE fonts do (for OT-trained minds like mine) even more "complex" things.
(3) Hence ACE fonts must be harder to make, and performance must be worse.
This were true if -- as implied by an unspoken premise -- ACE's layout logic were identical with OT's layout logic. But this is not the case. Unlike OT layout tables, ACE is built on a few simple (albeit "meta") ideas and has a clean, straightforward mechanism, the most elegant one I have seen so far.

Given this, another conclusion, though meant to be praise, is almost an insult:
Use OT for everyday stuff that does not need much sophistication, and reserve ACE for high-end typesetting with all bells and whistles.
Again, this is a conclusion that is drawn from experience with OpenType layout technology, which indeed suggests -- whenever "extras" are not required -- to reduce complexity of features to avoid performance issues (and keep production efforts at a reasonable level). Since ACE is a very clean and simple architecture, making this distinction between less and more sophisticated/complex fonts does not make sense. For ACE, it just does not matter if there are a few alternates less or more. And the tricks it does with attachments are applied to very simple fonts as well as very complex ones. No difference there.

I even wonder if talk about "complex" fonts originated in an OT environment -- because OT layout table logic makes some things complicated. OT layout tables have a big problem: their "simplicity". They literally scratch on the surface -- they try to mimic a script's appearance by accounting for every single tiny adjustment needed to achieve this appearance. E.g. by minutely defining that this mark must be attached to this base at this coordinate. This is evidently simple (in terms of "common sense") but does not account for the fact that some scripts require so many of these tiny adjustments, which even need to interact which each other, that it is suicidal to mimic "complex" layout behavior on the level of tiny adjustments.
ACE in contrast digs deep into the structure of a script, and rather than accounting for this or that tiny adjustment, it sets out with some very global observations about layout behavior, e.g. it knows that there are base glyphs, to which marks need to attach -- somehow. Btw, Milo explains all ideas behind ACE in his papers.

Regarding Nadine Chahine's comment "one does not need complex technology to make good Arabic typefaces", this seems true. Yet I think it should not be a type designer's technical competence that determines whether he can make this or that kind of typeface. Since there is no difference between simple and complex in ACE, it is the design that decides what it needs, not the designer's technical competence.

Karsten

Thomas Milo's picture

http://www.maplandia.com/turkmenistan/chardzhou/mamash/

Any turcologist could have told you.

Thomas Milo
DecoType
www.decotype.com

gohebrew's picture

Thomas,

Hey, that's not the "mamash" I meant.

I doubt if any turcologist would know the Hebrew meanings of "mamash".

===

Seriously, though, could Ace technology be used for (Biblical) Hebrew where sophisticated contextual replacement would solve certain obstacles that seem to be beyond the scope of OpenType? Such as a string of 9 glyphs (or less) needs to be replaced either by a devoted ligature or be a different set instructions on how the 9 glyphs or less should be handled.

Thomas Milo's picture

John wrote earlier:

"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 is not correct. We set out to emulate what Middle Eastern typographers were able to do. All Middle Eastern typography was focused on direct modeling of the classical calligraphic styles, nothing less. Quite specifically, we were inspired by a personal document written and typeset by Ohanis Mühendisoğlu in which he explains and proves how he did it.

Elsewhere on typophile I placed images of Mühendisoğlu's naskh and (nas)taʿlīq typefaces that unambiguously prove his: he directly modeled both the rules and the order of the classical calligraphic styles.

Mühendisoğlu's naskh became the mother of all naskh typefaces. In the Aramco World article about Tasmeem, you can find illustrations how he inadvertently left an idiosyncrasy in his design that can be found in practically all later Western naskh typefaces.

Syndicate content Syndicate content