Improve tables formating

I´m very satisfied whit Scrivener but the way to include tables and formatting need an urgent improve. It´s difficult to add, modify and format cells, rows and columns as well as other things into the table.
I would like to work with tables as I do in most of the others word processors.

1 Like


The easiest way of manipulating a table is using the ctrl-click menu:

I agree that the way tables work isn’t ideal, though. I didn’t program the tables or the text system in general, though - Apple did. The mess that is tables and bullet points is all part of Apple’s standard OS X text system. As a single coder, I have to rely on this text system as I don’t currently have the resources to write my own. Eventually I would like to replace the tables code with something better, though - hopefully for version 3.0 or 4.0, if we are able to take on more coders by then.

Thanks and all the best,

If making better tables with the Apple text system is not possible, maybe some parameters can be saved with the tables, thinking in perspective to exporting to other programs?

For example, in both InDesign and HTML, table header and body cells have semantic meaning. Maybe it doesn’t matter how they look in Scrivener, but what they mean in Scrivener. If there was a way to export tables as objects, with parameters like Table Header and Table Body identification, each with associated text styles, and save definitions for the columns width, it might be enough to have them right in the target program.

It wouldn’t even be bad to use an alternative system to write tables. Frankly, I don’t like any markdowns system I’ve seen as of now. They all deal with very simple tables, making something like multiline cells very difficult to edit. Maybe there is a way to use a system exclusive to Scrivener, making editing easy, that can be easily converted to one of the output file formats.


I use Excel and/or Numbers to make tables look as I want then past the PNG image into the document. Simple. I store the spreadsheet source in the Research folder to keep part of the project. This method hasn’t failed me in the many years of doing this.

Note for people who have “complex” table requirements, another workflow would be to extend markdown using something Quarto. This enables you to use R code to load data and generate very beautiful tables using libraries like kable, or gt:

This isn’t for everyone of course, it requires some knowledge of coding (in this case R, but I’m sure there is some tools for Python too), however it enables some very complex conditional tables including local footnotes etc. that are auto-updated each time you compile your Scrivener project.

Long-term, replacing the tables code will be the best approach, I think. A year or so ago I actually wrote a new tables system as part of a test app, and it worked well. It used the same approach Nisus uses internally. You could resize cells by dragging, select cells and columns, and so on. There were still some kinks to be ironed out, though, and some limitations. However, I’ve put it on hold since Apple announced TextKit 2, because I’m loath to spend a lot more time on code that I know I’m going to need to completely replace in the not so distant future.


Thank you for the hint, but it is something that I would absolutely avoid. This method would prevent access to reading machines for visually impaired people, look “pasted-in”, make editing and translating increasingly difficulty the more tables you have, and wouldn’t adapt to variable formats, like Web or eBook.


This is the first issue, of course. It would be impractical to code a long technical manual full of tables.

Another issue is that all the examples in markdown show “ideal” tables, populated by very short content. This may be useful for authors dealing with numeric data, but much less with real-world tables, where you have long paragraphs filling single cells. Having to enter them by manually rewrapping and aligning is not exactly comfortable and error-free.


Very good news for the future! Something that I want to stress out is that I wouldn’t personally care much for the individual look of a table, but for the general look of tables. That is, I would like there are table styles that can make the look and size of the table elements the same across the project. With different table styles for different types of table.


I have made an epub document that way.

I go with works now instead of waiting. might be waiting for Godot :wink:

Paolo, as a scientist you are right that numeric tables handled by regular markdown grids are mostly all we have to deal with (with things like R for more advanced statistical results). Using code can save a lot of time in layout depending on your field, and for numerical results it can be much faster to get R or python to do the hard work. But tables are used for much more than what we scientists use them for…

I’d be curious what sort of uses of tables / minimal feature set you would like to be able to use, is this for some sort of textual layout? This might also provide some data points to @KB on what is important, from your perspective of course…

A typical use of tables I do is the same you can find in the Scrivener manual itself:

Some of the cells contain long paragraphs of text. You can have multiple heading rows, and sub-heading rows. Vertical and horizontal alignment may vary.

