- tables are not a good way to provide information: try to avoid them (charts are way better!)- tabulators often produce a nicer (and simpler to read) layout- and if you really think you need a table, create it in libre office and import it as png, pdf, or svg (depending on the table and the scribus version)

imo, the tables tool should be hidden by default, since it's not ready for production

I have just done the following.1. I created new doc and created same table as in original doc.2. It works perfect.3. Opened original doc.4. Copied newly created table in new doc and pasted in original doc.5. Same problem.Something in my original document is buggering me around. For now I will save as jpg and import to original doc.

Thanks for attaching the file deonholt but it was made with 1.5.3 so I can't open it.I had a feeling that the problem might lie with the formatting/styles - maybe line spacing, something like that - but, since I don't use 1.5.3, I can't check it. Maybe someone else can.

I would generally recommend what a.l.e says above; tables are best done elsewhere and imported into Scribus.However, do an internet search on "when is table better than chart" for a bit more info' on when to use tables/charts. For example, this page https://infogram.com/blog/do-you-know-when-to-use-tables-vs-charts/ has some good reasoning.

sadly, i don't really agree with their table example. at least not in the context of scribus.

in my eyes, if there are interesting values about the salespersons, they should go in the text.i don't see much value in putting that "static" table in the document.imo, before publishing those numbers, one should think about the message to be conveyed.in this specific case, probably, the focus is on the evolution of each person's sales through the months.then something like the attached chart is much more expressive.

i agree with the author of the article, that sometimes you want to provide the raw data to your readers.but that raw data is something that should go in a (linked, online) spreadsheet or -- eventually -- in the annexes.the reader should be able to interactively "play" with it and we have nowadays tools for doing that.(hey we have jupyter nowadays!)

the more i think about it, and the less i'm convinced that there are reasons for putting tables in a layout document...except the laziness of the author : - )

my position: the tabulator are often enough, and if they are not, the data is probably better presented as a chart.

all that having being said, the main message is still: don't use the table tools provided by scribus.

p.s.: i welcome examples of data that cannot be presented as tabulators but needs a table! (for what it's worth: the example in the linked article can be created with tabulators in scribus... even if -- very sadly -- you have to use a little "hack"... since scribus does not have background colors for paragraphs)

Microsoft (MS) does not produce an open source office. (so there is no open source MS office)(this is not just a small detail... Microsoft is jealously hiding (sometime in plain sight...) the details about the files his office suite produces and does not even try to be in any way compatible with other offices which are not labelled MS. that is a pain and it's microsoft's fault (or strategy).)

back to the tables. the best formats for importing tables (and charts) are:

- PNG, it works with every version of scribus and office. you're importing a bitmap, of course, but it most cases it's good enough. just make sure, that the PNG is at the right size.- SVG: can work in both 1.4 and 1.6 and you get vectors. but you have to make sure that all features in the SVG are suported by scribus. and the text will be converted to paths.- PDF: can be imported as bitmap in 1.4 and and as bitmap, vector in an image frame (with limitations) and as vector (with text converted to paths.

you can use any image format that is supported by for export from office and for import in scribus, but those are probably the best options.