My comment comes about after 10+ years of having small caps in the basic font, so you can rightly assume I'm prejudiced in favor of that structure, and have worked out acceptable compromises for any problems that occasions. I imagine people who have used type differently may feel otherwise.

When we first started using PostScript Type 1 fonts, I decided that all glyphs in a font (e.g., roman, italic, bold, etc.) should be in one font database. This minimized several maintenance issues; if you were going to make a change in cap-cap kerning, or cap-punctuation kerning, there would only be one place to make the change.

Since our typesetting program would only handle 255 characters in a font, we did had to make a separate small cap font for setting type, but we could build the font change into the "go to small caps" command, so this "font" was both temporary, and a purely technical matter. For any job, making up a job-based small cap encoding vector allowed us to encode whatever style of numbers were needed -- or we could make up two small cap fonts, one for text, one for subheads, each using different figure styles, etc.

If OpenType were to move to a separate font for small caps, I think we'd lose some of that flexibility, which is now essentially programmable with OT features.

I realize most people don't make up database fonts, or don't modify existing OT fonts even when the EULA permits. And I allow it can be a bit of a nightmare to go into an existing OT font & change the kerning, but it often times has to be done, to avoid much handwork.

In short, one of the things I like about the OpenType format is its database structure, and would not want to give that up.

Best,

Charles Ellertson

Adam, with all due respect: this idea is pathetic!

Miguel,

with all due respect, you wrote:

> this idea is pathetic!

As I explained earlier, there are some designs that only come with uppercase and smallcaps but without lowercase. This includes Chevalier, Bank Gothic or Adobe’s own Sava Pro and Trajan Pro.

Sava Pro has no lowercase, just uppercase glyphs (associated with uppercase Unicode codepoints) and smallcap glyphs (associated with lowercase Unicode codepoints). In addition, Sava Pro contains a smcp feature that replaces figures and punctuation with smallcap variants as well as a c2sc feature that replaces uppercase, figures and punctuation with smallcap variants (the smallcap letters are named "A.sc", "B.sc" etc., and are identical duplicates of the "a", "b" etc. glyphs). Was it Jovica Veljović's idea, the designer's of this typeface, that — in your own words — was "pathetic", or was the "pathetic" idea by one of the font engineers at Adobe who wrote the feature definition code that implemented it? Please make sure to find out who it was, and tell him that.

Or wait, was it perhaps the guy who wrote the feature definitions for Trajan Pro? Because this is also exactly how Trajan Pro is implemented (smallcaps on lowercase glyphs, c2sc, smcp & case features; the difference from what I suggest is that the case feature does not covert the letters in those fonts, nor do the fonts include a titl feature, but those really are implementational details). Was this idea "pathetic"?

Or do you think that designing a typeface with only uppercase and smallcaps is "pathetic" itself?

Rather than proposing something entirely new, I’m trying to suggest what developers should do better to implement what they’re doing already. Underware ships separate smallcap fonts for Fakir or Auto. Other vendors like Elsner+Flake or URW++ do the same. However, these fonts do not offer functionality such as all-smallcaps (through appropriate features such as c2sc). My suggestion tries to improve that situation, and I follow the examples set by Adobe in Sava Pro and Trajan Pro.

Or do you think it is "pathetic" that four major versions of Microsoft Office since the inception of OpenType (2000, XP, 2003 and 2007) have not offered proper access to smallcaps?

I’ve seen people revert to drastic methods like using Visual Basic macros in Microsoft Word that replace lowercase Unicodes with PUA codepoints that Adobe used for smallcap glyphs -- a practice that obviously bastardizes the underlying text string and makes the document unsearchable. Do you think my idea that avoids this problem is more "pathetic" than these solutions?

Finally, I would most kindly ask you to explain me, where exactly my posting contradicts the OpenType specification. I'd prefer to hear some substantial arguments from you, but if you feel more comfortable with name-calling, please go ahead. I can take it.

Really: please find the guy at Adobe who wrote the feature definitions for Sava Pro and Trajan Pro, and please tell him that his idea is "pathetic". And then kindly report back what he said. I'll take care of forwarding that very eloquent comment of yours to Jovica Veljović.

Kind regards,
Adam

Right Adam.

There's no need to include alternate characters, such as small caps, in a font unless there is contextual interaction (via kerning, or OpenType features) with the basic characters.

I'm considering a typestyle with two sizes of small cap. I'll put the usual "small caps" in the standard font, and the other, which I will call "middle caps" in a font suffixed -MSC.

