I’m using folders to export titles of things. If I convert a file to a folder, and the folder itself has no text in its own text space, it will not export its title upon compile, even though exporting the titles for folders is checked.
Is there any option to export titles for textless folders, or one has to add some text to the folder itself, even only a space, to make it disgorge the title into export?
You should be able to compile folder titles without the folders containing text. Do you accidentally have the empty folders marked to compile as-is? That would prevent the title from being inserted at compile.
What format are you compiling for?
I’ve tried everything, including plain text. I don’t have anything checked as-is. When a folder has no text, but its children document have some, I don’t get the title. Scrivener 2.0.4 (7817).
Please could you post a screenshot showing bot the “Contents” and “Formatting” pane of your Compile sheet (ensuring that a folder with the problem is visible in the “Contents” panel)? That should enable me to see where the problem is.
Hi
I have the same problem (Scrivener 2.0.4 (7817)). When compiling my document to the MultiMarkdown format, folders that have no text or only inline annotations or spaces inside them sometimes get ignored. Below are two screenshots (slightly censored) as an example for this behavior, where the second one also shows what’s being exported.
The document «Modus Operandi» contains only the text «Modus Operandi», which gets exported correctly, see second screenshot on the left lower corner. The folder «Wirtschaftlicher Wandel» only contains an inline annotation + an empty second line and doesn’t get exported as a title.
Thanks for looking into this,
Oliver
The first thing I notice from your screenshot is that there is an image file in your draft - Handwerker 19??. Can you remember how that got in there? Scrivener should guard against image files getting into the Draft folder at all it’s disallowed - so that being there shows that there has been a bug somewhere down the line that has allowed it to get through (could it be that it was the subdocument of a template document? That was a bug I closed off a little while back but if you added it after the first release of 2.0 it’s possible).
My guess is that image file is responsible - because Scrivener doesn’t support image files in the draft area - and should disallow one - the fact that this one has got through is probably cause an error to be thrown in the background (try opening the console - ~/Applications/Utilities/Console.app and seeing if any errors get reported when you compile). Try removing that image file from the Draft folder and re-compiling, and let me know how you get on.
If you want images in the text, you should drag them into the text area directly. If you can remember how that image file got in there, I’d be very grateful!
Thanks and all the best,
Keith
Hi Keith
Thank you for your quick reply.
No bug, I just chose it as an icon for the document via «Change icon» (it contains LaTeX-code that inserts an image, that’s why it’s marked «as-is».
Greetings,
Oliver
I just checked: No errors on the console when I compile.
Sorry, it’s been a long day and I mistook the characters icon for the photo icon - rather embarrassing in my own software. 
Would it be possible to zip up and send either the project or a test project that exhibits the same problem to kb-tech-support@literatureandlatte.com? It may be a bug in the MMD exporter.
Thanks and all the best,
Keith
No worries. Of course, as the author of Scrivener you are a hero and beyond embarrassment and other trifles that concern us mere mortals.
I sent you the file. Thank you for looking into this.
Ha, if only. 
Many thanks for sending the file - now I see the problem. It’s a minor bug related to another rather obscure feature. There’s a way of “tagging” inline footnotes so that you can keep inline footnotes in a separate file to your text and just place a tag after the text to which they relate, so if Scrivener detects a file that only contains nothing but whitespace and inline footnotes, it only includes the text of the file and ignores the other compile settings (title etc). This shouldn’t cause any problem in normal use, because there’s no other reason anyone would want inline footnotes on their own without other text preceding them. However, a bug in the code means that it’s not just doing this if the text only contains footnotes, but also if the text contains only whitespace and nothing else.
I’ve fixed this for the next build, but in the meantime you can work around it by deleting the return character that appears after the annotation in the affected document - once the annotation is removed, that return character is all that’s left and so the bug means that the document, containing only whitespace, ignores the compile settings.
Thanks for helping me find and fix this!
All the best,
Keith
Great, thank you!
