I think this may only apply to Compile to Word (docx) as I think it might have been OK compiling to PDF, but I had been tearing my hair out over a document to compile and not all details are entirely clear in hindsight.
<$include:Synopsis: 300 (actually 297) Words>
the <$include also LINKS to the document… I just find it easier to do both so I can see at a glance what the source is, and know that if I rename it, the link (which has priority) still works.
Alas either a second “:” in the include text, or in the linked document name (but I doubt it, I think that parts OK) caused compile to fail using the Microsoft Office (not Aspose) docx converter. I also found MS Word zombie processes accumulating.
Noticed the colon issue (and proved the cause by removing the extra colon) only after restarting everything… and then the whole PC – but at least it is working again now.
UPDATE Not at all sure about this now – could have been the target file name (containing two “.”? Or path too long? Or…?).
Ignore - unless someone knows something about what causes such failures
You may have hit a one-off situation, as I do not see any issues with various methods of placeholder use and linking, as well as using colons in the title of the item itself. Here is a test project you can use to update and attach with any modifications that may reproduce the error (in case I misunderstood your description of usage):
As a note: I place the pure link parity check on a second line to avoid a bug whereby multiple <$include…> tags on the same line will work incorrectly. That pure link approach is something to keep in mind though for tricky titles. Most should work fine, in my testing, but if you do run into a case where the literal document title is messing up placeholder recognition (I bet having a > in the title messes things up!) then just hyperlink the <$include> placeholder by itself, and maybe drop an inline annotation after it with the binder title if it is ambiguous. That’s what I tend to do, as I’d rather not have to worry too much about binder item titles changing over time.
TL;DR Resolved - not a Scrivener issue, not related to “:” or includes, but probably to "."s in the output filename with the Microsoft Office docx converter
Thanks. I’ve opened and compiled that successfully and confirmed that if it compiles, it compiles correctly.
The bug, is – I suspect – in the Microsoft Office converter.
It will compile to temp 2 (1 5 SPACE).docx , it will not compile to temp 2 (1.5 SPACE).docx – which has a “.” in the filename before the extension, creating two “.” in the path. (I was naming the file to remind me to increase line spacing to 1.5 times for a submission.)
If the converter is changed back to Aspose, then compilation to temp 2 (1.5 SPACE).docx is also successful.
So I’ll use the Aspose converter.
Just wish I could remember why I switched to Microsoft Office… there was a reason!
UPDATE: I used the Microsoft Office converter so the document was compiled to UK English… with the Aspose converter it was always US English. See this question
Ah, okay. I do know of at least one weird problem with dots in filenames, with Qt internally (image icon asset names). It could be there are other areas where it gets a bit confused over what the extension is meant to be. Kind of an odd problem to have in 2023, but oh well.
I had checked that condition as well, but in double-checking my settings I’m already using Aspose, so I guess that’s why I hadn’t run into issues.