Table support?

Hi,

I am writing a paper using Scrivener, and the tables and figures are a big part of it. However, I found that the tables in Scrivener are very hard to use. When I compile to DOC, the tables are also screwed up. I am wondering whether it is a problem of Scrivener, or something Scrivener is unable to deal with? Anything I am missing here?

Also, I miss the cross-referencing and auto-generating table/figure name function in WORD. Is it possible in Scrivener?

Thanks!

Denny

Denny

Your first question has come up before. It’s worth doing a search on “Table”, although it’s liable also to produce answers relating to the table at the Red Lion pub at Stockport, UK ( :wink: don’t ask).

But here’s one recent answer from Keith that sets out the overall picture.

H

Hi Hugh,

Thanks for your reply! I will do a search before posting in the future!

Just as I suspected, the table function cannot be easily improved due to Apple’s implementation. I wish there would be an easy workaround, though.

Denny

I have made a couple of improvements to table support for 2.0, based on some code I found recently, but they aren’t major. Basically in 2.0 a new row will be created when you tab out of the last cell, and also the ctrl-click menu will allow you to add or delete rows and columns. Other than that, there is little that can be done, though, I’m afraid, without writing my own tables implementation, and I don’t have the resources for that at the moment.
All the best,
Keith

I write documents with Scrivener that will contain lots of tables, and here’s my advice, also posted elsewhere. I create the tables in Nisus Write Pro, number them, put them in the same work folder that contains my Scrivener file, and link to them as Project references in the Scrivener Inspector. This makes it easy to refer to them. I add a place-holder for each table in Scrivener itself ("[Table X about here]"). After I have run Compile Draft, I import the draft into NWP where I do the final formatting. If I am writing a report, I insert the tables one by one into NWP. If I am writing for an academic journal, I just include the tables in a separate section.

Steve

I’m a new Scrivener user, and tables that export properly to Word are essential for me. Here’s what I’ve figured out as a work-around for the problems with RTF support in OS/X. My particular application is APA6 format manuscripts, which have a fairly specific table style.

First, make the table in HTML and convert it to RTF using textutil. I like to use BBEdit, because its HTML preview mode is very handy as you lay out the table. You won’t be able to use the


horizontal line tag, because it is not supported by textutil or textedit. Instead, you should draw lines using sequences of non-breakable space ( ) embedded within strike-out ) tags. Don’t fuss with the lengths of these lines because after you import the table into Scriv, you can adjust the length using copy and paste. Also, if you need to adjust centered numbers at the decimal point, the best way to do that is to use the tag for those cells to establish monospacing, and to insert nonbreakable spaces to make the adjustments. Actually, I like to make my tables using shell scripts that read from the raw data files, so all this gets done automagically. Use font tags around the text in the file to set the main table font, and also put the font and fontsize on the command line. Once the table looks right in the preview, try converting it to RTF via textutil -font "TimesNewRoman" -fontsize 12 -convert rtf FILE.html (or whatever is appropriate in your context), and then drag the rtf file into the Binder. In APA6 format, the title and the caption are double-spaced, so you may need to tweak that in Scrivener; plus, as I said you may need to fiddle with the length of any horizontal lines you inserted.

Next, when you compile the document, there is a critical step you must do before trying to open it in Word. Here is a Terminal command that should work:

sed -e 's/\\trwWidth[0-9][0-9]*\\trftsWidth3//g' -e 's/\\clwWidth[0-9][0-9]*\\clftsWidth3//g' < FILE.rtf > FILE-fixed.rtf

What this does is to remove some RTF commands that are inserted incorrectly into the file by textutil. They cause Word to format the table about twice as wide as it should be, so half of it is off the page. Apple programs ignore those RTF commands, so the same table looks good in Scrivener or TextEdit, but too wide in Word. (I’ve filed a bug report with Apple about this.) You could run this command on the product of textutil before importing it into Scrivener, that would also work. I have this command as part of a post-export Automator script I use. (I plan to post it here along with my APA6 Template for comments when I get it finished.)

Anyway, once the table is in Word, you may need to fiddle with the overall spacing a little, but that’s about it. The fonts and alignment should be OK.

Greg Shenaut

Could you e-mail me with more details about this? I’ve customised the RTF export, overriding certain of the standard OS X RTF commands (basically by hacking the standard RTF exporter). I’m not quite sure what sed does etc, but if you could e-mail me with the details about exactly what this does and why, with an example, it might be possible for me to hack it into the RTF exporter if it is a bug in the text system. Also, if you have some good ideas for a Scrivener APA6 template, let me know, as I’d be interested in including it as a 2.0 template (and can bung you a free upgrade in return). I’m just quite interested in what you are doing here.
All the best,
Keith

sed, among other things, lets you apply substitution regexps to text streams, which is all that is being done here. The “-e” command means to execute an expression, in this case two of them. If you can apply regular expressions in Obj-C easily, they could probably be inserted into the exporter verbatim. Depending on the syntax, the expressions here are:
1.
Substitute Search Pattern:

\trwWidth[0-9][0-9]*\trftsWidth3

With: Nothing and apply with the global switch so that multiple matches per line can be made.

Substitute Search Pattern:

\clwWidth[0-9][0-9]*\clftsWidth3

With: Nothing and again applying globally.

If you cannot use regular expressions, it might be a little more difficult, but these phrases roughly parse out to:

[b]\trwWidth[/b] + Digit + Any number of further Digits (including zero) + [b]\trftsWidth3[/b]

And

[b]\clwWidth[/b] + Digit + Any number of further Digits (including zero) + [b]\clftsWidth3[/b]

Since the variable part is in the middle, you could potentially do a substring search using the two static elements in quotes as delimiters.

Incidentally, Greg, is in there any merit to [b]/[0-9][0-9]*/[/b] over [b]/\d+/[/b] ?

