Battling with tables

Previous topic - Next topic



I have a table with three columns and 5 rows.

For some reason I cannot figure out some cells show the X in the corner when I enter the first letter of text. Others don't do it and some do? What I am doing wrong? Will appreciate any help.

You will notice the little crosses in the cells on the attached image. I really cannot explain or understand this. When I create a new doc, it does not happen. This is so frustrating.

The second image shows  to where Scribus allows text to go. The bottom right cell cannot even take one character.

I have just discovered that this does not happen with new docs. Where could I have told Scribus to do this?


[attachment deleted by admin]


Would you be able to attach a sample SLA that shows the problem?


Quote from: GarryP on March 09, 2018, 01:30:49 PM
Would you be able to attach a sample SLA that shows the problem?
Hi Garry.

Thank you very much for your help.

Please find file attached. Cells with X bottom right are those which does not want to populate.

Thanks again.

[attachment deleted by admin]


the standard hint: don't do table in of scribus:

- 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


Thanks for the reply.

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.

Thank you for everyone's help.


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 has some good reasoning.


thanks garry for the link!

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)

[attachment deleted by admin]


btw, here a few table i consider "meaningful" (or don't have an easy alternative):

- : but i fear that it's not trivial to get a table tool to create it...
- : see the table at the top right. but, again, find a table tool that can do triangular fields
- catalogs: tables are a ugly solution there... but i don't see any alternative...



And let it not be forgotten that charts - and tables - can be made to deliberately mislead people.
There are some interesting examples here:

Charts or tables? In the end, it depends on who you're speaking to and what you want to tell them.


A quick question pertinent to this: Libra Office is just an open source MS Office right? For the most recent version of Scribus, what's the best format to important tables from Office into Scribus?


LibreOffice is an open source Office.

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.


Everyone here who helps us very helpful and does so in good faith. That being said, a question about how to do tables provokes them to try to persuade you that tables are bad. That's NOT helpful or even pertinent. I use the table function in Scribus because producing them in Libre Office just makes an image file that doesn't retain sharpness when exporting at differently dpi (say, exporting the same document for web and print). You are getting the Xs because whatever you have in that cell is more than the size the cell can currently contain. Resize the cell. The table function in Scribus is funky but will work if you're patient and is often the only real solution for certain tasks/projects. Take this from a user who tried to solve the table issue using the tabulated text option, vector option, and image option and eventually had to go back to actual Scribus tables, which ended up working fine.


I want to second that: Tables are important for appropriate presentation, semantic representation, of certain data. Everything that has matrix structure (e.g. dates vs. participant groups or locations) is naturally represented using a table.

Managing this data outside of Scribus is cumbersome. Importing it as a PDF or, worse, image is compromising the document quality. It should be normal to suggest using Scribus tables as the preferred way, for both ease of use and the print quality of the end result.

Scribus tables have a few bugs and usability issues that need to be addressed, though (e.g. changing paragraph formatting and table borders across several cells). Fixing this should be a high priority. The fact that the source code is hosted on Sourceforge doesn't make collaboration for this easy though, unfortunately.


hi bittner

the source code is hosted on the scribus own svn server:

svn co svn:// scribus

which makes collaboration slightly more attractive than the sourceforge tarball.

for your comfort, i'm maintaining a github unofficial mirror:

a gitlab mirror is being setup...


instructions for compiling are here:

instruction  for compiling on windows with visual studio will follow very soon.