Just a suggestion on figures, tables and raw code

Hi there,
every time I use Scrivener I am impressed, how smooth and relaxed work is going on. Good job! But there is one thing I always worry about. It’s the way scrivener deals with graphics and tables as well as with code snippets.

So I have a suggestion that might offer a simple solution:
Why not define additional types for the binder items? Let’s say not only “Folder” and “File” but as well “Figure”, “Table” and “Code”. The first two would define latex-like environments. It would be easy to handle, the title as caption, the inspector tools etc. available for every figure or table. Even the generation of LOFs and LOTs would be simple as you already have a concept to create TOCs.

The “Code” item should just pass through the written text to let the post processing deal with it as it is. Considering the great selection and filter capabilities of the composer this would be a fantastic benefit for all who use Scrivener to create complex documents for different targets.

May be I could help a bit to bring Scrivener to the next stage.

This is already easily done. Just click the As is tick box in the contents pane when you compile for output.

Don’t forget you can also change the icon of the item and metadata to make each binder item more specificetc.
Have a look Section 7.5 of the User Manual for document templates — you could set up figure, table, quote or whatever item templates you want. They would look different in the binder and their metadata would aim compilation.

As lunk suggests, I think what you want to do is already doable 8)

p.s. personally I use pandoc markdown for all my academic work, but I’ve never broken the document up just for a figure or table, but my Binder has document structure elements (methods, results section 1 etc.) and I use pandoc markup to specify figures etc. If my “Results 1” was broken up into lots of subdocuments at each figure block, I would find this much harder to manage…

I use Scrivener as it is for my academic work. The journals usually want the text as Word and tables and figures as separate documents, not included in the text.

@lunk: I know it can be done that way, but I find it a bit confusing to mix up text and code parts under the same item type. Having a “Code” item type in my opinion would simplify things as I don’t have to think about “Did I check the As is tick box”. Just select “Code” and code.

@nontroppo: Ok, this might depend on how your workflow looks like. My work is also mostly academic, sometimes papers, routinely project and research reports. Especially the latter are demanding a lot of combining and composing work as there are always external partners involved in our projects. So our report structures are very granular anyway, sometimes only one sentence or two per item. Nerve-stretching but excellently to handle within Scrivener.

The template solution is very useful without doubt and this is how I deal with graphics and tables for now. But from my point of view having dedicated items for images and tables would make thing easier and more consistent. Apart from the LOF/LOT matter.

Hi,

Thanks for the kind words!

This is exactly what the document templates system is for, though - it allows you to create your own types with different icons and settings, which you can then add from the “New” menu. There would be nothing gained in having dedicated types built into the program over you creating your own templates - all it would do would be to add noise for the majority of users who never need to use these types because they don’t work in LaTeX. So templates are definitely the solution.

All the best,
Keith

Ok. I see your point though I am not really convinced. Scrivener will remain my writing tool of choice anyway. Thanks for clarification.

BTW: It’s a pleasure to see that you at literature & latte are going into serious discussion with your users. That makes the difference.

You can place your figures where you want in either workflow; the advantages for me are that Pandoc generates a properly styled (block quotes, inline code, figure captions etc.), properly outlined (binder items get outline Heading 1-6), and fully referenced (Pandoc uses CSL style citation processor) automatically. Even better, you can give Pandoc an existing Word document and it will use the styles as a template when it generates your manuscript, so you can have everything in Word to your exact specification.

Scrivener > Pandoc > Word is a more fluid path overall IMO than Scrivener > Word (manual fiddling of formatting, manually rescanning for bibliography etc). Perhaps I’m a semantic pedantic, but a Word document with a mess of direct formatting and no outlining makes me twitch… :wink:

On the figures placement note, I was incidentally compiling for Nature today (the lofty unattainable goal for us scientists), and they now recommend combining figures within the main results text for first submission. It does make it more readable for reviewers after all… 8) But sadly they still heavily recommend DOCX as the submission format (LaTeX is grudgingly accepted for first submission only)… :cry:

@mxi: if you use mostly LaTeX, have you had a look at TexDown? viewtopic.php?f=21&t=36854&p=231476&hilit=texdown#p231476

The one thing that I would like to do is related to this but there could be multiple ways to implement it. Having additional document types is one way. The feature is the ability to have “new document types” so they can have unique formatting associated with them during compile. Currently we are limited to the 3 document types and levels underneath. But if you have more than 3 unique things you would like to format uniquely, there is no way to do it unless you use a complex system of hierarchical folders or document groups.

It would be powerful without adding a lot of complexity to have a way to “tag” documents so that the special document shows up in the compile Formatting list. For example, the OP could use this to tag Code documents and assign code formatting in the compiler. Similarly, this could be used for Figures, Tables, or any other special things a user wants to format uniquely at compile time.

In my case, I’m investigating options to drive compile output so I can import into Nisus Writer Pro and apply a macro to apply NWP styles. For example, I like to use documents for each paragraph or several paragraphs within a section of sub section. Interleaved in these paragraphs are images and “inline comments”. Inline comments are simply a few lines that I want to format as single line spacing in a smaller font and indented more than body text on the left and right to stand it off from the body text. If I had a way to either create a new document type or tag the existing document so that it shows up as a new “type” in the compiler’s Formatting panel I could do this and more very easily.

Hi,

For this I’d follow the same system as for body text styles: set up appropriate presets, giving them a unique colour and then in NWP create styles in the style collection you are using, copying one of the

If Find All @Text<[^\n\f]+>, 'Eau' Menu “:Format:Paragraph Style:Normal” Menu ":Format:Text Color:Remove Text Color Attribute" End

snippets and pasting it in at a suitable point. Then give the [^\n\f]+ part the colour you have set in Scrivener and replace the style name with the one you want. That is how I built up the complete macro from the individual code snippet for which I had Martin’s help. You may not be able to detect the different colours by eye, but each of them does have a slight difference of colour.

Mark

Yes, thanks. That makes sense and is what I’ve done. I created a document template that uses the style/color that will be the “tag” in NWP - one for my “tips” and one for photos with captions. I haven’t tested the output yet but I don’t expect problems.

It would still be more intuitive and less hand work / opportunity for human error if Scrivener could format these “things” at compile time like it does with folders document groups and documents.

Well, this should be solved with the proper Style system and whatever magic will happen in the new Compile in Scrivener 3 8)