To tell the truth, I’m not familiar with \d+ . Is that supported by sed? If so, then as long as it matches one or more digits, no problem. The construct [0-9][0-9]* is just sort of muscle memory for me at this point.

Greg’s method ensure that there are 2 numerals as a minimum match. The better way to do this would be \d{2,} but I am not sure sed catches that. And I am too lazy to find out right this minute.

Actually I think that is just one or more. The second class is asterisk, and thus can be matched zero times. So ‘1’ would match as would ‘12’, but I don’t think \d or {} is a part of BRE, and I don’t think \d shorthand is a part of BSD sed’s ERE parser, either, come to think of it. I remember running into that before.

Update: According to my test, even + is not a part of sed’s BRE. I needed -E to get /[0-9]+/ to work.

I clearly spend too much time in perl.

Thanks. Unfortunately Cocoa doesn’t allow for regular expression searches, which makes things a little more difficult, but by no means impossible.

However, it’s probably not desirable to have Scrivener’s RTF exporter erase trwWidth and clwWidth controls from the RTF, as this would mean cause all tables to have evenly-sized columns and to autosize across the page, which may not be desirable for all tables. It’s a tough one, because the way the OS X text system handles these controls is clearly wrong - even after I resized in Scrivener the table in the example Greg sent me, it was still wrong when I copied and pasted it to Word.

On a related note, I quite like the idea of using HTML to build tables, though. Table creation in the text system is notoriously difficult. I quite like the idea of having a simple HTML editor with a preview pane that could be used for dragging to the main text as RTF elements for things like tables… Hmm.

All the best,
Keith

Ooo, I like that idea for a different reason. If you handled tables as HTML internally, that means they could be passed along via MMD formats verbatim, meaning MMD users can use Scrivener tables instead of syntax (the one area of MMD I dislike working in, honestly, is tables; though I cannot really fault it because tables are a complex entity—no way around it).

Hmm, I don’t think my idea would cover that, I’m afraid. I was more thinking of just a sort of window where you could type in some HTML, see it appear in a web view on the right, and copy from the web view to your text (and save snippets for later use). Although you could just paste the HTML into the text instead of the formatted table from the web view, I suppose (can MMD take HTML tables then? I thought it had its own syntax for tables…).

In other words, once the table is in the text, it would be a regular RTF table with no knowledge of its HTML origins. Hmm…

Ah, I see. I was thinking you were thinking along the lines of a small embedded table parser in the text view, so that internally the document would support HTML coding; dispensing with an external view; basically embedding that process you are describing into the editor stream.

Yes, MMD has its own table syntax, and such is preferable to using raw HTML by far. The only exception would be if some “front end” was generating HTML already, then it could be an alternative in some cases—much as using Scrivener’s footnote generator is a nice alternative to typing in the raw codes.

Keith, I hadn’t picked up on the constant-width columns part, but now that you mention it, that’s right. So, the next thing to try is to divide the number following those width commands by a constant factor instead of just deleting them. As a test, I hand-wrote this script based solely on the contents of the particular RTF file I’m dealing with: [code]
#!/bin/ksh

sed -i try-table.rtf
-e ‘s:\trwWidth12540:\trwWidth9450:g’
-e ‘s:\clwWidth12420:\clwWidth9360:g’
-e ‘s:\clwWidth1740:\clwWidth1311:g’
-e ‘s:\clwWidth1800:\clwWidth1357:g’
-e ‘s:\clwWidth1840:\clwWidth1387:g’
-e ‘s:\clwWidth2420:\clwWidth1824:g’
-e ‘s:\clwWidth3620:\clwWidth2728:g’
-e ‘s:\clwWidth4300:\clwWidth3241:g’
-e ‘s:\clwWidth4340:\clwWidth3271:g’
try-table.rtf
[/code] and ran it on the RTF version of my table, which I then imported into Scrivener, where it looks correct. (In my case, there is a title and a table note in the html which has to be set to doublespace after importing into Scrivener, but those things might better be implemented as scrivenings surrounding the actual table.) After compiling the draft to RTF, the table imported into Word, with all spacing and everything correct, no manual adjustment necessary. The next step will be to generalize this so that my script will convert the numbers arithmetically instead of me entering them manually. Or, the conversion could potentially occur upon importing an RTF file with no margins set into scrivener, I suppose.

To come up with the scale factor, I noticed that the printable width of an 8.5 in wide page with 1-inch margins is 9360 twips, but the full width of the page in twips is 12420, a number that appeared in the clwWidth command. So, I used the following scaling factor in the above: (paperwidth-(lmarg+rmarg))/paperwidth. In other words, textutil sizes the table without regard to the margins, and my script resizes it to fit proportionally within the margins.

I don’t know where the 12540 comes from in trwWidth–it would be 120 twips wider than the papersize. But, I just scaled it along with the others.

Greg

Just to follow up on that last message, here’s an Automator app (htm2rtf.app) and a small sample html table (try-table.html), if anyone wants to try it out. The app will convert and rescale the table (or hopefully, any html table) so that it will import correctly into Scrivener and display correctly in Word. It may work with other html files–it will convert them–but I’ve only tested this with simply files containing one table. It definitely isn’t safe to use it with files containing more than one table, because the script doesn’t really understand rtf and it will try to use the same scaling values across the whole file.

The app asks you to browse to the html file, and then produces the rtf file in the same folder, with the same base name.

It rescales what textutil produces to fit on a page 8.5 inches wide with 1-inch margins, and uses 12-point Times New Roman. These could all be changed pretty easily by editing parameters in the shell script embedded in the Automator app.

Once it does the conversion, drag the resulting rtf file into the Binder.

Greg Shenaut
htm2rtf.zip (726 Bytes)