Scrivener’s content files are RTF. Most of the associated support files are XML.
1 Like
Not unanimous. I am working quite a lot with citations and it is the cornerstone of my workflow that it is a third party app—the “wonderfully bloated” Bookends—that handles the references and the citations.
The simple reason for that is that although Scrivener is my main and unconditionally loved writing app for all texts which are ready to be sent out into the world, it is not the only app I am using for work related texts.
When I am quoting from print books almost always I use Drafts on my iPhone. I collect these quotes and other material in DEVONthink, my knowledge repository. And move the quotes into a Scrivener project when I need to.
This only works because I can use the citations from Bookends in all three apps—and in all others I might use in the future. Because there is no Bookends integration but Bookends is a native macOS/iPadOS app and uses on of its basic features, the clipboard. Getting citations from Bookends into Scrivener is very easy and has no need for any workaround.
If you don’t call finalizing—is that the processing you refer to?—the citations and generating the bibliography in the compiled document and not in the Scrivener project itself a workaround, that is.
And yes, I use temporary citations, i. e. citations not yet formatted with a style, for all these quotes. That way I will be able to choose which format I will like or what will be recommended for a text in the however far future. On the other hand this calls for a last step of formatting—processing?—the citations in the Compile output.
Would I be against Scrivener doing this in-project or in-Compile? No, of course not. If it then worked for all of the many possible Compile formats (and not just with RTF and DOCX as it does now with Bookends) that would be a major improvement. But if Scrivener had integrated some conduit to a reference software I could not use with the other software that is part of my workflow I probably would not use it.
4 Likes
I appreciate the discussion points here. A middle-ground would be a more built-in way of calling Pandoc, or more generally pre-processing and post-processing pipelines. Many of us have hacked together our own systems, but it’s been a huge front-loaded investment (thankfully with much return on that investment). With every hacked-together system, there is the ever-present risk of some component breaking. So a new Compiler with better options for pre-/post-processing using Pandoc or Quarto, etc., would be well-received.
That said, Scrivener is many things to many people, but it simply can’t be everything to everybody. It is a lovely space for creating drafts that get exported into some destination format for further work. Converting a document into another format is the signature strength of Pandoc, too – which is why Pandoc would dovetail nicely with Scrivener’s Compile step.
5 Likes
The proposal here is to rely on third-party citation managers[1] — no one has proposed building reference management into Scrivener. What the proposal is, just as our beloved compiler already make caption styles turn into captions, or adds options to insert headers and footers, to translate metadata etc., for the compiler to turn the temporary citations already provided by a third-party citation manager into formatted text just as an RTF italic is turned into PDF italic text.
There are many tools already written, and so at its simplest the compiler pipes text in and gets formatting out. L&L do not need to handle citations, do not need to manage a database, do not need to develop translation styles. It is even easier if Scrivener formally bundles Pandoc, Scrivener’s MMD outputs have been battle-tested for years already so we know it works. The compiler needs some settings in the UI[2] and be able to pipe text, something it is more than capable of doing already, as evidenced by the many output formats that are not RTF Scrivener handles already.
2 Likes
But the compiler already converts RTF into many outputs, including text and markdown, i.e. the format Scrivener writes data to disk in is does not preclude a workflow in the compiler.
1 Like
For the interested reader, I will link to a portion of a related discussion.
2 Likes
Scrivener already uses the concept of compile a document and about the concerns of
Scrivener already rely on third-party services, like the MMD compiler and other tools to generate other formats. The real point here is that the pandoc is much more mature now and offer out of the box all the things needed for structural writing. This would improve and simplify Scrivener capabilities, that is the point for consideration. Today they may have headaches to adapt their internal rtf format with pandoc, but I am sure that for the concept of compiling document, this is will payoff very soon. Also, from the same engine, they can export for all formats that they already work today.
You are already working with citations, this endorse my point. What you describe is an expensive workaround, nothing more than this.
I understand that have people with very ‘wonderful’ workflows. This reminds me the hilarious discussions in the MPU forum, the so-called Mac Power Users (“Power” in a very interesting sense). In this place you will find the real Kings of Bloat. There, you will see how people love to spend $1000 per month and still having headaches to integrate all their 500 game changers apps for huge productive.™ Or how it is very interesting to change your golden workflow every month for maximum-plus productive™
For sure you can make an expensive bloated combo with DEVONthink, Bookends, Tinderbox, and whenever you want. That is not the point.
The core of the discussion is that Scrivener is really a software solution for writing, and our suggestion is to improve the compiler to make it a complete solution for document export.
One step closer! Now it is just the main file and some associated files. 