Scrivener User Manual Corrections

[AmberV]

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.

Thanks for helping to make the manual better!

[gr]

23.4 Compile Settings > 23.4.2 Metadata Tab > Word Processing and Web Metadata [pg 555]

"fields may be used by search indexers to better categories the documents"

Should be 'categorise'.

-gr

p.s. I really just want to be the first on this thread.

[gr]

It may just be me, but on my Mac, text from the Manual pdf is not properly copyable.

If I open it in Preview or Acrobat and select some text and Copy, I cannot get the text to paste elsewhere either with a straight paste or paste special.

Pasting into this form field gives me an apparent string of spaces (a guess seemingly confirmed by pasting the same into TextWrangler).

Pasting into Scrivener or Word as unformatted text gives the same result.

If I copy from Acrobat, Pasting into Scrivener or Word as unformatted text gives me a string of placeholder boxes.

[nontroppo]

Copy-n-paste seems to work for me with Preview or PDF Expert, with the usual fact that hyphenation becomes "hard":

23.2.4 EditingFormats
To edit a custom format you’ve made in the past, simple double-click on the for- mat in the sidebar to open the format designer. You cannot edit built-in formats directly, so use the previous instructions to duplicate and then edit the new for- mat.

[gr]

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??

screenshot.jpg (355.82 KiB) Viewed 19315 times

Running OS Sierra (10.12.6), Scriv 3.0 (58). Preview 9.0 (909.18).

[Bridey]

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??

Just an FYI for the thread: using macOS 10.13 2 (beta) and Preview 10.0, Save As works fine when making a copy of the Manual embedded in the Scriv pkg.

Export … and then exporting as PDF also works without problems, but using the direct Export as PDF … option creates a file that only pastes blank lines.

Labyrinthine.

[nontroppo]

MINOR: Fig. 21.2 is incorrect, in that Pandoc outputs semantic HTML5 by default (test in terminal, use ⌃D to finish markdown input and see result):

Code: Select all

>  pandoc -t html

![caption](image.png){.left_float}

<figure>
<img src="image.png" alt="caption" class="left_float" /><figcaption>caption</figcaption>
</figure>



[AmberV]

Thanks, gr and nontroppo, both of those are all fixed. I had an older version of Pandoc installed when I created that screenshot.

Regarding keeping a separate copy outside of the bundle, the way I’ve always approached this is:

1. Open the manual from the Help menu.
2. Click on the icon in the header bar and drag it into the binder (or if into Finder, make sure to hold down Option so that a copy is made).

That should result in an identical PDF from the original. I’ve modified the instructions in the About This Manual intro with this tip.

As for the hard hyphens, I wish I knew a way around that.

[nontroppo]

Please see viewtopic.php?p=243931#p243931 — a link to §24.6.4 in the footnote may help a user to find the correct place to change first indents for .mobi and .epub3

Hard hyphens I'm sure are a "hard" limitation of PDF as a format...

[AmberV]

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:

This feature is not intended to be used for handling large and dynamic amounts of text (such as all body text), but rather smaller ranges such as individual block quotes, monologue formatting and so on. For bulk indent management, you should use a Section Layout’s settings tab.

(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.

[nontroppo]

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:

1 ePub 3 and KF8 Mobi formats can utilise CSS rule for more robust first indent management, which can be configured using the Text Layout settings (see §24.6.4).

Also in Text Layouts it is called "Remove first line indents" but in Compile styles it is called "Flatten first indent", when it is effectively doing the same thing?

[AmberV]

Also in Text Layouts it is called “Remove first line indents” but in Compile styles it is called “Flatten first 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.

[brookter]

[Vanishingly inconsequential but hey I'm a pedant and you did ask...]

Yellow box ("I don't need all of this...") above S23.1 Compile Overview Screen: TYPO

'Aren't to worried...'

[nontroppo]

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.

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

[AmberV]

Pedantry always welcome, brookter.

Speaking of which…

Well technically the indent is not “removed” with CSS, the specificity of the Cascade defines the importance of the rules…

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.