That will be easier for me to do, and easier for the end user, for many reasons.

But this has nothing to do with your feature definitions!

Ps. In case of Auto, the designers (Underware) created the uppercase, smallcaps and lowercase at the same time, so it was merely a choice of packaging that they decided to place the smallcaps into a separate font. But there are typefaces that get developed gradually. Trajan was originally developed as an uppercase-only font. Later, the smallcaps were added. One could imagine, that in a yet-another iteration lowercase is added to such font. For example, Aldo Novarese's Microgramma was originally released as a small-caps typeface, and lowercase was added several years later, after the typeface proved to be successful.

Smallcaps practically never interact with lowercase in one font. Smallcap punctuation and figures mostly needs to be drawn separately, so an uppercase+smallcap glyphset is an independent being from an uppercase+lowercase glyphset, just like an slanted-uppercase+italic-lowercase glyphset is a separate being.

It is a matter of preference and convention that in the Western markets, we put italic glyphs into separate fonts from upright glyphs, while in the Japanese markets, italic and upright Roman letters are often put in the same Japanese font, which then uses the ital OpenType feature to switch between these. This clearly shows that even between upright and italic, the border is not that hardly drawn.

The same applies for smallcaps: sometimes smallcap designs are not at all subordinate to lowercase but are a separate being, conceptually. They have different spacing, different figures, different punctuation. They only share uppercase letters with the roman design. So contemplating whether to put smallcaps as a subordinate set in the roman font, or into a separate font, are not out of question. Miguel may think that ideas such as Novarese’s are "pathetic" but there are enough designers out there who think otherwise.

The point I'm making is that if you decide to publish your smallcaps in a separate OpenType font, the font should also include some relevant features, such as c2sc and even smcp.

The question how you package your final font has little to do with how you design your font. Of course you can have the small caps and the lowercase in the same font file during design, just like you wouldn’t have two sets of small cap glyphs while you’re designing. During design, you would often use Multiple Master. After the design is done, many technical steps need to be done, such as generating single instances from MM, separating fonts, duplicating some glyphs, removing others etc.

The difference between "database fonts" and final products still exists, and will continue to exist.

A.

Nick,

increasingly, I tend to think about smallcaps being (conceptually) something like optical sizes of uppercase. I mean, they’re actually what they originally were: smaller capital letters. They’re "smaller" not by mere geometric scaling, but they’re "typographically smaller". Just like you can either put your body-sized glyphs and your display-sized glyphs into the same font (Adobe Garamond Pro, titl feature) or you can put them into separate fonts (Garamond Premier Pro Regular and Garamond Premier Pro Display), you can have the flexibility to decide what to do with smallcaps. In your case, you could consider having lowercase in one font, one set of smallcaps in another font, and the other set of smallcaps in a third font, or you could merge one of these smallcap sets into the lowercase font. It’s up to you.

A.

> Or do you think that designing a typeface with only uppercase and smallcaps is “pathetic” itself?

No. What I find pathetic is the suggestion of putting the small caps in a separate font.

> Or do you think it is “pathetic” that four major versions of Microsoft Office since the inception of OpenType (2000, XP, 2003 and 2007) have not offered proper access to smallcaps?

Yes, definitely!

> that replace lowercase Unicodes with PUA codepoints that Adobe used for smallcap glyphs — a practice that obviously bastardizes the underlying text string and makes the document unsearchable.

Exactly, that's one more reason we stopped using PUAs.

> Do you think my idea that avoids this problem is more “pathetic” than these solutions?

I strongly believe that your efforts would have a stronger impact in the long run if you'd focus on pushing things forward, rather than resorting in workaround methods. I definitely don't see your proposal as a "solution". It is a hack that sends us back to the time when we had to rely on Expert fonts and the like. I don't think your solution does a good service to the users.

