Clear Way to Export Scrivener file to InDesign?

I’ve written several books in Scrivener without images or fancy layout requirements.

Now I’m working on an academic book project with extensive text, many images, hundreds of footnotes, and a need for control over layouts. I really want to do the writing in Scrivener (it’s a great tool) but I’m having a painful experience trying to get that writing into InDesign. I have image placeholders in Scrivener that I want to format properly in Indesign. All the tutorials I’ve found have intensive workarounds using coding.

Is there a clear way to do with without having to get into coding?

In the past, I’ve used a combination of Word and InDesign for these types of projects. The workflow is effortless: Word files are linked to Indesign, and updated as needed. I hate Word (and love Scrivener) for writing. But this cumbersome process is making me reconsider just writing the whole thing in abominable Word. Others online seem to export from Scrivener to Word to InDesign, which seems kinda nuts to me. What about a second draft? Do I rewrite in Scrivener, only to have to again lay the book out in InDesign? Three programs just to write a decently formatted academic book?

Tl;dr, Is there a clear way to get a Scrivener file with footnotes and images into InDesign? Seems like a major liability of Scrivener that there’s no clear way to do this.

The Scrivener → Word → InDesign route seems to be what most people use. I would recommend simply avoiding InDesign until the manuscript is almost complete.

Many of our academic users use a Scrivener → Markdown → LaTeX workflow instead. On the downside, LaTeX has a pretty steep learning curve of its own. But on the upside, it’s the big gorilla in academic publishing, and most of the steps in this workflow can be automated.

Edit: As for whether this is a “major liability of Scrivener.” Not really. Scrivener’s goal is to produce a complete manuscript with “good enough” formatting to hand it off to dedicated layout tools. The point where that handoff happens will depend on the complexity of your manuscript.

2 Likes

Thank you!
Sorry for the major liability comment. I think what I meant is that Scrivener goes far beyond a “good enough” program—it’s excellent. But one flaw as a first-line writing/drafting software is that exporting cleanly to a layout program (which many users seem to struggle with) is pretty opaque. And is absolutely necessary for many users.

I’ve been working this afternoon on how I might do this. Seems like I can use a Word file as a kind of “dummy” or intermediary file that I might not even open. I can then link the Word file in InDesign. And when I make any changes in Scrivener, I’ll just save over the linked Word file. I haven’t really tested the process out in practice—may be great, may bomb. We’ll see.

Would love Scrivener to Export to IDML, just as the program exports to Final Draft, for instance. Seems like a logical thing to do, considering the goal above…

2 Likes

I use just such a workflow. Works a charm – though my use case does not involve images. One of the delights of the workflow for me is this: for special needs paragraphs, I can set up a do-nothing style in Scriv to tag them, have that style info passed to the compiled docx, and the resulting paragraphs will be given their special finished look (whatever it is) in InDesign, because I have a same-named style in my InDesign template. Sweet. This alone does most of what I need to get excellent page layout results – once I figured what sorts of special paragraph (and character) styles I needed to establish. I recently set a 400 page book this way which required nary a tweak in InDesign.

Of course, if you are really picky about typography and book design, you will want to dig more into InDesign for the clever things it can do for you. I do have a number of InDesign scripts that do some finicky things for me and save me manual labor in the program.

1 Like

If the format is public, in theory it would be possible to write a Markdown → IDML converter, along the same lines as Markdown → LaTeX. That would be a feature request for the Markdown people, though, as Markdown is Scrivener’s endpoint in that sort of workflow. (Could do the same with Pandoc → IDML, too.)

We do provide a LaTeX pane in the Compile command, but it’s used to define the information that gets passed through to Markdown. Scrivener itself does not include a LaTeX engine. For other formats, you could use the Processing pane in the Compile command (see Section 24.22) to send Scrivener’s output to the post-processing script of your choice.

Pandoc supports ICML, which is an IDML subset that Adobe’s own word-processor, InCopy, uses to communicate with InDesign. You can preserve most features of a document via ICML, though ICML is not a full layout format like IDML is (that is Adobe’s design choice). At present you would need to compile via the plain MMD output. Scrivener could make this a bit easier by adding this as an option for their Pandoc-specific output (currently limited to docx, docbook & epub).

