I’m just about to finish the trial to Scrivener and I’m going to buy it here in the next day or two as it’s become indispensable to me. It’s one of the rare programs that works better than expected and gives me functionality I didn’t even know I needed. If you can’t tell I’m already a fan…
Anyway on to the issue:
A normal font such as Times New Roman only has Regular, Bold, Italic, and Bold Italic, the basic four variations of a font. On these fonts I have no problems. Command-B, Command-i, etc all do what you’d expect. On a font like Garamond Premier Pro however, there are e a ridiculous number of variations such as: caption, bold caption, italic caption, subheading, bold subheading, italic subheading, display, bold display, semibold, etc. These fonts don’t work properly in regard to bolding, italicizing, or underlining using the text menu or shortcuts.
So when I set the default font in Scrivener to Garamond Premier Pro Regular everything was fine until I tried to bold a section. Then I tried to un-bold a portion that I’d selected by mistake and it didn’t go back to Regular. When I opened the fonts window (the one from Text > Fonts > Show Fonts) and experimented a little I noticed that when I hit command-b it would go from the Regular font to the Bold Display font. Hitting command-b at that point would strangely select the Semibold version of Garamond Premier Pro. Pressing command-b again toggles it back to Bold Display then back to Semibold. It never goes back to the Regular font.
I have found a workaround (turning off all the versions of Garamond Premier Pro that I’m not using) but it still seems oddly broken to me and I’d like to fix it if possible.
Thanks in advance for any light you might be able to shed on this issue.
I don’t have a full GPP set, and probably couldn’t tell you anything other than you have already observed even if I did. The only suggestion I can offer is: try replicating this issue in TextEdit and see if you get the same problem? If you can, then it might not be something that can be fixed in Scrivener.
Meanwhile, I’ll hold back on my rant regarding font designers who opportunistically mash ten, clearly different, font families into one family with a high profile name.
You’re right! It IS the same even in TextEdit. I hadn’t realized that was a system panel (the Show Fonts panel). Guess I’ll try checking the OS X and Adobe (where I got the font) forums to see if anyone else has experienced this.
I noticed that my Helvetica has quite a few variations as well and it behaves correctly. The Helvetica I have is a TrueType font whereas GPP is OpenType. I wonder if that has something to do with it…hmmm…
…anyway thanks for the assistance. I’m kinda glad it wasn’t a Scrivener issue. Keeps Scrivener untarnished in my eyes :mrgreen:
I am sorry to have taken your time with a non-Scrivener issue though. Thank you for taking the time to answer.
It might still be something that can fixed. Just because it reproduces in TextEdit doesn’t mean it is impossible, but quite often it is the case, unfortunately. You get a lot of power with Apple, but if they have a bug deep in their code the choice is often either to live with it or code your own alternative from scratch.
It would surprise me if the difference was TT/OTF. I think by the time it gets to this high a level it’s all down to the PostScript naming conventions which both TT and OTF follow. Helvetica Neue does have one [HN Condensed Bold] which you’d think would produce the same confusion as [GPP Disp Bold], but it’s hard to tell in a plain English list. There might be something beneath the name that keeps HN-Cb vs. GPPD-b, if you will, and thus confusing the text engine in light of there also being a GPP-b. That would be my guess.
I have seen some of this bad behavior for command+I and command+B in both Scrivener and TextEdit. It seems to me to connect with issues people in the font community had about type handling in Leopard back in 2007, see e.g.
But unless I’ve made a mistake in my checking, the problem doesn’t show up in current versions of Nisus Writer Pro and Pages. Sequences that make trouble in Scrivener and TextEdit, for instance
Garamond Premier Pro Regular, then command I, then command B, then command I, then command B
landing you in Caption instead of back in Regular, seem to behave properly in these other apps. It’s as if there were two versions of Apple’s font handling stuff, only one of which is handling these large families properly.
I’m not sure about bold, but for italics these other programs probably set the obliqueness angle on the font directly when there isn’t a proper italic variable, but then Nisus is a very heavily subclassed version of the OS X text system and Pages doesn’t use the OS X text system at all, but a custom engine built (I believe) on the WebKit. In most other places - where the standard text engine is used - you will see the same behaviour though.
All the best,
Keith
Oh, this has been driving me nuts!
The problem occurs with all the excellent Adobe OTF fonts that come with cuts/typefaces for different font sizes. Robert Slimbach’s Arno Pro has the same issue, for example. The problem is that the different cuts are ordered according to their intended sizes: caption, small text, regular, subhead, display. Cmd-I employs by default the “Italic” typeface of a font family if available. This means that if you are using a 9pt caption (non-italic) typeface, cmd-I will not jump to “caption italic” as it should but to (regular) “italic”. For some reason, a second cmd-I will select the first typeface in the list, which is “caption” and not “regular”. The correct choice, of course, would be dependent on the cut you are currently using (from “subhead semibold italic” back to “subhead semibold”, for example).
Any ideas/solutions/workarounds are more than welcome…
Well, one way to solve it would be to rename the sections out into their own families; eg. open up each of the caption fonts and change the family name to Arno Pro Caption, instead of Arno Pro. This can be done using any decent font editing application; if you need a free one, FontForge is from the wilds of open source software, and runs in X11, but is quite capable.
This problem has been around ever since font foundries started producing fonts with more than the base four cuts. Once you have more than four, the keyboard shortcuts will either fail or select “random” alternates. The reason for this behavior is buried in the truly arcane font definition structures. You’d think that by this time everyone would have agreed on a font family definition that would include alternate mappings for the shortcuts but they haven’t. Professional design shops just have a rule in place that you never choose fonts using the keyboard shortcuts, you choose them explicitly.
There are several solutions to this. InDesign & QuarkXPress have extensive style systems where you define an explicit italic style and a bold style, etc. and you can assign keyboard shortcuts to the styles. You can do this in MS Word & Nisus, too. Unfortunately the Apple style system does not offer this but you could use Keyboard Maestro, iKey, or another keyboard macro system to select the font for you—a little ungainly but it works.
In Scrivener, perhaps your best bet is to use a four-cut font to write and worry about the fancy caption stuff after you export it. 8)
Professional design shops just have a rule in place that you