Here's a suggestion, start a new thread with the goal of uniting as many supporters as you can, to demand (yes, that's the word) full support of the OpenType spec. You might also want to do a poll to have an idea of which ones the users and/or developers would like to see implemented first. Then, in unison, flood all the major app developers with your (everyone's that is) requests. Here's Adobe's: http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

To me, this would clearly be a better usage of the bandwidth.

As for the Sava Pro and Trajan Pro examples you mention, have you ever heard me saying that a typeface without lowercase forms is pathetic? I'm failing to see the reasoning that led you link the two.

One other thing you should be aware of, is that you're basing some of your key reasons in what you find inside a few Adobe's fonts that were built many years ago, when OpenType was in its infancy. Therefore, the code that went into those fonts might not reflect the current best practices (which is one reason why we're currently revising the whole library).

> I’m considering a typestyle with two sizes of small cap. I’ll put the usual “small caps” in the standard font, and the other, which I will call “middle caps” in a font suffixed -MSC.

Nick, this sounds like a good case for a Stylistic Set.

P.S.: In the same font!

I tend to think about smallcaps being (conceptually) something like optical sizes of uppercase.

I think this is over-simplified. Are you suggesting that, assuming a small cap height of 75%, the small caps for 12pt are the same as the capital letters for 9pt?

That is certainly not the case. The capital letters of the 9pt size (if optically compensated) are wider and bolder than the 12pt ones but the 12pt small caps are even wider, heavier and have longer serifs than the 9pt capitals.

The small caps compensation is different (generally stronger) than the optical sizes compensation.

Not sure whether to post this here or there ...

Of course one could send particular feature requests to Adobe or Microsoft or Apple. But what is important is that Adobe and Microsoft and Apple finally agree on something -- which would affect both font and layout engine design.

Just a recent example:
'case' is differently implemented in Adobe fonts and in Microsoft's Cleartype fonts (also adopted in new fonts from a major foundry). Adobe's implementation also covers substitution of oldstyle by lining numerals, so that numerals match uppercase glyphs. Microsoft's implementation only cares for punctuation &c but not for numeral substition. As an effect, if you use the latter in Adobe applications and apply All Caps, you will receive uppercase letters in combination with oldstyle numerals.
This nicely indicates dependency of the way fonts are built and the way OT features are implemented in the application (it is more than a mere 'UI' thing): While the Adobe method assumes that an application's All Caps option calls 'case' (and 'cpsp') only, the Microsoft method assumes that All Caps calls both 'case' and 'lnum' to give a typographically correct result. [The latter is my conclusion. No idea what Microsoft has in mind. And unless they finally support typographic OT features in their applications, this is an issue that cannot be decided upon.]
Other issues: implementation of 'cpsp' (if at all) and 'ss**' (mutually exclusive or additive).

Things like these are not solved by mere feature requests to one company. What is required is that font plus layout engine developers of the three have a nice day together, with coffee, tee, biscuits and cake, and go through the set of currently supported OT features one by one, and compare the way OT features are addressed in their applications. If there are differences, try to agree on one solution. I think the set of features supported (InDesign CS2 and WPF specs) does not differ that much any more, so there already is a solid common ground.
This is something that cannot be done from outside.

I am a bit oldfashioned and prefer to write someone who I know really exists instead of filling in some form.  :)

Karsten

Smallcaps practically never interact with lowercase in one font. Smallcap punctuation and figures mostly needs to be drawn separately, so an uppercase+smallcap glyphset is an independent being from an uppercase+lowercase glyphset, just like an slanted-uppercase+italic-lowercase glyphset is a separate being.

It is a matter of preference and convention that in the Western markets, we put italic glyphs into separate fonts from upright glyphs, while in the Japanese markets, italic and upright Roman letters are often put in the same Japanese font, which then uses the ital OpenType feature to switch between these. This clearly shows that even between upright and italic, the border is not that hardly drawn.

Depends on what you mean by "interact." It is true that you usually don't find both a small cap and a lower case letter in the same word. I know of one publisher who banishes small caps for acronyms if GmbH appears in the text. But you do find both in the same sentence, in justified copy. Now a usual convention is that small caps are slightly letterspaced, and the letterspace instruction works on the spaceband character as well, so everything works pretty well. Italics on the other hand, often are narrower than thier roman counterparts, and can take a smaller wordspace value -- all this in justified copy. When the composition system picks up the spaceband value from the font, it is a plus to have a separate italic font.

A different situation occurs when the small caps are used for subheads. In fact, back in the linecaster days, Linotype sometimes cut two versions of small caps (in the same size), one to be used for text, the second to be used for subheads. I beleive Linotype Caslon had this feature.

In this context, having a separate small caps font makes sense, just like having a separate titling font makes sense. But small caps designed to run in justified copy should be included in he basic font, and should be designed to work with the lowercase letterforms.

Maybe the reason why we feel that italics should be a separate font is that in general every glyph has a counterpart in the other font. Therefore we can consider the italics, bold versions and optical sizes a global variation that justifies globally switching to a different font.

Small caps are just a few glyphs tewaked to match or harmonise with others in the same font and they belong to the other glyphs in that font stylistically in every aspect. The fact that putting small caps into a separate font results in redundancy (identical glyphs in both fonts) is probably what makes some people feel that practice is wrong.

Damn,
I just wrote a long post that failed to post because the site timed out while posting. I am to pisßed to retype it now :-(

ChrisL

I am to pisßed

Chris, shouldn't that be "too pißed"?

LOL! Yes Charles, that was my first take at it. My concern was with folks who did not see the double ess and thought it might be a B. Europeans would easily read the ß but some Americans might get pißed for seeing piBed :-)
See what happens when you try to work around the sensoring software?

ChrisL

PS: the to instead of too was just a screwup :-)