IDML (rather than ICML) is not an easy format to support. The specification is IMO dense and really is specific to InDesign only, requiring an in-depth knowledge of its layout engine. But I think ICML is a good bridge, as it is more document-centric…

This is the important detail. By using Scrivener’s styles, you can tag paragraphs so that styles can be utilised. This works for Word (as in gr’s workflow), markdown, LaTex etc. in a similar way and is the true magic sauce that makes Scrivener’s compile mechanism so flexible!

Unfortunately, this support is very, very limited. It’s just paragraph and character styles, plus images and basic table support. Style names can’t be freely defined, so you can’t adapt the output to a pre-existing style sheet.

If one can live inside those limits, it might work better than formats, like DOC or RTF, not preserving links to external image files.

Paolo

I have to address this statement with a workaround: You can apply an existing InDesign style sheet to the ICML file generated by Pandoc. Once you have done it, you can delete one of the styles automatically generated by Pandoc, and let InDesign replace it with one of the styles in the style sheet.

This way, you will end with the desired styles in place of the ones forced by the Pandoc filter. Not the most comfortable of the operations, but a viable one.

Paolo

I can’t yet find a way to go from Scrivener to InDesign/Affinity Publisher without a lot of editing work.

  • The Pandoc → ICML conversion is very basic. Styles are renamed according to its own syntax, images and object can’t have styles, therefore have to be edited one by one in the page layout program.

  • The Word file format doesn’t preserve image links, and the image placement when loading into InDesign is messy. Again, there is heavy editing work to do after importing.

  • Affinity Publisher can’t read ICML files, so even the basic conversion is not useful for it. There has not been a way to convince the developer, as of now, to add this compatibility. I found a way to manually convert an ICML file into an IDML one, but it is very much a try&prey process.

While evaluating the Markdown → LaTeX way for creating PDFs, I could discover (thanx to @nontroppo) Quarto and Typst. The developers are very responsive, and while testing them I could see that it is a very promising way for my workflow.

Yet, this type of path is not exactly a user-friendly one. With the price of Affinity Publisher, a direct link between Scrivener and the page layout program would be an obvious choice.

As a marginal note: I see LaTeX continuing to be considered the natural choice for academia and scientific writings. Yet, I see that the major magazine, like Nature, ask for Word or PDF files. Nature is very explicit in discouraging LaTeX:

If you have prepared your paper using TeX/LaTeX, we will need to convert this to Word after acceptance, before your paper can be typeset.

As someone who has always worked for the publishing houses in a town with a law and human sciences university, I’ve obviously never seen manuscripts delivered in LaTeX. Everything comes in Word, and is edited in Word (or a program that can read and write that file format).

This is not to say that that’s the wrong way; just that there is also a different perspective, and it is probably the one most people using Scrivener are accustomed to. Privileging the LaTeX way, instead of improving compatibility with page layout programs, seems to just be making things more complicate.

Paolo

If you want to use Word as your exchange format, you certainly can, and we’d be happy to consider any feature requests that would make that process easier for you.

I think, though, that some degree of “editing work” is almost always going to be necessary after importing to InDesign. I mean, if Word (or Scrivener) could do everything, you wouldn’t need InDesign in the first place, right? The whole point of a dedicated page layout tool is that it has more powerful formatting capabilities.

I’m surprised that Nature discourages LaTeX. IEEE, the American Chemical Society, and Physical Review all prefer it. Of course, Knuth invented TeX for mathematical typesetting, so I’m sure field-specific biases are at work.

2 Likes

I don’t think Scrivener / L&L has privileged LaTeX over other workflows at all. In fact I suspect @KB has dedicated more time to his custom DOCX / EPUB / Direct-to-PDF converters (both via Java and his native one), than anything LaTeX specific. The reason there are so many “geeky” options is because the hard work is done outside of Scrivener. I’m sure L&L would love to have an ICML or Affinity exporter.

BUT to see how utterly daunting it is, have a read of the obtuse and incomplete documentation Adobe has reluctantly released on ICML and its IDML superset.

In fact, Adobe has mostly removed all documentation – do a google search for Adobe IDML specification and you’ll find lots of posts asking “where” the spec has gone, then you may find a link to an old PDF. Then try to read it, then try to get help on understanding it…

