I don’t know whether this should qualify as a bug reported or a wish articulated.
I’ve noticed, that when formatting text as small caps (I used it for names), after compiling the document as Word (.doc), the text is not exported as encoded as Upper+Lowercase letters with the markup of “small caps” (which would be the expected behaviour), but as all uppercase letters with smaller font size for the supposedly small ones. This makes reformatting hard. (btw within Scrivener this is problematic as well… pasting with “match style” gives me all caps instead of a mix of uc and lc).
No, this isn’t a bug. “Real” small caps are a feature of fonts. Word uses a different text engine and provides built-in small-cap variants for all its fonts, but the rest of OS X doesn’t. If you want real small caps, you should select the text, hit cmd-T to bring up the fonts panel, click on the gear icon at the bottom and select “Typography…”. This will bring up a panel with typography options for the current font. If the font supports small caps, you will be able to apply them here - for instance, Hoefler Text allows it (via “Letter Case”), as does Big Caslon, Calibri, and several others. Not many support this, though.
Scrivener’s “small caps” feature allows you to “fake” small caps for fonts that don’t support this (the same way Nisus Writer does it).
There are basically three (rather than two) ways of achieving small caps over the word processor / text engine lanscape in computing.
specific font feature/style – this is mostly supported by expensive professional fonts.
faking small caps on the display side by smaller font-sized normal capital letters of the font.
However, 2) can be encoded in different ways in the underlying text representation:
2.1) markup as This text (this is was word does, and allows more flexible text reformatting).
2.2) markap as THIS TEXT (this is what Scrivener does, and is less flexible in therms of reformatting text).
My question was whether you would considered using the 2.1. method of “fake” small caps encoding (in the text rendering would use in both sub-cases of (2) something like 2.2.). This would allow for more versatile reformatting options AND more adequate results in compiling/exporting.
[As 2.1 can be readily converted both to 1. and 2.2. without loss of information, however, 2.2. cannot.]
Method 1 Method 2.1 Method 2.2
Encoding level: <fstyle>Text</fstyle> <sc>Text</sc> T<fsize>EXT</fsize>
Text engine level: <fstyle>Text</fstyle> T<fsize>EXT</fsize> T<fsize>EXT</fsize>
Visual level: TEXT TEXT TEXT
(Where I could not simulate small caps for the visual level in the “code” environment needed for table-like layout; sc=small-caps, fstyle=font-style, fsize=font-size).
So if I understand correctly, if I use one of the fonts that support real small caps, than it will be successfully exported to Word, even if the override font during compilation is different? For example, if I write in Scrivener using Calibri using real small caps, but when I compile the text is converted to Times New Roman, will the text in small caps from scrivener also be in small caps in Word? Thanks so much!
Hmm, I just tested that and I’m sorry to say that no, it seems this doesn’t work. I believe it’s because small caps works completely differently in MS Word. On OS X, the small caps attribute is saved as a special Apple attribute which doesn’t get translated to Word.
This doesn’t help for ebooks, or any workflow that doesn’t go through an editor that can handle small caps, but I’ve stumbled on a method that I think works quite well and allows me to code bits throughout my thesis as being in small caps so I don’t have to go through in Word every time I export and put small caps in.
I use underlining instead, then I use Word’s mediocre search and replace function to search for underlined segments and replace them with small caps (and remove the underlining).
I have ~400 example sentences in my thesis, and roughly half of each one needs to be in small caps. Each time I give my supervisors a draft, they comment on the lack of small caps, and I tell them I’m planning on doing them right at the end, as I’d otherwise have to go through and manually do them for every example. This way, I’ve done the manual work in underlining the relevant bits in Scrivener, and in word I only have to run a simple search and replace once each time I print off another draft.