Create a new tutorial -there’s a section on new features (there’s quite a lot of them) there.
The new file format has been discussed very often on the forums - it was necessary to allow some of the new features, AIUI and for technical reasons. You can convert a project back to V2 if you need to.
I’m not at my desk so can’t answer the quick override question, sorry.
As of this moment, twenty people have read this inquiry and yet no one has the answer.
Not a good sign.
Fact is, when I asked this question I thought, “this is simple, I’ve just missed it.” I didn’t expect to journey down the v.3 Compile rabbit hole.
I searched the user manual for “Quick Font Override”, and in the section that discusses upgrading compile formats from legacy, I found this bullet:
> If the format depended upon the “Quick Font Override” setting in the legacy version, this is no longer done at the format level, but rather as a per-project choice in the compile overview screen.
So yes, that function that KB pointed out has the same purpose. I don’t understand why it needs to be called precisely “Quick” “Font” “Override”, in that order, to be considered the same function. The important thing is: if you select “Herculanum” from the drop-down and compile, does your entire manuscript look like a Disney film?
It makes all kinds of sense for it to be located in compile settings, in the overview area, rather than in the format as a special pane. If a format needs to use a different font then it ought to be using a different font in all of its section layouts and styles from the very start. The desire to use a different font than what the format was designed to use is a project/personal level decision.
P.S. You can’t take thread views seriously—and certainly not as omens of anything. The web has bots, and for another there might be ten people that view a thread for every one that knows the answer—and is capable of answering at the moment and now browsing on the subway.
It is obvious to me that the font override function in v3 is NOT the same as the previous “Quick Font Override.”
I like to write in Times New Roman 12 and 18, but I proofread/print my own work in Baskerville or Garamond Premier Pro points 12 and 18, with page numbers in Helvetica point 9.
Before, with the “Quick Font Override,” I was able to override the font of my main text without it affecting Header and footers: I could have the main text compiled as Baskerville point 12, but choosing Helvetica point 9, even in a different color, for the page numbers.
In Scrivener 3, the font override function affects absolutely everything, including the footer fonts. (Even when I have specified on the “Header and Footer” section that I want the footers to be in Helvetica 9.)
Furthermore, if I go a different way and use the Section Layouts, set my main text output format to Baskerville 12, and marking the box that says “Override text and notes formatting,” the exported document turns out as follows:
ALL the main text has been converted to Baskerville size 12, including of course Headers and Footers, and even some text which should be in size 18.
Small caps are converted to All caps. (WHY???)
I have spent the last 3 days reading the manuals, going through the interactive tutorial, and watching the tutorial videos, but haven’t been able to find a solution.
To summarize, I am looking to do the following:
Work on Times New Roman point 12 and 18.
Export to Baskerville 12 an 18, keeping Small caps as they should be.
Have page numbers in Helvetica 9, preferably in gray color.
Sorry, but you are wrong. You must be misremembering the 2.x feature. Quick Font Override overrode every single font in the text - that was its whole point. The font choice I pointed out uses the same code as in 2.x. It’s like nostalgia for 2.x has people thinking not seeing the concomitant features of 3.0…
Another approach would be to go back over how you were accomplishing this in v2. We learned up-thread that QFO was not the magic bullet. So, looking back and finding what did make it happen for you in v2 might help reveal how you would did it in v3 – might be substantially the same!
Of course, I am not sure why it is important to you to have the page numbers in a different font when you are proofreading, but onward and upward!
I just tested this in Scrivener 2 and Keith is right, “Quick Font Override” also overrides headers and footers in PDF mode (as it states in the UI).
Anyway, in Scrivener 3, set up a Section Type for your headings and text, and then assign a Section Layout to each one, for example Section Type: Preface gets assigned a Section Layout: New Page heading:
Then edit the header / footer font. Please see the text project — the project editor font is Gill Sans, the compile format converts it to Baskerville, however the header/footer is Menlo (fonts chosen as they are each clearly different to one another):
In this case I am writing a poetry project, with each poem broken into a few numbered segments. The reason I want to have page numbers in a smaller, thinner, and sans serif type (ideally I would like to make them gray, not black), is so they don’t interfere with the overall aspect of the printed page and, most importantly, so they don’t compete with the segment numbers. Enlarging the bottom margin helps, but is not enough. The purpose is to make the reading easier for an editor, for example, or for anyone else for that matter.
Anyway, thanks again! I will try these solutions and let you guys know.
I can confirm this behaviour, but it also happens when I try the same thing in Scrivener 2, see attached Scrivener 2 project. test.scriv.zip (45.2 KB) — There are only a few fonts that properly support Small Caps, all others fake it and I don’t know what the PDF engine Scrivener uses does (I tried Proofing and Publishing modes in Scrivener 2)…
Also in Scrivener 2 I cannot change the font colour of the footer?
The copies of Helvetica and Neue that come installed with macOS are not typographically capable of using small caps, I don’t think, nor do they seem to have the glyphs or variants. I’d try another font that is close—Avenir Next has small caps capabilities.
It’s a Scrivener fudge. Because most fonts don’t support small caps, Scrivener provides a way to fudge it. It makes the selected text uppercase and then shrinks the font size of the letters that should be small. So it’s not true typography-based small caps, just a quick way of getting the appearance of small caps using font sizes.
It is a fudge (the T is thicker than the H, a sure sign of a hack) in the editor. The question is whether this fudge can get applied to the PDF somehow. Santiago wanted his output in Baskerville, which is also does not have a real small caps.
I tested this with Dolly Pro which does have Small Caps support (opentype feature table smcp), and the PDF also shows All Caps. This is a limitation or a bug, and I see the same problem in Scrivener 2 (tested with either Formatting or Quick font override) as well as 3…