I am fairly adept at reading dry specs (I used to “enjoy” reading the various web standards documents released by the W3C, particularly technical docs for CSS), yet the Adobe docs (once you find it) is utterly horrid in comparison. I do not envy anyone who has to make an InDesign exporter, that is likely months of frustrating work as Adobe is probably actively protecting their territory by released an incomplete spec. For Affinity have they even attempted to make an open standard?

In summary, I totally agree with you that if Scrivener had a clear path to export IDML or Affintiy docs this would be a big selling point for L&L (more users would want this route than the geeky markup routes via MMD / Pandoc). but neither company has made it easy to do so, and the sheer complexity and maintainability is what I assume precludes L&L from investing its resources in this direction.

Just for reference, many of your problems could be solved with a more focussed workflow that utilise Pandoc filters or other scripts. But the user must be capable of writing these or asking others to help on the pandoc forums etc. As long as you have the data, scripts and filters can do just about anything. I do understand that the technical barrier for this precludes this option for most people who don’t code, and understand why InDesign may be the only choice for them. But to be fair, they are paying the debt of not being able to code + without someone else doing that work…

1 Like

In my own use case, a workflow from Scriv to inDesign using docx as a bridge works very seamlessly. Though, in the rare cases where I needed images, I have dropped them into inDesign directly. Also, after doing the fidgetty stuff in inDesign for a while I committed them to a custom inDesign script that does all the things I standardly do with such text.

Maybe my needs are just modest enough that it works for me. Defining custom styles in Scriv that don’t but mark the text, but have defined meanings in my inDesign template does most of the basic work. The custom inDesign script does most of the rest. Pretty sure what remains is just me being particular!

So, listening to you and comparing to my experience suggests it might be transformative to find some way to handle the image transfer problem.

Looks like there are folks over in inDesign Land that have worked at inDesign scripting that would convert a placeholder url and replace it with the placed image. Maybe there is some promise in that.

It should be a generic solution for exporting to any DTP package. My preference would be exporting to Scribus as it is open source.

There is equally a steep learning cuve for newbies to InDesign/Scribus/etc too.

Thank you @kewms , @nontroppo and @gr for your answers.

Using the DOCX file format as an interchange file format is excellent for text. As far as I can see, paragraph and character styles are preserved.

Links to images are not preserved (I don’t know if this is limited to importing from Scrivener, or, as it seems to me, a general limitation in the InDesign importer). The script indicated by @gr is an interesting workaround, in particular in projects like mines, where I’ve accepted to have placeholder strings for them. The script is however very limited, not allowing, for example, to consider classes (in Pandoc markdown, something like ::: {.screenshot} or ::: {.photo} ) to be converted to object styles. This means having to reapply object styles to all the images when in InDesign.

I don’t know what else might be missing. I’ve reduced my formatting to a bare minimum, and I’ve not experimented much, due to the limitations making it not a viable solution for me. I don’t know, for example, if something like column number change is considered.

No interchange format has been released by Serif for their Affinity Publisher. I can think that most of their users don’t need data exchange, and that the raw numbers are not yet high enough to invest on that. It’s a developing software, with the IDML importer being constantly improved, and plans for advanced scripting. Nothing has been told about exporting.

My personal idea is that the quickest, easiest solution they could implement, at the moment, would be two-ways Pandoc/CommonMark compatibility. Geeky, but with a growing support (many bloggers write in markdown, Scrivener outputs markdown, and something like PanWriter makes conversion to many formats effortless).

IDML is an important exchange format, but with the (not so) slow fall of traditional publishing, it might become less and less relevant. InDesign has already been sort of abandonware for years. It might be time to focus on more modern workflows.

Paolo

1 Like

I am thinking this might be addressable. It is clear that one could go after two different classes of urls which are distinguished by some kind of tag, so as to then treat them differently. The trick then, it seems to me, is whether one can retain a reference to the placed image once it is placed — like if the place function returns as value a reference to the resulting object. If so, then the algorithm can also apply to it any style or whatever can be applied to such a thing.

1 Like

Though I am finding it hard to re-find Adobe’s user scripting bible online, I have nonetheless found evidence (regarding placing images by script specifically) that something like this makes sense:

img = container.place(myImageFile)

Which certainly suggests the place function returns a reference to the placed object as expected.

Cheers!