Typophile - Critiques of the OpenType format? - Comments

Thomas, Hey, that’s not

gohebrew — Sat, 16 Aug 2008 23:31:47 -0700

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.

http://www.maplandia.com/turk

Thomas Milo — Wed, 13 Aug 2008 05:06:04 -0700

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

Any turcologist could have told you.

Thomas Milo
DecoType
www.decotype.com

When this old discussion was

k.l. — Mon, 11 Aug 2008 15:50:07 -0700

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

Hi Israel, just for the

billtroop — Mon, 4 Aug 2008 12:09:43 -0700

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!

Somebody asked me in

gohebrew — Mon, 4 Aug 2008 08:46:23 -0700

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] :)

I don’t know the details

gohebrew — Sun, 3 Aug 2008 19:35:10 -0700

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?

I recently noticed this

Thomas Milo — Tue, 29 Jul 2008 13:24:29 -0700

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.

Thomas Milo
DecoType
www.decotype.com

“Karaoke is a technology

dberlow — Thu, 2 Feb 2006 04:52:31 -0800

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

Karaoke is a technology 99%

sii — Mon, 30 Jan 2006 08:56:54 -0800

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

From the links to the ISO

dberlow — Mon, 30 Jan 2006 04:48:18 -0800

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.

Thomas writes, ‘I’m not

billtroop — Sat, 28 Jan 2006 00:41:20 -0800

Thomas writes,

’I’m not going to respond to Bill’s comments and speculations, regardless of the truth or falsehoods in them. I did a big public presentation at ATypI a while back on why MM fonts went away, and I was there when the decisions were made. Bill can believe what he wants.’

Thomas, I think you should hold the heat. This is a pretty fact-oriented discussion and anytime someone says something that someone else doesn’t understand or disagrees with, there is appropriate give and take until the issue is worked out. We can all understand if you just want to vent ire, but if you have a specific problem with something I’ve said, tell us what it is, and back up your position with some verifiable facts. Do not waste everyone’s time with ’I forget how that worked’ kind of remarks. 1. you should know. 2. you should spend the two minutes it takes to find out before you waste the bandwidth. Everyone realizes that you are not one of the towering intellectual giants of type development. But tidier mental habits would bring you a lot closer to that goal, and your intellect, functioning at its possible best, is desperately needed in the type industry. In the meantime let’s focus on what is so importantly emerging here, a potential synergy between Berlow and these TeX people.

” TeX may implement, for a

dberlow — Fri, 27 Jan 2006 07:09:31 -0800

” TeX may implement, for a given advanced script, a generalized model, and users can give the parameters for a given font.”

I see. I think this should say:
TeX may allow the implementation of a generalized model,for a given enriched opportunity script ;). Then, typographers can create fonts and the typogrphy required for this opportunity, and users can interact if they need to with the parameters for a given font’s typography, or in cases of extremely rare opportunities, with individual characters within the font, but in general, the user’s are specifying no more than line length, leading point size and other “last opportunity” variables, and the font/TeX takes the other cares away...

“Hmm. David and Thomas, are you saying that Chinese language programs assemble Chinese characters on the fly from radicals?”

Hmm? There are some for sure, that assemble on-the-fly, which is to say, when the character is called by the font manager little parts recipies and interpreters whirl out Chinese glyphs. My guess, is when the MS and Apple fonts were being specified, the imagination of the specifiers was to ask the Japanese partner for “The” definition of “Quality”. That definition was of fonts made in digital format to mimic a size of a font made for metal or film. Narrow specification complete for wide application, figure out the input your selves... Other font makers “over there” have other standards of quality more appropriate to applications outside of print, where vast glyph armies that don’t scale, rotate, skew, contour, shadow or color well, are... less useful to the market.

Hmm. David and Thomas, are

William Berkson — Thu, 26 Jan 2006 12:55:40 -0800

Hmm. David and Thomas, are you saying that Chinese language programs assemble Chinese characters on the fly from radicals?

I don’t think this is true. Also it seems mind-boggling to think of a program that could do this, given that there are none, it seems, that automate kerning and bolding that well. Assembling the radicals would also involve rescaling as well as bolding and thinning, and the characters splash around more than roman, so the fitting problems would be greater.

In ’Now Read This,’ on the new Microsoft Clear Type fonts, they say that the Kanji characters (= Han Zi = Chinese characters) for the font Meiryo were drawn by a team. The first 3000 were drawn, and “carefully analyzed as models to make subsequent production of the rest as automated as possible.” The others were produced by the Japanese firm C & G, “using their in-house automated production method working with the analyzed data of kanji radicals.” I gather from this that they needed additional information on each radical—perhaps for just this typeface—as to how to scale it, and perhaps also needed to look and correct.

In any case the all the Kanji characters are in the font, and not assembled on the fly. As I said, Chinese is input using the Pin Yin romanization, and I would guess that Japanese is input using the Japanese alphabet, hiragana, rather than radicals.

Thank you John. I fixed it

ishamid — Thu, 26 Jan 2006 12:54:42 -0800

Thank you John. I fixed it but the algorithm is still inconsistent: “” works for dbl-grave+dbl-apostrophe but the analogous situation does not work for sngl-grave+sngl-apostrophe. Indeed, I cannot input a single quote pair at all without a context. More consistent would be to force the use of the dbl-quote symbol twice, which does work.

So the typophile algorithm should either remove the dbl-grave+dbl-apostrophe or add support for sngl-grave+sngl-apostrophe==>left-right quotes.

Best and Thnx
Idris

The font that typophile.com

John Hudson — Thu, 26 Jan 2006 12:41:24 -0800

The font that typophile.com uses a right single quote that is out of harmony with the left single quote. I think that a site like this one should look into that

Idris, ‘ is not a left quote, it is a grave accent (U+0060). You should use the ’ (U+0027) key for both left and right quotes, and let the clever algorithm figure out how to display them ’thus’.

Critiques of the OpenType format?

ishamid — Fri, 16 Dec 2005 14:23:10 -0800

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