Entering this type of content doesn’t seem, as far as I can find in the documentation and example, easy. Tables have to be entered trying to replicate the final layout of a table, so you end up having to make a semi-graphical work.

In the past I’ve imagined a way of entering tables, that has been decidedly refused. It placed cells that had to appear side-by-side in the final layout into subsequent paragraphs. Something like this:

<table .parameters>

--| Format
|-- Ext.
|-| Description

MultiMarkdown Conversion

Eports a plain-text MultiMarkdown file, useful for archival. In combination with…

Exports a LaTeX format file with full MultiMarkdown parsing. Note that if you are…



Hi Paolo, interestingly that table in the Scrivener manual is a normal Scrivener table, that gets compiled to markdown and then rendered to LaTeX. Here is the raw table in the scrivener editor (@AmberV styles it to look similar to the output, but this isn’t being used later on AFAIK):

The markdown intermediate looks like this:

| Format | Ext. | Description |
| :----- | :----- | :----- |
| **MultiMarkdown Conversion** |||
| MultiMarkdown | .md | Export a plain-text MultiMarkdown file, useful for archival. In combination with post-processing, this file type can be used to generate Pandoc flavour syntax as well. |
| LaTeX | .tex | Exports a `\LaTeX\,`{=latex} format file with full MultiMarkdown parsing. Note that if you are intending to export a `\LaTeX\,`{=latex} file that has been handwritten in Scrivener (without MMD), you should use the plain-text format, above. |
| OpenOffice | .odt | Exports an OpenOffice document, and is the best way to bring a MultiMarkdown project into the word processing realm. |

Some of the hard work for making the table look nice is being done by LaTeX, and I don’t know if @AmberV does any other tweaking there? But for example what looks like a rowspan is not really a rowspan.

As another aside, Pandoc internally now supports rowspan and colspan along with quite a few other table attributes. This is not yet available in the markdown reader, but work is ongoing. If so any improvements to Scrivener’s editor should be able to be translated to markdown tables.

Yes, there is a little more to it than the raw MMD syntax Scrivener generates, and the stock LaTeX output that MMD creates from it. What I do is start with that, and then go into the .tex file with an editor and manually polish the design of each table. Once I’ve got it looking the way I want, I copy the \tabulary line I end up with into the custom metadata field for the table binder item (this is why I put tables into their own sections).

So to work with this particular table as an example, if you load up the Markdown Compile Types binder item and check out its “latexTable” custom metadata field, you’ll find the formatting line for this. To see how that ends up in the .tex file, check out the “Table” Section Layout in compile settings. We are printing the latexTable value into what is essentially a specially formatted LaTeX comment that includes the section title (which as you’ll note is what is also used to generate the table caption).

The post-processing Ruby script then, as part of its line-by-line processing of the .tex file, looks for these specially formatted comment lines and matches the table caption with the custom tabulary line. When the matching table is found, the MMD stock tabulary is swapped out for the custom one.

If I didn’t use a script, then I’d have to manually go through with a text editor and swap out the table lines by hand. That was my life back in the v2 days, when it took several hours to finish a user manual compile.

If I didn’t store the custom formatting in Scrivener and print it out in a comment then I’d have to keep a list of these somewhere else for my post-compile checklist. If I didn’t design the table and store the result somewhere, I’d have to manually fix up tables every single time.

So there are layers of automation and self-help you can use here, to whatever degree of implementation effort you wish to take, where each layer removes one more manual step from what you have to do. The end result is completely automated. I don’t mess with tables once they are designed. The only reason to update its custom tabulary line is if I have to make significant edits that might change the layout.

Of course, another approach is to just toss the whole finished LaTeX table into a pass-thru block and not bother with the Scrivener→MMD route for it. I have done that before, for one table that was particularly tricky to lay out. And to be fair, LaTeX table syntax isn’t too noisy.

1 Like

Yes, this is a very nice solution to specific customisation, manually tweak the table design to your liking, then take that data and store it as custom metadata. Now when compiling, use placeholders to insert the stored customisation as a comment and use a script to rewrite the table with the previously identified tweak! :nerd_face: