I just tried compiling a couple of chapters, in which certain terms are meant to be written in small caps. I am compiling to a “pro” font with built-in small caps for both characters and numbers, but it seems that no matter how I try I can only get Scrivener to compile them as actual large caps (and regular tall numbers too).
As far as I understand from the documentation, convert to small-caps should give me just that — typesize-shrunk actual caps (whose shrunken-ness disappears on compilation as all text is reformatted) and not actual small caps. So that seems to work as described.
But as far as I understand, it also says that if I compile to a font with built-in small caps, they should come through fine. Which, in other words, I can’t get them to.
My question, then, is: Shouldn’t Small Caps ideally be “passed through” the compilation reformat process, just as italics and bold and underlining? Or am I missing something here?
Typography settings are a bit finicky in OS X. One of the problems with them is that the method used to store formatting attributes (what we use with our Formatting Presets system, as well as any customisations in the Formatting compile and preference pane) completely disregards all of these settings. So if that is what you are trying to use, that’s the problem. You can see these settings get dropped by merely switching to another pane and then back to Formatting.
So you do need them to be applied to text itself, rather than held in a formatting storage area that is applied to text. Just make sure you have Preserve Formatting applied to these ranges of text.
I might need to update the manual though, I’ll have to check out that section again.
Gee, I think I just might have reached the outer limits of my brain…!
Not sure what you mean by "formatting storage area " — but to my knowledge, I am indeed applying the attributes to the text itself.
Or am I oversimplifying (undercomplicating?) things?
In the editor, for whatever reason (laziness + defaults?) I am using Optima as I write and author my text, knowing that on compile everything will turn into Garamond, with the spacing and margins and whatnot that I like.
But I also know that any words I make italic or bold will stay so in the formatted Garamond output.
So to clarify my question: How come small caps aren’t?
Thinking as I write, I do see a difference: Italics and bold are (I guess) control tags of some kind (which, technically, then makes the output choose characters from another font file, right?) whereas small caps are actually their own characters (U+F761 and onwards) within the original font file.
So if Scrivener creates small caps by shrinking “original” caps only, that change-of-size will obviously be ignored at compile when the text is streamlined into one formatting. Hm.
Perhaps — unless I’m missing something — that means that this post ends up being a suggestion instead:
A. On convert-to-small-caps, could Scrivener convert the selected text to unicode small caps rather than just shrunk standard caps?
Yes: a problem would be that if using a non-extended font (like my Optima) those character would become squares or control characters instead.
So perhaps,
B. Could there be two menu-items, one “convert to small caps” and one “convert to faux small caps” (perhaps with a warning dialog if choosing real small caps and the selected text does not have an extended character set).
Yeah, basically bold is a wholly independent (but associated) font table with potentially its own typography settings. Those are more like a way of seamlessly remapping characters to different addresses in the font table on the fly so that B ends up using some other glyph entirely, but remains ‘B’ in the source. Technically speaking the two are not alike at all, and that is what you’re witnessing the result of (well, that and Apple’s somewhat incomplete OpenType management system).
Speaking for what a designer wants, though, I’d say the choice to use, say, a fancy ligature set is essentially the same type of human-level decision as making a title bold.
The problem as I understand it all goes back to what I was describing before: if you apply settings to text it is stored in the text file just fine, but formatting, as an abstract set of settings, is stored as something applied to text, rather than being a part of some text (like a Preset, or the Formatting compile settings), is technically different internally—and there is a bug (I presume) in OS X’s capability to store formatting which excludes typography settings. Thus you cannot create a title preset that automatically applies proper small caps. (Update: actually that seems to be working at least on 10.10.)
Is that why they get knocked out by the compiler? It’s likely, but I’m asking about that with Keith.
As to the suggestions: I don’t really understand how a modified or additional menu command would alter any of the above. All that would do is make applying this one single typography setting easier (assuming it is even technically possible to access that stuff from the programming side)—the end result would still be something subject to the limitations explained above.
Aha — might we be talking about two different things here? I’m starting to suspect I’m not making myself totally clear, so I’ll try to describe the situation instead of expressing myself in general terms.
If I understand you correctly, you’re mainly talking about styling, say, each chapter’s beginning with, say, the first four words in small caps — as described in the manual on page 380. No?
What I want is rather to arbitrarily incorporate small-capped words and terms into my text (actually, and ideally, very much as if “applying a setting” the way you describe).
Let’s use this made-up text as an example:
If typing this text in Scrivener, then selecting FBI, NSA and ECHELON respectively and choosing the ConvertToSmallCaps menu item, they are first CAPITALIZED and then shrunk.
In the editor this looks fine, but when compiling the chapter the size attribute is overridden by the compile settings for level’s formatting — totally as expected, of course, streamlining the look of my book. But at the same time, turning my nice-looking [size=80]SMALL CAPS[/size] into screaming CAPITALS:
So what I’m after here, I guess, is one (or both) of two things:
A. A menu command that simply converts my text to the font’s own actual small caps in the font format table. (Yes, I do see that these are addressable manually by selecting the word and going into FORMAT>FONT>SHOW FONTS, then choosing COG WHEEL>TYPOGRAPHY, then expanding the LOWER CASE section and hitting SMALL CAPS — but that is arguably quite a long route to wander when you’re in the middle of trying to compose a sentence…)
B. When compiling, should Scrivener not ideally react when encountering text that has been converted to (faux) small caps, and — where the compiled-to font has the appropriate professional features — replace it with actual ones?
I think that would be better than what happens now: just passing them through as capitals. It would also let me author with a screen-friendly font the way I do now, and not necessitate writing in the final font as with alternative A. Which, no doubt, is one of Scrivener’s great strengths!
Thanks for bearing with me!
Hope you agree (and that I made myself a little bit more clear now.)
EDITED TO ADD:
BUT WAIT — just a brief update: The two images above are screendumps from within Scrivener, and the first image shows the actual, true small caps set using the cogwheel menu in the font dialog.
However. On compiling those exact lines, using the same pro Garamond font for output as in the editor, the compiled PDF/print comes out with those [size=80]SMALL CAPS[/size] printed as lowercase again.
This makes me wonder — is there no way to output small caps from inside normal document text?
And also: With small caps actually checked within the font’s typography settings — and with the right small cap glyphs displayed on screen in the editor — isn’t it weird that those glyphs are not just passed through when compiling? It seems to me they are then actively changed back to the lowercase glyphs…?
Sorry — this one was a more confusing issue than I thought…
There are several problems with small-caps which are unfortunately problems inherent in the OS X text system:
Unfortunately, it’s not really possible to offer that, because those typography features that Apple provides in the font panel are black magic - whatever Apple is doing there, there is no way to replicate it in third-party code. To bore you with technical details, NSFont (Cocoa’s standard font object) does have an NSSmallCapsFontMask setting, which in theory should convert fonts that support small caps to use small caps in the same way you convert fonts to use italics and bold in code - but it doesn’t seem to work. And Douglas Davidson, one of Apple’s text engineers, has said on a developer list that the text system in fact uses special attributes to record the small caps state - it’s not stored in the font. But these special attributes aren’t documented anywhere nor publicly observable by examining the text in code. So, as I say: there’s some deep voodoo going on there.
Even if it were possible, however, only a very few fonts on the system support small caps anyway, meaning that if you converted between fonts, you’d lose the small caps.
Thus, the solution - not ideal, but the only one currently feasible - is to shrink the the font and merely emulate small caps. But that brings us to:
[qutoe]B. When compiling, should Scrivener not ideally react when encountering text that has been converted to (faux) small caps, and — where the compiled-to font has the appropriate professional features — replace it with actual ones?
[/quote]
Again, this isn’t possible for the reasons given above - there seems to be no way to do this in code. And the problem is there there is nothing special about the faked small caps text, so if you override the font, it will all end up as uppercase (unless you choose not to override the font size).
I’m sorry for not replying to this earlier, but Ioa brought this post to my attention and I looked into this. It turns out that there is a bug in the Cocoa methods I’m using to archive and store the Compile settings that results in the typographical features of fonts getting lost. The good news is that there’s a different method I can use, which I have adopted for a future version, which preserves the typographical features. So, this is fixed for a future version (although not a 2.x version, I’m afraid).
There is going to be a solution to all of this - styles. Styles are being introduced into the next major version of Scrivener, and you will be able to override them at compile time. So, along with the fix mentioned above, it means that you should just be able to assign a range of text a particular style (which has small caps or not) and then override that style to have small caps in a font that supports it during Compile time, and the small caps will be successfully applied. (Compile doesn’t have to try to do any of the deep voodoo in code since it just captures what you have done via the Font panel in the “Formatting” pane.)
So, in short, the introduction of styles and this fix should address all of your problems, but we’re a good few months away from any of that being public, I’m sorry to say.
