If I had to guess it’s the remnant of deleted section type that is still associated (by ID or whatever) to the scene.
I tested that. It is not.
When a section type is deleted, documents fall back on Structure-Based.
(It seems more like something that would have gone wrong on import from V1…)
And the reason I am asking, is that somehow I still think it has some role to play in the (although fixed by a workaround) present issue. (Assuming the original issue wasn’t simply a question of incorrect binder structure, that is…)
N/A is a default section type that appears in some templates. For example, this is from the short-story template:
By god.
You mean someone deliberately named a section type “Not available / Not applicable” in a template. ??
Well then, nevermind, I guess. Not related to the present issue at all.
Perhaps the idea is to mean it is to compile “as-is” ? As in “not assigned” ? (But it is a bad idea, imo. The name, that is. – If that is the case, why not simply name it “as-is” ? Or “Compile as-is” ?)
1 Like
In the same template, it is used for the cover page (in the front-matter folder) to the short story. It only holds the author’s name, contact details, word count, and story title.
A cover page doesn’t need a section type or to be styled to a publisher’s specifications, so ‘N/A’ (not applicable) seems apt, oui?
Not if it looks so much like something a software would say after something went wrong.
(Just my opinion.)
To me it makes sense, sans confusion. It reads as it being not relevant (i.e. not applicable; n/a) to style the first-page header. The template is designed so the first-page header is prepended to the story itself on compile, without a page break (as below). Can’t remember anyone else bringing this up as an issue, but perhaps L&L will read this thread and give it some thought.
1 Like
Using the compile settings you supplied, the issue appears to be the with custom separator between text files. Changing this to anything else removes the asterisks between the front-page header and the story.
Sample project and compiled PDF attached.
Bekanator.zip (134.9 KB)
But that would’ve also removed it from everywhere else she wanted that separator.
(By the way, @sobs, issue is already resolved. The problem was that the file was inside a folder, and the separator came from the assignation of that said (otherwise useless) folder. If I understood correctly, that is.)
2 Likes
Calling the section type ‘N/A’ seems like a terrible idea to me too. To my mind it is perfectly inscrutable and suggestive of all the wrong things.
1 Like
I’m not even sure what the problem was that created it. In Scrivener 1’s Compile function, I used to be able to change the separator between a folder and a text document with an empty line and that always solved the problem.
For whatever reason, that solution doesn’t work in Scrivener 3.
I’m actually shocked that this isn’t a more frequent problem, considering that the above photo is how most publishers expect manuscripts to look.
The manuscript format in Compile still has a lot to be desired. EVERY SINGLE TIME I compile a short story with Scrivener, I have to tweak it to get it to adhere to SHUNN formatting.
If you mean the photo in this post, that’s the default output from the short-story template in Scrivener 3. If that is right, hopefully that template (or your own edited version of it) will make things smoother in the future. Lot of changes between Scrivener 1 and Scrivener 3.
That is definitely not the best way to proceed. You need to Duplicate and Edit that Compile format to meet your requirements. Tweak once, use for compiling short stories!
The way it works is indeed different in V3. For transitions (separators) between such document types, you need to rather use section types/layouts. (When you want a separator other than the one that is otherwise set as the default separator, that is.)
Once that specific section layout is created (along its section type) you need to assign it manually in the metadata panel of the document 2nd (of 2) of the met condition by which you want compile to rather insert that different separator. (The separator always comes from the document that is after. For e.g. : in a folder-separator-text document transition, the separator comes from the text document’s separator setting. The folder is only there as a “condition to trigger”.) → In that case, different doc types following each other, 2nd being a text file : this is where the separator is set
You should also have a look at Project / Project settings / Section Types, which sets the default types per structure, and offers the possibility to treat file groups as a different file type.
And finally, each section layout can either use the default separators (top section) or its own :
→ This is where your true solution actually was. …You should have created a section type/layout for that specific no separator case, and assign it to the document following where you wish there was no separator. After which you would have set the section layout therefor created to use its own separator (not the default ones), which here you would have set to be none. [※]
But even so, since in that case the issue came from being in the binder a folder that didn’t actually need to exist: for the rest, do not insert files and/or folders that are now otherwise useless in V3.
(Folder which, by the way, I still can’t see anywhere in your screenshots… (you spoke of two and I can only see one) make sure to show everything next time 
)
[Something is still not adding up tho; but I give up, no point digging further at this stage. (A folder should have triggered the text file’s before section separator, not ***, and not where it ended up. That file being followed by a folder, probably that folder is leading to a section layout that does insert *** before sections. ← I can’t see such assignations from importing your compile format; the whole project would have been necessary. ) But even then, I pointed out to the one layout I thought could potentially insert it, and if I remember right, you said that that wasn’t the assignation. I hate when this happens, but I just can’t wrap my head around it.]
. . . . . . . . .
※ (There is also the option to override the separator under a certain met condition – the less section layouts you have in a project, the better it is; as they all need to be adjusted, should you later choose to change the overall formatting…)
1 Like
Adapting the Manuscript compile format for the “proper” manuscript format advice from Shunn is not hard. Here are a few screenshots of one simple way to approach it. I have included at the end the Compile format file I came up with for this.
There is a single front matter doc that uses placeholders and does not need editing when compiling diff stories.
In the story folder, the ‘section’ docs are for body text (and # separators will be interpolated between them). The body text docs look just like you would expect. (Ignore the stray carriage return – Adobe pdf–>docx export let me down.)
Each of the two kinds of doc have their own (self named) section types, and each of these is assigned to a (self-named) section format. This is just so we can get the # between body text sections and not between front matter and body.
In my view the one weakness of this approach is that it requires that you enter project metadata at Compile time – namely title and abbr title (presumably author does not change).
This project metadata dialog box was clearly conceived with the idea that your Scriv project would contain only one work – like a book. But that is not the natural way to work with short stories in Scrivener. You will probably keep lots of stories in a Story Library folder in the same project and just move a relevant story up into the Draft folder when you want to compile it. BUT that means you have to remember each time to edit the title and abbr title in the project metadata box (which is often not the tab showing!). There is, sadly, no natural way to establish all these per-story parameters within the story folder itself and call on them through placeholders as needed. (Scriv desperately needs a placeholder-type for setting a string constant and one for recalling it!)
Here is the compile format file that I made:
SHUNN Manuscript (Times).scrformat (60.3 KB)
Finally, a sample compile (Shunn’s own article):
SHUNN sample result.pdf.zip (92.0 KB)
1 Like
Have you looked at our upgrade guide for Scrivener 1 users? It explains how to convert Compile settings from the old version to the new. You can find it here:
“N/A” is what Scrivener 3 uses as a Section Type for Scrivener 1 documents when it can’t guess – for instance from the Binder structure – what they should use instead.
1 Like
That’s a good explanation, and it is exactly what I thought when I saw it in the OP’s screenshot (the part where Scrivener didn’t know what to make of it, that is… Although I have to say that it looked way more like some sort of error report than an alternative section type…)
But still, then, why is it in a V3 template ?
Just curious hey. It’s not like it is likely to pop up mixed in with some other unrelated issue that often…
I didn’t write the template, so I can’t say for sure. But it looks like the Short Story template assumes that Short Stories are composed of Scenes, and that all other structural divisions are just for the convenience of the author.
Naturally users of the template can and should adjust the list of Section Types to match what they’re actually doing.