Depends on what you mean by “interact.”

Quite literally, effect each other's behaviour.
So yes there are very rare exceptions, such as GmbH in "lc+sc", and also perhaps some uses of "Mc".

My concern was with folks who did not see the double ess and thought it might be a B.

Dude, this is Typophiile!

Yes, home of Missgigles :-)

ChrisL

Adam,

I think you underestimate amount of work associated with placing smallcaps into separate font. In addition to punctuation, you will have to add another copy of diacritics, mark attachment lookups, capital letter kerning, different numeral styles, etc.

If your real goal to have smallcap font working in non-OT savvy applications, the best approach for me is to put two fonts into ttc file, and have only different cmap table mapping lower case characters to smallcap glyphs. Shared glyphs, layout tables, metrics will allow both fonts to have full functionality and behave well in different types of applications. So, you will have this smallcap font to be a simple addition to the main, fully functional font.

Thanks,
Sergey

Adam, I applaud you for bringing this issue up, because the Small Caps feature embedded in the OpenType feature menu is one of my pet peeves.

Small caps are just a few glyphs tewaked to match or harmonise with others in the same font and they belong to the other glyphs in that font stylistically in every aspect.

Tim, I must respectfully disagree with this. Small caps are as much of a style difference as Roman and italics. They often require their own complete set. I'm sure some type designers would agree with that. You also have to take into account that small caps may also have different numeral sets than the Roman counterpart, not to mention initial caps (which is another debate entirely.)

I can't talk much about the coding issues discussed (because quite frankly I don't understand any of it) but from a USER standpoint, the small caps feature— I'd be happy if it went away. I want to see it as a seperate font in the pull down menu— like the old days. This feature wasn't broken, so why did it get fixed?

I don't want anyone to be offended by this, but the user seems to always get the short end of the stick here. Programmers and users do not speak the same language. What is ironic here is that something that was probably done to be more convenient, is actually less convenient.

