If you have spotted an error in the Scrivener user manual, please report it in this thread. All types of corrections are welcome, from formatting glitches to typos to cases of awful grammar.
It would work best for me if you refer to the section name that the typo or error was found within, along with a little contextual text to search for. Page numbers are okay, but in Scrivener things are organised by section name, not page numbers.
If you have been feeling especially ambitious and have compiled a large list of notes, then to avoid clogging up the forum thread please send them to our support. Plain-text, RTF or .scriv format preferred. You will also have my eternal gratitude.
To add to my Copy & Paste Manual Mystery: If I open the Manual from Scriv’s Help menu, (it opens in Preview and) copy and paste works fine. If I choose Save As and save a copy of the Manual to my desktop, then Copy and Paste fails with that pdf in the way I described earlier copying from either Preview and Acrobat Pro (vers 11) and pasting anywhere (Textedit, Scriv, Word).
Below is a screen shot of the operation on the desktop copy of the Manual showing open in Acrobat and Preview. Results shown are: copy from Acro paste to Word, copy from Preview paste to Word, and copy from Acro paste to textEdit. Other results paste in textEdit or Scriv are just like these.
UPDATE: Manual pdfs downloaded from the website and copy-dragged from the Scriv pkg behave likewise, correctly in themselves, but I can get the same bad result by making a copy of the pdf using Save As in Preview. The resulting copy shows the effects reported here.
I am surprised Preview’s Save As is doing anything substantive, but apparently it is. Could be some freak bug in Preview, but I have not been able to reproduce the effect with other pdfs I have hanging around (nor with a simple test pdf compiled from Scriv 3 for the purpose). So, what the heck is weird with this Scriv Manual PDF??
I’m a bit confused (could be Sunday fog brain). The documentation for that and the subsequent checkboxes very specifically warns in the paragraph directly following:
(I have fixed the typo and added a dynamic xref.)
I think that is the best (in the sense of economical cross-referencing) place to point people who are thinking these checkboxes are meant to adjust how the entire book looks, because (a) that is where you typically do make these adjustments—and so that is good to know—and (b) if you are using ePub3/KF8, there is a footnote in that section that refers to Text Layout as a global setting, as well as the section class + CSS method for more granularity.
This specific footnote is only meant to point out the fact that if you used these checkboxes in the past to adjust how things like a block quotes work for PDF, you need to know that if block quotes aren’t working the way you want in your ePub, you have to use CSS for that. Wouldn’t pointing to global settings be more confusing—when the very next paragraph says these checkboxes aren’t for global settings?
Maybe I just need put the warning in a yellow box though. I obviously anticipated some confusion since I have that paragraph in there, but I didn’t think people would stop at the file type availability line when referencing how the feature works.
If I understood pomme4mois correctly, they understood that the only way to flatten first-line indents for ePub3 was manually by editing CSS; which isn’t correct because they can simply click the checkboxes in the Text Layout panel (which may even be more robust anyway). I suspect most users don’t care about the “fragility” of the scope of an effect, i.e. they just want to flatten first-line indents, and want to know how to do that: they search the manual, find §24.5.3 and follow the idea for ePub3 or MOBI they can only manually edit CSS (and probably panic) to get the effect they need. §24.6.4 details actually they can use the UI to set up the CSS rules for them. So why not:
Also in Text Layouts it is called “Remove ﬁrst line indents” but in Compile styles it is called “Flatten ﬁrst indent”, when it is effectively doing the same thing?
My interpretation of the terminology difference is that styles effectively overrule global indent settings at the paragraph level. So “flattening” feels like a better way of putting that, whereas in the other cases that is where we set up the underlying default indent policy. Technically they are both very similar, but conceptually one is “default” and the other isn’t.
I’ve made a few minor adjustments to all three of these sections; hopefully it will be clearer in the next revision. The warning in the Styles panel is less about fragility and more about efficiency. It will be more efficient to handle indent policies at a broad level than using paragraph level tools. I think it would be effective (not fragile) to use Styles if every paragraph in the book is styled, but since that may very well not be the case, and isn’t by default, it requires less configuration overall to use the broad tools.
Well technically the indent is not “removed” with CSS, the specificity of the Cascade defines the importance of the rules (p + x rules are more specific thus take precedence, applying the indent), and only then falls back to the default paragraph styling (with no indent) — technical details aside the generic user probably doesn’t need to care about the technical vs. practical semantics… and yes, this is all pretty esoteric
ACK-shually, in reference to these options that use the “flatten” terminology, they are only applicable to RTF-sourced methods, not the clean and simple MMD+CSS derived extractions. When compiling from RTF-sourced material, indents exist as literal and baked-in RTF code applied to each paragraph individually wherever there is a stream change in formatting. Styles that dictate formatting not only have that definition stored in the RTF header, but express that definition literally as RTF code in the paragraph (updating a style means changing both of these things in all instances).
So the indent very much exists on the paragraph during the compile process, and thus for a style rule in the compile format to change that, it must remove that which exists… or flatten it.
And yes, nobody cares. But, I do think in light of that distinction, the “flatten” terminology does make sense.