Critiques of the OpenType format?

Primary tabs

118 posts / 0 new
Last post
Idris Samawi Hamid's picture
Joined: 12 Dec 2005 - 10:57pm
Critiques of the OpenType format?
0

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

Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

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

Laurie Schwarz's picture
Offline
Joined: 9 Jan 2006 - 6:39pm
0

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.

Karsten Luecke's picture
Offline
Joined: 6 Aug 2005 - 8:41am
0

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.

Mark Simonson's picture
Offline
Joined: 3 Dec 2001 - 11:00am
0

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.

paul d hunt's picture
Offline
Joined: 5 May 2005 - 8:44pm
0

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

Idris Samawi Hamid's picture
Joined: 12 Dec 2005 - 10:57pm
0

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

Karsten Luecke's picture
Offline
Joined: 6 Aug 2005 - 8:41am
0

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
Offline
Joined: 24 Oct 2007 - 1:58pm
0

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

Any turcologist could have told you.

Thomas Milo
DecoType
www.decotype.com

Scott "Israel" Seldowitz's picture
Joined: 7 May 2007 - 12:08pm
0

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?

Thomas Milo's picture
Offline
Joined: 24 Oct 2007 - 1:58pm
0

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

Scott "Israel" Seldowitz's picture
Joined: 7 May 2007 - 12:08pm
0

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
Offline
Joined: 24 Oct 2007 - 1:58pm
0

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.

Scott "Israel" Seldowitz's picture
Joined: 7 May 2007 - 12:08pm
0

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

Bill Troop's picture
Offline
Joined: 20 Jun 2004 - 12:32am
0

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!

Khalid Muhammed Khalid's picture
Joined: 29 Dec 2010 - 7:15am
0

Thomas Milo wrote:

"We - the DecoType team - set out to design Arabic typography, not calligraphy."

Then, ACE should have been more appropriately called "Arabic Typographic Engine", ATE for short.

K

Idris Samawi Hamid's picture
Joined: 12 Dec 2005 - 10:57pm
0

accidental post-)

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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.

Reynir Heiðberg Stefánsson's picture
Joined: 19 Nov 2010 - 11:15am
0

Of course I would miss it. Go fig.

Reynir Heiðberg Stefánsson's picture
Joined: 19 Nov 2010 - 11:15am
0

Where does thia quote come from? I do not see it in the text here.

Maya Alexander's picture
Offline
Joined: 21 Jan 2015 - 11:55pm
0

I am working on a project of parking. What would be the technical suggestions for this topic? You can take the reference from http://www.bestmeetandgreetgatwick.co.uk/

Khalid Muhammed Khalid's picture
Joined: 29 Dec 2010 - 7:15am
0

Actually, I'm in the wrong place. I made my earlier comment on ACE in passing after reading what Thomas Milo said about it some time back.

Thomas also mentioned Mühendisoğlu here and this is what actually brought me in the first place. It seems that all references to Ohanis Mühendisoğlu on the internet will direct you to Thomas Milo!

However, since this thread has been dormant for some time and is about OpenType, I do not want to dwell much longer on this obscure historical figure, Mühendisoğlu, here and will direct my remark to probably a more appropriate thread where again TM finds it opportune to talk about Mühendisoğlu. Those who are interested might wish to join:
http://typophile.com/node/57013

Finally, on OpenType I would like to mention that it is interesting to note that some of the vision that ChrisL and others had in the beginning of the thread 10 years ago about OpenType has actually been realized.

Cheers.

K

Khalid Muhammed Khalid's picture
Joined: 29 Dec 2010 - 7:15am
0

See TM 29 July 2008.

Anyway, I just learned that ACE now stands for "Arabic Composition Engine".

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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.

Sergey Malkin's picture
Offline
Joined: 17 Feb 2004 - 2:07pm
0

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

David Berlow's picture
Offline
Joined: 19 Jul 2004 - 6:31pm
0

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.

Simon Daniels's picture
Offline
Joined: 11 Apr 2002 - 6:37pm
0

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

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

David Berlow's picture
Offline
Joined: 19 Jul 2004 - 6:31pm
0

"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)

Raph Levien's picture
Offline
Joined: 8 Aug 2004 - 11:00am
0

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.

Idris Samawi Hamid's picture
Joined: 12 Dec 2005 - 10:57pm
0

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

Idris Samawi Hamid's picture
Joined: 12 Dec 2005 - 10:57pm
0

PS

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

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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.

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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

Thomas W Phinney's picture
Joined: 3 Sep 2002 - 11:00am
0

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

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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

David Berlow's picture
Offline
Joined: 19 Jul 2004 - 6:31pm
0

"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.

paul d hunt's picture
Offline
Joined: 5 May 2005 - 8:44pm
0

dream format: multimaster opentype fonts.

paul d hunt's picture
Offline
Joined: 5 May 2005 - 8:44pm
0

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

Idris Samawi Hamid's picture
Joined: 12 Dec 2005 - 10:57pm
0

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

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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

David Berlow's picture
Offline
Joined: 19 Jul 2004 - 6:31pm
0

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.

Ian Blair's picture
Offline
Joined: 20 May 2003 - 11:00am
0

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?

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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 Berlow's picture
Offline
Joined: 19 Jul 2004 - 6:31pm
0

"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.

Carl Crossgrove's picture
Offline
Joined: 8 Sep 2003 - 2:07pm
0

David,

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

Carl Crossgrove's picture
Offline
Joined: 8 Sep 2003 - 2:07pm
0

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

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

Ah, but I bet I can turn it down.

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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?

Dan Reynolds's picture
Offline
Joined: 20 Jul 2002 - 11:00am
0

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? ;-)

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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

Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

John hacks his own font for posting :-)

ChrisL