Do a user survey of graphic designers (and Typophile is not the best place because we're more type savvy than most). I think you'll find a lot of graphic designers will share my view here.

Some pressure could also go towards Microsoft, because honestly their lack of concern in regards to OpenType in their software applications has caused enough headaches in graphic designer's daily lives. Its really inexcusable.

Oh, and Chris..."Select all" and copy at certain points. That way its on your clipboard. (It's happened to me before too.) :)

I'm only a user, but in most instances I'm very glad that small caps are in the font. The few instances I'd like small caps to be separate are when I set enough of a block that I find myself needing small caps punctuation. But, traditionally (and in my own viewpoint), small caps shouldn't be used to such an extent. The magazine, STEPInside Design, has huge blocks of all small caps which suffer greatly from the punctuation not being aligned and sized for small caps. (Not to mention that those blocks are set too tight.)

Terry,

I too am a user only, but I suspect we occupy different ends of the *user* spectrum. I only work on books, and 90% of the small caps I set are run in to regular sentences. My guess is that 90% of the small caps you use stand alone on a line by themselves; what I would term display.

This points up the type designer's nightmare, at least if they are working on fonts that may have both text and display uses.

I also run into both italic and small cap occurrence that "interact" in the sense used here, i.e., letters that are set with roman letters with no space intervening (except what kerning we have to add by hand). This occurs in specialized instances; the analysis of poetry, phonetics, etc. I expect to have to fiddle with them in such cases, but the *design* needs to be compatible with the roman.

I just pulled out Adrian Wilson's The Design of Books where he shows Linotype's Caslon Old Face. In addition to the usual suspects, there are swash letters, lower-case roman and italic letters with long and short descenders, regular small caps, special two-letter small caps, single-letter italics (so they don't have to fit on the same matrix as the roman), special logotypes (what most of us would call ligatures, though strictly, ligatures are tied letters), and so on.

Obviously, this effort only makes sense for a text font, and some of these sorts were needed only because of the linecasting machine. But that aside, I'm beginning to believe that Adam is onto something, where the separate small-cap font is intended for display.

Small caps are as much of a style difference as Roman and italics.

So, what would you say is the stylistic difference to the other glyphs then? I would say they are specifically designed not to show any stylistic differences.

They often require their own complete set.

No, they never require their own complete set. I simply cannot imagine that anyone would ever do a smallcap-period, for example. The same goes for many other glyphs in a font.

My guess is that 90% of the small caps you use stand alone on a line by themselves; what I would term display.

You are right on the money, Charles. I'm glad to hear your take on it because I figured a book designer would have a different experience than I.

Tiff, STEPInside Design needs someone to step inside their design. :) It is lacking in comparison to Print and HOW.

I simply cannot imagine that anyone would ever do a smallcap-period, for example.

You got me, Tim! :) Punctuation, though I would think is an easy fix. (Though I am sure I could be wrong here.) I'd think the designer wouldn't mind going the extra mile if it improved functionality for the user.

Though I think the list can be somewhat cumbersome, I think Lucas De Groot's system for Thesis works best in regards to font styles:

Plain
Italic
Caps
Caps Italic

As an aside to this... Embedding small caps can also limit previews in font management programs. Something that you need to have a quick reference for in certain situations.

Biddy, I've been harping about your last comment lately, in that it boggles me that the major players in font management don't have a simple preview option for the complete character set. FontExpert almost has this, but none of the others I've come across even get close.

As for accessing true small caps in non-OT savvy apps, I don't really see the "urgency" seeing as most users of word processors (etc.) don't have a clue what small caps are anyway. Sure, it might be a way to "educate the masses," but, for the most part, the masses aren't interested. While selfish, what I want is a font that makes my life easier where I need it to (in design software), and OT with small caps built in does that. Now, if only PS and Illustrator had the same (full) OT support that InD CS2 has...

> I simply cannot imagine that anyone would ever
> do a smallcap-period, for example.

Maybe not necessarily regarding the shape but very often spacing-wise.

A.

Adam, a good topic and interesting discussion. Unfortunately, I wouldn't sign up for that. As a type guy and a designer who has been using desktop publishing software for twenty years, I am quite glad to have small caps finally wrapped into the fonts. (And for that reason, I probabaly wouldn't mind having italics and bolds wrapped in there too -- but I don't want to have to make them!) It's just a matter of how this stuff is accessed, how much font you want to sell at once, and what you're used to.

Remember, many font companies don't just sell to professional graphic designers. They sell to font users of every strata. My guess is that a great majority of font consumers overall are glad to have the small caps built-in and not separate. Companies like Adobe want to make advanced typographic features available to more people, more easily, and it seems to me that a "small caps" button in a UI from a single font will get used more than a separately-installed font.

I really do think that most Adobe type customers are thrilled that all those separate Expert and SC fonts finally got folded together into single fonts. Encoding issues aside, it was a hassle, I think.

I don't mind that others have their preferences. I mean, if someone prefers small caps as a separate font, I don't think it's a character defect. If all those people want to make their opinions known and reveal that, in fact, most users want small caps as separate fonts, well, that would be very interesting. But I think there's an advantage to having these things consistent, so I would expect the status quo to prevail in the OpenType mainstream.

I would expect the status quo to prevail

Which particular quo though, MS or Adobe?

Christopher,

thanks for the feedback. I'm not convinced that OpenType Layout features are easier accessible in application UIs than single fonts. Single fonts have dropdown lists for families with arranged submenus that only list the styles included in a family (rather than listing 40 stub styles with square brackets around the styles that aren't present in the family, which is what is being done for OpenType Layout features in Adobe applications).

With WYSIWYG font menus activated, it takes just a quick glimpse of an eye for the user to judge what the visual styles of the characters are for all the fonts installed on the system, to find the one that matches the intended purpose.

The OpenType Layout feature selectors are usually buried deeper in the UI, they're not available on the "top level": in Adobe applications, some selectors are available on the top level but most are in an extra OpenType flyout submenu, while stylistic sets in InDesign even take two submenus to dig through; in Apple applications, the OpenType Layout features are buried in a small Typography palette that takes at least three clicks to access, so virtually nobody knows about it (even seasoned OpenType font developers are often stunned that TextEdit supports OpenType Layout features).

