I have been a long-time paid user of Scrivener for Mac - and I am now testing Scrivener for Windows to see if a Windows 8 machine might be in my future.
My issue is this:
I have used Scrivener for Mac to ‘compile’ my projects to LaTex via the MMD->LaTex option. All works fine on the Mac side. However, when I compile the same project with Scrivener for Windows, I cannot get the section headings to be formatted correctly in the .tex output file.
For example, my project (on Mac) compiles to the following .tex code:
[code]\section{Historical Complexity in Synoptic Gospel Research}
\label{historicalcomplexityinsynopticgospelresearch}
William of Ockham was a Franciscan monk and philosopher who was born in the late eleventh century and lived until mid twelfth century.\footnote{William of Ockham (alt. Occam) ca.1285–1349 CE.} In the course of his writings and personal correspondence…[/code]
However, the same project compiles in Scrivener for Windows as follows:
[code]Historical Complexity in Synoptic Gospel Research
William of Ockham was a Franciscan monk and philosopher who was born in the late eleventh century and lived until mid twelfth century. In the course of his writings and personal correspondence[/code]
The Windows version does not seem to place the LaTex “\section” and “\label” codes in the .text file. (*also, the Windows version is also missing the LaTex footnote tags - but that is because the Windows version does not yet support ‘inspector footnotes’ - which I use in the Mac version.)
I am well versed in the MMD/LaTex compile workflow from the Mac side - and have tried to replicate all the settings in my Windows Scrivener project - but to no avail.
What might I be missing - or is this an issue with the Windows build of which I am not aware? I need those sections in my Windows .tex file!
This is a known bug at the moment. Basically it lets you turn on titles but it neglects to add appropriate MMD hashmarks to indicate their depth, so you just end up with bare text where the title would be. The workaround is to add the hashes manually to the prefix for each level of depth you intend to export titles at. So the prefix for folder level 1 would be "# ", level 2 "## " and so on (note the space after the hash). The suffix hashes are not necessary, they are just visual enhancement when working with the raw MMD file.
Ok- thanks for the clarification. When you say it is a ‘bug’ - I assume that it has been noted/logged as such and will (hopefully) be fixed soon? Correct?
Thanks so much for your help in this I was beginning to go ‘crazy’ trying to get it to work. I will simply wait for the update! Have a great day-
Yup, it’s in the problem list already, and I’m not sure of the status on it. I just checked the NaNoWriMo version which is has a few bug fixes in it over the normal version, but it still exists in that one. I did just remember a better workaround. The bug disappears if there is any kind of prefix or suffix. So all you need to do is press the Return button twice in the Suffix file, and untick the “Place suffix inside hashes” option. That will space out the title from the first paragraph and hashes will generate normally.
Thanks for the assistance. I have implemented your ‘better workaround’. It ALMOST works correctly. All of the documents in my ‘draft’ folder are processed correctly with one exception. It appears that the first document in the binder (in the draft folder) is not being processed correctly.
If my binder looks like this:
then the document titled ‘Introduction’ is not processed with the correct latex code. This is what is generated
[code] #
Introduction #[/code]
HOWEVER, if I put a “dummy” file before the “Introduction” file like THIS:
then the document titled ‘Introduction’ is processed correctly with the following correct latex code:
\part{Introduction}
\label{introduction}
So, it appears that your workaround does work correctly, but the first document in the binder (under the ‘draft’ folder) does not. The same error happens whatever document I make the first (even if the ‘Part I’ file is first…)
For testing’s sake I switched the order of my ‘Meta-Data’ and my ‘Introduction’ files to check this behavior…In this case, the ‘Introduction’ file is not processed - but the ‘Meta-Data’ one is processed like a ‘real file’ (as it should be processed since it is not the first file in the Draft folder).
I’m not getting that problem myself, but it strikes me as being something unrelated to the title bug. Could you zip up the test project that replicates it and attach it to a response? It might be a unique combination of compile settings that I myself am not using.
Ok - I took a more detailed look at the problem. The issue I noted (about the need for a ‘dummy’ file) masked the real problem… I figured out what was happening.
This is something you may label as ‘user error’ - but if so, it may be something to address in the future. Here is what happened.
My ‘Meta-Data’ file (first document in my draft folder) did NOT have an end-of-line character after the last line. Therefore, the EOL needed to recognize the new next file’s title (in this case “Introduction”) was not being fed through the MMD parser.
On a RELATED NOTE - I didn’t notice this EOL issue earlier because when I moved my project from Mac to Windows - I removed the metadata from the keys list in the ‘metadata’ panel on the ‘compile’ page (Mac version). I did this because when you move a project from Mac -> Windows, it appears that all of the metadata keys are ‘lost’ in translation. That is, they simply disappear when the mac project is opened in windows. So, what I did was to recreate my metadata and place it into the ‘Meta-Data’ file in my project - and when I did, I unfortunately did not add that last, necessary EOL character.
*You might wish to add a feature so that when the MMD parser processes the first file named “Meta-Data” that it will add a final EOL if it is not in the file. Otherwise, it will break the MMD compile.
Thanks for your offer to look at my project. Fortunately I solved this myself. I am looking forward to the time when the windows version reaches feature parity with the mac one.
All right, yes that is indeed a problem. It should be adding a necessary empty line in between the Meta-Data file and whatever comes next. That is how it works on the Mac. I’ll make sure that’s on the list.
