...keyboard shorthand commands...

...it’s a real crap throw whether roman will link to italic or just turn up that fake cursive...

...reliable links...

Um... I'm not sure what you're talking about. Do you mean keyboard shortcuts, like Command + B? And what applications are you using? Design for print? Web?

mondoB

There are a number of reasons for this: font configuration, system keyboard mapping, application programming. . .

As much as one would hope for a consistent industry standard, ha, be careful what you wish for.

Gerald

Actually, the problem IS based on an industry standard. In Windows a font family was defined as regular/italic/bold/bold italic. Whenever a font has other styles they cannot be treated as as one font family in applications like Microsoft Word.

Don’t work with Command-B/-I, but create style sheets. Any sane design application will let you assign (custom) shortcuts for accessing those styles. For good measure, you then can easily change all the occurences, in case ‘bold’ suddenly has to be ‘semibold’.

I do use style sheets whenever there is more than one bold weight, but I should be able to keyboard-command from a roman to its italic without setting up style sheets. It should always be as simple and reliable as it is with the big boys. Adobe, ITC, and Monotype never leave this aspect of their font engineering undone, so why do smaller foundries think they can ignore it?

mondoB -- Adobe, ITC, and Monotype never leave this aspect of their font engineering undone, so why do smaller foundries think they can ignore it?

Smaller foundries do not "think they can ignore it." Actually there are good reasons for avoiding style linking.

First of all, style linking works really reliable only with 4-style families which Windows regards as the one-and-only way a family should be look like: Regular, Italic, Bold, Bold Italic. More than two weights, Regular and Bold, were not anticipated.
As soon as a family has more than these two weights, a foundry has a few options:
   (1)  avoid style linking altogether,
   (2)  only style link each weight to its according italic,
   (3)  style link both italic and bold; therefore split what is a big family in InDesign, into many 4-style families for Microsoft applications. This is what you seem to expect. But this does have nasty side effects too:
   (3a)  Take an Adobe font with five weights. It links Regular--Bold and Light--SemiBold. But -- no bold for the Black! In a way this is inconsistent too.**
   (3b)  Other foundries (you have one in your list of good examples) only link Regular--Bold, but leave all other weights, Light, SemiBold, Black unlinked. Which means that if you select the Light and click B you get a fake bold. I doubt this is what you want.

And there are more factors involved which help make sure that, as soon as one wants to style link more than the 5 weights (which seem to be the maximum in Adobe families), things will break in certain contexts. Believe it or not, sometimes the "smaller foundries" who "think they can ignore it" are a step ahead of what Adobe does -- downside is that there are no footsteps to follow because we're discovering yet untouched territory.

In so far, it is easiest and most reliable for a foundry to choose option (1) and just say: "Never hit the B or I buttons!"*

You are right that foundries should make it clear if their fonts are style linked or not, and how (bold, italic, or both). Some do.

*  No misreading please. I am not saying that what Adobe does is bad, but just point out that all approaches to work around the 4-style family limitation have their disadvantages.
**  Thinking of WPF and future Vista application that may use it, however, (2) may turn out to be a better option than (1). So I am with you. Halfway.  :)

Sorry, even without technical details this turned into a longer post ...

I understand the ambiguity about style-linking more than one heavier weight, although you'd think smaller foundries would follow the solutions of Adobe and Monotype, or at least style-link each weight of roman to its italic. No, it's when they just abandon the customer who buys a four-style "nuclear" family--especially without any consistency within the same foundry. Perfect example: FF Celeste, with all four fonts style-linked simply and reliably when used in Quark. Versus FF Scala, with NO style links for ANY of its same four fonts in Quark. Same foundry! And if my memory serves, my original version of Scala (since replaced for OSX) DID have those style links! This indifference to basic customer convenience can be a real burn--something that needs to be discussed industry-wide and remedied industry-wide, it seems to me.

From a type designers point of view there are two kinds of customers: Office users and DTP users.
There are special packages for Office users where font families are limited to 4 styles and style linking works as expected.
http://www.myfonts.com/search?search%5Btext%5D=office

In a DTP environment the use of Bold and Italic buttons or shortcuts is not considered as an appropriate workflow. So for a type designer there is no need to jump through hoops to allow such a workflow. Just because some foundries do it, doesn't make it right.
Define paragraph and character styles for your bold and italic texts and apply the styles instead.
(Not sure about Quark, but in InDesign you could define those globally, so they will appear automatically in EVERY new document.)

mondoB -- Perfect example: FF Celeste, with all four fonts style-linked simply and reliably when used in Quark. Versus FF Scala, with NO style links for ANY of its same four fonts in Quark. Same foundry!

Hm, some consistency were nice. Or at least documentation.

Consider: If every single type design came with Regular, Bold, Italic and Bold Italic, then no matter how many other weights there were, you could rely on those 4 being style-linked. But that's not the case. There isn't an industry standard in the names of the various styles of a font family, much less a mandate that type families include Bold or Italic. We already know from other discussions that different applications see font style names differently, and some of them want Regular, Book, Plain, and other names to mean the same thing.

Built into that is the pitfall Karsten mentions: If you are accustomed to using the keyboard styles, you can get something bolder when you hit the "bold" command, but it might be fake, smeared bold. The italic command can give you electronically sloped roman. Many people don't notice this onscreen, and oftentimes don't even notice this in print. Is that desirable?

To put a finer point on what Ralf said, graphic designers are trained not to use the keyboard shortcuts for the above reason and for others. It is a MS Word convention that has leaked into other areas, much like the 2-space convention of typewriting that no longer has a purpose. I hesitate to make the suggestion since you're so passionate about it, but because of the inconsistent way typefaces, applications, systems, and text engines behave, I recommend you change your habits: Refrain from using the keyboard shortcuts and either select styles from menus, or set up character styles. I think it's safe to say that the consistency you wish for will not happen any time soon.

If you are accustomed to using the keyboard styles, you can get something bolder when you hit the “bold” command, but it might be fake, smeared bold. The italic command can give you electronically sloped roman.

Hear, hear, Carl. That's exactly why, as you say later, graphic designers are trained to stay away from QuarkXPress's Bold and Italic style buttons (I recently learned that the results of using them are known as "forced bold" or "forced italic").

I agree that the safest bet is always to choose the face and weight from the font menu provided in the application you are using.

In the old days (it came with Fontographer / OS9) there was a utility that would merge fonts styles into a family, providing for that behaviour in all programs. Very handy, but in these days font families with more than 4 styles were a rarity.

T was called Style Merger, if I recall correctly.

. . .
Bert Vanderveen BNO