While there are countless ways (e.g. in font management applications or in the WYSIWYG font menus) to see all styles of a family, I know *no single* application for Mac OS X or Windows that would show you the glyph repertoires of fonts installed on your system arranged by OpenType Layout features. I even don't know any application that would, say, display or flag all the fonts on my system that support a particular OpenType feature.

Christopher, apart from writing my own scripts, do you know a way that I could see OpenType small caps for all fonts installed on my system somehow? Ideally in a way that I could check whether the font has small caps for plain English, accented Latin, or also Cyrillic and/or Greek. Please point me to a way that would let me discover all the Adobe OpenType fonts that have, say, Cyrillic small caps.

I must admit that personally, when designing publications using OpenType fonts, I find those limitations very cumbersome. I think OpenType is great whenever some machinery is involved (ligation, contextual substitutions, positioning), whenever some single alternates are needed, also figure styles (because there can be so many of them). But small caps really have such a dramatic impact on the appearance of the type, and are practically never mixed with lowercase in the same *word* (so kerning would be necessary).

In fact, a case could be made that italics would benefit much more than small caps from being placed in the same font as the upright glyphs. For example, it is very common in typesetting practice to enclose italic phrases in upright punctuation (quotation marks, parantheses etc.) or follow italic words by upright signs -- depending on the context, it is often the only correct way, e.g.

“Is this some schadenfreude?” he asked.

Kerning between the italic glyphs and the upright punctuation could solve many problems in typesetting, especially for clashes such as “f)” or “f!”.

You wrote in the other thread:
> With not too much trouble, an ‘ss**’ feature can
> be applied to a character style in InDesign, for
> example, and applied to the first letter of
> every paragraph with nested styles.

The same can be said for switching fonts to access small caps. I don’t see why it should be different to define a character style that uses a separate small font as opposed to one that switches on small caps using an OpenType feature.

As I said, I’m not saying that one solution is better than the other. All I’m saying is that small caps is a particular border case where arguments can be made both ways.

Best,
Adam

I must admit that personally, when designing publications using OpenType fonts, I find those limitations [getting information about whether or not small caps are available] very cumbersome

Adam, I can't imagine designing a publication without knowing the fonts I'm using pretty well -- how the characters space when set, let alone what the character compliment is. And I don't find WYSIWYG displays accurate enough to make spacing judgments, nor can I get a good sense of the page from a screen display -- printing out & trimming the sheet to the final size is the only way to be sure.

Perhaps this is a difference in book work?

I remember all too well the days of expert sets and search and replace to get formatting as desired. PLEASE, don’t go back to that! If you are working on anything more than a page or two, style sheets are a must [I use them even for 1 page jobs]. If you work with clients who make changes (well Duh!), style sheets are a must.
I recently repurchased a revised type family that we purchased originally in the mid 90s just to get the OpenType version. Much to my dismay, I found that all that had been done was to save the single files as opentype without making the expert sets part of the same font! Gawdhammit that pißed me off royally! The only features were kerning and the 2 basic fi and fl ligas. Here I am stuck with a friggin expert set again in 2007!
It seems that the problem of access to OpenType feature is more one of OS and App than of typeface design. Don’t throw the baby out with the bath water. Should Adobe, Microsoft, and Apple sit down and work out something sensible regarding GUI and OpenType features? Certainly. OpenType is just an infant now and the world it was born into has yet to come to grips with how to deal with it. The interface is wonky. Illustrator and InD don’t even do it the same way and both are part of the same Adobe suite!

ChrisL

OpenType is just an infant now and the world it was born into has yet to come to grips with how to deal with it.

Word. (Agreed.) So is there anyway to come to a solution for this? I agree with everything Adam just said in his last post, so...

How about writing our own code? I'm sure I'm not the only one who has thought of some other features they'd like to see built in OpenType.

Charles,

I find the opposite: in book work, I need to know the typeface very well. You usually just pick one typeface, and the typeface needs to work by itself, often with very little illustrations or photos. So the typeface needs to "sit" perfectly, the spacing is often more important than the graphic qualities of the face.

In magazine work, especially when prototyping different layouts and developing different design directions, publication designers often need to experiment a lot, sometimes mixing different styles for text and headline, and also trying different colors. I have spoken to full-time publication designers and book designers about their work, and from what I can tell, magazine layouts are among the most demanding when it comes to trying a large veriety of different typefaces.

