Hi, I have an issue when exporting a scrivener document with some tables inside in MS Word. The exported tables are too big for the page and I have to manually select them each of them and use the option “AutoFit Content” in MS Word.
Am I doing something wrong?
I would love to resolve the problem one way or another because I have many many table in the scrivener document, and every time I export a draft I need to fix all of them…
I am currently using the beta version of Scrivener 3 (because of the image output problem).
I would enable View ▸ Text Editing ▸ Page View for a moment and make sure the tables are set to a size that fits within the margin area. Page View should use your compile settings by default, but if something looks off about it, double-check that in the Appearance: Page View preference pane, at the very bottom.
I’m getting what I think is the same problem.
It’s not a problem with the formatted width of the table in Scrivener. It’s a problem that when the table is compiled to .docx it does not hold its width as set in Scrivener or stay at a width within the defined page margins.
I might need some sample data to work with. Attached is my attempt to reproduce this. I have three different tables: one where I never touched the width of it in Scrivener, the second where I intentionally squeezed it down, the third is larger than any sheet of paper (you’ll need to disable Fixed Width in the main editor, or Page View, in order to see its true size). But when I compile that to RTF, all of the tables come out the same width as expected.
Thanks, that helps. I don’t have Word in fact, so I cannot see the problem itself (LibreOffice and Nisus Writer Pro both seem to sensibly limit table widths to the text column width), but I can see signs of what would be problematic behaviour in the source file. Here’s the best way to do so:
Use the View ▸ Text Editing ▸ Show Invisibles command so that you can see the borders on your tables. Use View ▸ Text Editing ▸ Show Ruler.
In the Appearance: Main Editor: Options preference pane, disable Use fixed width editor.
Back in the editor, widen the project window and/or zoom out so you can see how far to the right some of these cells are set up to.
You’ll note that some of the cells have a floating width that tracks however wide you make the editor. That’s what a “normal” table should look like—one that hasn’t been resized manually at all (even interior cell widths).
Every single cell that does not float to the width of the editor is set to actually be as wide as you see it. I see a variety of widths in your source, ranging from around 590 points wide to 800. That’s a problem when your sheet of US Letter paper is itself only 612 pts wide from edge to edge. With typical 1" margins all around, that leaves 468 pts as the width of the text column. So even the narrower tables are too wide for the text, and the widest tables are several inches beyond the sheet of paper.
With your editor “zoomed out” like this, if you set everything down to 6.5" (again assuming 1" margins on US Letter) on Scrivener’s ruler than that should work well. When margins are added, that will become 7.5", or one inch shy of the edge of the paper and flush with the text margin. But you might need to experiment a little to get the right maximum value.
Amber’s resolution “I would enable View ▸ Text Editing ▸ Page View for a moment and make sure the tables are set to a size that fits within the margin area.” Didn’t help me. My tables display properly in Page View.
I think it’s time to add a folder just to talk about tables to the Literature and Latte discussion board. There is a lot of ground to cover and maybe users could help each other out, and maybe L&L could collect some useful, organized feedback to help it deal with the future of tables.
I’m writing a lot of stuff that needs to be published across formats and where table presentations are important.
Inevitably you have to bring tables in from other sources. Figuring out the easiest ways to bridge to Scrivener is not easy.
I appreciate there has been some effort to make this simpler, but in my case it’s actually complicated things.
Anyway, I appreciate this whole area of functionality may take some time to evolve, so having some place where Scrivener users could share ideas about best practices would be really helpful. If some of those were to be sorted through and some well thought out “how to” blog items were created, that would help, too.
Putting back the WYSIWYG table to graphic format for ePub would help. Introducing WYSIWYG table to graphic into the PDF compile would be helpful, too.
I can see big upside for some ebook publishers in strengthening the CSS options for tables, too. Partnering up with a developer who’d create a tool for quick development of custom CSS usable in the compiler would be great – but keep in mind there is a need out here to be able to compile a table that’s going to look great (and not page break funny) in PDF and the word processing functions, and then be able to convert to a form that’s going play nice in ebook formats. Sometimes a graphic image is what comes closest to doing this. But being able to chose the output option at the per table level would make sense.
Anyway, maybe user discussion can become part of the solution?
One important limiter to keep in mind is that Scrivener’s tables are pretty much identical to how tables work in TextEdit, and every other stock macOS editor that supports the full rich text editing component. We’ve added some convenience commands that TextEdit does not have, but the core technology itself comes from the text engine and cannot be changed, unfortunately. That includes conversion for import, export, data storage in the file and the user interface from top to bottom. So as far as getting a round table going about what’s best for Scrivener’s future—we’re a bit limited there by what Apple provides.
At this point in time, HTML/CSS tables should be more than adequate for the job. The option you refer to is something that was implemented back in the days when Kindles linearised table content into lines, and hardly anything could properly display them. Graphics were for years the only good way to even get something that looked remotely like a table. The actual result was only so-so, and with all of the weaknesses that come along with using raster graphics for text in a container designed to display itself on everything from business card sized screens to something as wide and crisp as a full-colour magazine (not to mention a fundamental incompatibility with the concept of giving the reader presentation choice over fonts, font size and overall colour theme).
But if you really want graphics of tables in your eBook I’d recommend using design-oriented tools to make them, take a screenshot or export it, and use that. Now you have a nicer looking table than you could ever make in Scrivener, for all the formats you need.
A screenshot of the table would look identical to the result in the PDF, meaning the only accomplishment is making the table blurry and more difficult to read at any size other than just so.
Well that part I think we do all right on. If you go into the Tables & Lists compile format pane you’ll find four presets for table design. Select the one closest to what you desire, then click over to the CSS pane. In the Default Stylesheet column, search for “/* Tables */”. The preset selection you chose will be reflected here in the CSS. Copy and paste the parts you want to modify over into the Custom Stylesheet column and have at it. Or paste in your own hand-designed CSS, either overriding the preset in whole or in part, or set the pane to full custom for complete control.
Tweaked a bit around, and it does indeed work! Thank you! So, the normal behaviour is that every table has a floating width and in while exporting the document it does automatically resized the table, right?
Yes, with the caveat that it is very easy to end up with a table that has a fixed width. The floating width behaviour only remains in effect so long as the metrics of the table remain untouched. Resize the width of column A, and now the table has metrics stored into it, which includes a total width. So whenever you resize columns, just knolw that you now need to babysit the total width.
Using Page View will remain the best way to change the size of a table or its column width and row height settings, since it won’t allow you to resize a table beyond the width of the page view frame, and any changes made to the metrics in that view will reset the width to the maximum allowed area (if it is in fact wider than Page View shows).