Chris,

the search-and-replace thing you're mentioning was often because of ligatures. As I mentioned already, there are small-caps-only OpenType fonts, even from Adobe (Sava Pro, Trajan Pro) which are still conveniently equipped with appropriate OpenType Layout features so that ligatures, various figure sets etc. work as they should.

One of the most obvious cases that exemplifies that drawing a hard line between placing stylistically related alphabets into one font or separate fonts is Matthew Carter’s Shelley family.

Adobe and Linotype originally issued the Shelley Script family on three separate PostScript Type 1 fonts: Shelley Andante, Shelley Allegro and Shelley Volante. All three were stylistically separate. They were allowed to intermix but were three alphabets of three equally democratic position. When Adobe converted Shelley to OpenType, they merged the fonts into one: Shelley Std. The Andante set became the default alphabet, the only that gets wide exposure in WYSIWYG previews etc., while the Allegro and Volante sets were *demoted* to the position of "alternates".

Just take a look at the presentation of Shelley Script on Linotype.com:
http://www.linotype.com/1716/shelleyscript-family.html

You will notice that only the "Andante" variant has an "OpenType" icon next to it. This is because the merged font Shelley Std has been linked into the Andante style, suggesting that only one out of the three styles is available as OpenType. One need to dig to the Private Use Area section of the character map for Shelley Std on the Linotype website to actually see the other sets, and even then, it is *not* possible to preview the Allegro and Volante sets in running text. So if Linotype today sold only the OpenType version, the wonderfull Shelley Script would actually get *less* visual exposure and *worse* visual presentation than it was the case for the old PostScript Type 1 fonts.

I think it is actually more difficult to judge Shelley Script's visual potential when looking at the OpenType version than it was the case for the old versions.

And finally, the wonderful "Andante", "Allegro" and "Volante" names have been now replaced by wooden-sounding "Stylistic Set 1" and "Stylistic Set 2".

Do we call that progress?

Regards,
Adam

I have always hated the "Stylistic Set" numbering nonsense and agree completely on that issue. Shelley is a fifferent case than small caps completely though. Shelley would not be a choice often made for book work either, gorgeous as it may be.

ChrisL

Adam, I'm sorry I wsn't clear. I only do book work, and only know one or two magazine designers. Even these are really quarterlies rather than magazines. So yes, there are many ways to communicate many different kinds of information. But one more "still." The magazines I'm familiar with do tend to use a small selection of fonts for the magazine. And when they occasionally try a new display font for a particular situation, I usually mutter a quite "designer boredom" & get on with my reading. Very few "nice touch" mutters.

The advertisements in magazines are an entirely different matter, but I would think there is usually no thought of them fitting into the overall magazine design. Maybe I read the wrong stuff.

Terry:

How about writing our own code? I’m sure I’m not the only one who has thought of some other features they’d like to see built in OpenType.

Of course, and you should. I'd guess your problem is that in your work, many of the fonts you want to use are new, and a number of the newer foundries, or newer reincarnations of older foundries have EULA's prohibiting this. The thing to work on is "the fonts you want to use" -- only want fonts with a EULA that permits modification for personal use.

The progress that needs to be made is in the application and system software. There is already more in the OpenType spec than can be used with any convenience by the software available now. Here is hoping Adobe CS3 will soon make a change in all that.

ChrisL

I have a case study recently that I don't think ever was fully addressed before.

I want to first address that I think it is difficult for us type-centric people to realize that the world, (and this includes even many skilled and experienced graphic designers) don't understand OpenType technology. The habits of replacing ligatures from the Glyph Palette menu die hard, especially when many don't know there is any other way.

Another important factor to consider is until the latest versions of Quark, OpenType features weren't even accessible. There are massive amounts of publishing companies and print houses all over who have been using Quark for years...because of this, OpenType features are a brand new experience.

As more people become aware of this (and applications begin to fully integrate OpenType features) there will be more and more designers switching their libraries over from Postscript to OpenType. Which leads to this case study:

Recently we've been working with a freelance designer who has been creating a text heavy document (essentially a book) for our company. Over the course of the project we purchased the OpenType version of a Postscript font used by the designer. While this seems like a simple fix, the Postscript version contained small caps which are defined as a seperate font.

When converting to OpenType all style sheets had to be altered in order to compensate for the change in Postscript/OpenType formatting.

I assume I'm not going to be the only one this causes problems for when people switch over their libraries. I'd be curious to hear from book designers on this issue.

Has anyone actually reached out to "users" and asked what they thought about these issues?

There are always a few growing pains when switching from one format to another. This does not mean we should not progress or design everything for the transition period. If you make a typeface change, you always have to adjust your style sheets anyway. The difference is, once you have established style sheets with an Opentype font, you wont have to do it again for another one (unless it does not have small caps). If you were changing from one type 1 family to another type 1 family, you still would have to adjust the style sheets. I have always been a style sheet junky anyway. As long as there are client changes (always), style sheets save your butt.

ChrisL

It is partly a chicken/egg thing or an "if you build it, they will come" thing.
Application developers don't hear many cries for opentype features so they leave them out. Users don't know what can be gained from Opentype, so they don't ask for opentype features from Adobe or Quark. Adobe and Quark work on the squeaky wheel principle so they give Opentype features low priority.
Somewhere, there needs to be a real education campaign where graphic designeres/publishers are taught the reasons to use opentype as well as how to do it. This is tough untill the InD, Quark, et al have the interface and features sensibly included with the applications.
If you build it, they will come.

ChrisL

Don't forget about Microsoft...one of the biggest culprits. :)

It is partly a chicken/egg thing or an “if you build it, they will come” thing.
Application developers don’t hear many cries for opentype features so they leave them out. Users don’t know what can be gained from Opentype, so they don’t ask for opentype features from Adobe or Quark.

What I really wish is that this sort of thing not be done in type, but in the applications program -- which isn't happening.

To set nut fractions, we used a small routine in TeX for years. It was suppose to get more refinement, but worked well enough as is. For a particular circumstance, we'd just change the parameters a bit:

\def\Fraction#1{\DoFraction#1\EndDo}
\def\DoFraction#1/#2\EndDo{
\setbox0\vbox{\hbox{\XX{#1}}\hbox{\XX{#2}}}
\vtop{\vskip-.5\ht0
\hbox to \wd0{\hfill \XX{#1}\hfill}
\vskip.9pt
\hrule
\vskip.9pt
\hbox to \wd0{\hfill \XX{#2}\hfill}}}

Where "\XX" included a font change.

Or, to set any accent (or character, for that matter) over another, with positioning:

\def\superimpositioN#1{\leavevmode
\setbox0\hbox{#1}
\lower.0em\hbox to \wd0{
\hss\hbox{\char000}\hss}
\llap{#1}}

where #1 was the character taking the accent. \lower (or \raise) could be used for fine-tuning the vertical positioning; you could also put an \hskip inside the hbox for fine tuning the left-right positioning. Almost all of the characters in "Latin Extended A" can be made up this way. And if you want to make such definitions specific, change the name of the definition to be for a particular character. etc.

If your applications program is robust enough, you don't need to worry about making "changes" to the font -- one reason I find such restrictions in EULA's absurd.

* * *

Anyway, the code is no harder to write than what you need for OT features, and if it is in the application program, there is never a concern about whether or not it will be supported.

But Adam, surely under your scheme one would need two separate smallcap fonts in each weight of each family: one with both the uppercase and lowercase characters mapped to smallcap glyphs, and one with only the lowercase characters mapped to smallcap glyphs. Otherwise, users will have to carefully select only those letters in a word that they want in smallcaps, and would not be able to select capitalised words and set only the lowercase in smallcaps, as they can easily do via an OpenType control (which is not to say that I think the existing OT UI models are ideal).

Don’t forget about Microsoft…one of the biggest culprits.

Let's clarify and focus that compaint: don't forget about Microsoft Office... the biggest culprit.

There are lots of people doing good work at MS developing and supporting OpenType technology, but only a small fraction of that work ends up being adopted by the Office group, and the rest remains largely invisible to the majority of users.

Let’s clarify and focus that compaint: don’t forget about Microsoft Office… the biggest culprit.

Thanks for the fine tuning. ;)

"don’t forget about Microsoft Office… the biggest culprit."

Word :-)

ChrisL

Don't sound much like a standard to me.

Hope this all works on the web.

Oh hell, Happy Birthday Anyway, Adam!!!

Someone remind the higher level janitors that if unique Unicode values, despite the horrible break in Unicode laws, were be assigned to these glyphs, the lower level janitors would not be able to screw it all up quite so easily.