Tables

Previous topic - Next topic

PastaShock

From previous discussions on here, I have learned that table support in Scribus still something that needs development work.

Well, I am not a developer, and I'm not willing to learn and step up and add to the table support in Scribus. So, I will not criticize the table support in Scribus, or make silly demands. Instead I will ask for workarounds.

I'm recreating some existing RPG books from the 80s as a fun little side project. Most of these books have lots of tables in them, and I'm just trying to find out if there may be an easier way to do tables than what I am doing.

I first tried to use the table support built into Scribus, but I could not get it work for my needs.

Next I tried an external tool. I found a website that let me make a table by pasting a Markdown table and then exporting it to SVG. That did not work too well. And the table wasn't searchable when I created the final PDF.

I tried to make a table in LibreOffice Calc and then export it. But I could only export as a PNG or JPEG. I was going to to put the Calc table in a Writer file and then try to import that, but haven't gotten that far.

What I'm doing now is using paragraph styles with tab stops. I have one style for the table header, and one style for the table data. This lets me easily reposition columns just by editing the styles.

Is there a better way to do tables that I might want to try before I really get far into the book?

I'm debating writing a Python script that just prompts for the number of columns and rows, and the width of the row, and creates a Paragraph Style with the tab stops in the proper spots. That would save me some time.

Any wisdom on how you do tables would be greatly appreciated.

a.l.e

In the current state of Scribus, tabs are probably the best solution.

If you show a few samples of tables you want to create I can explore if it's possible to write a script that creates some sort of lines around text frames...

PastaShock

Quote from: a.l.e on November 01, 2025, 05:37:35 PMIn the current state of Scribus, tabs are probably the best solution.

If you show a few samples of tables you want to create I can explore if it's possible to write a script that creates some sort of lines around text frames...

These tables don't have any lines in them. Here is a sample page. I already did the first table using a tab paragraph style and some creativity.



As you can see, other than the first table, the rest are pretty basic.

Here is what I did with it:



The annoying part is I'm working off a PDF, and not a physical book. So I have to print out the pages with tables and get a ruler and measure them, which is time consuming and a waste of paper and toner.

PastaShock

I'd also like to give a shout out to the open source font Perun, as a nice replacement for Univers. It's not 100% glyph compatible, so you'll need to check your document. But considering what Monotype charges for embedding of Univers in a PDF or ePub, it will save you thousands a year in licensing costs.

Nermander

You could import the PDF page into a separate "help layer", adjust the opacity and create your content on top of it. When you are done you can just delete the "help layer".

PastaShock

Quote from: Nermander on November 01, 2025, 07:33:54 PMYou could import the PDF page into a separate "help layer", adjust the opacity and create your content on top of it. When you are done you can just delete the "help layer".

That's a good idea.

AdmFubar

would a short height multi column text frame work for this? You would have to make one for each line, the duplication function might make it easier to create them.
Using Scribus1.6.1, 1.7.0 openSUSE 15.6
Advanced hobbyist

a.l.e

So, I had a look at what the scripter can do with paragraph styles and tabs.

I think that I have good news:

scribus.createParagraphStyle(name='table_2', tabs=[(50),(70, 1),(100)])
Will set the tabs for the style table_2 at the position 50, 70, 100.
If the style already exist, it will update the position of the tabs.

You can define left, center and right tab with that.

I've now created a script that uses the text in a (non printable) text frame to define tabs in styles:

https://github.com/aoloe/scribus-script-repository/tree/master/tabs_definer

""" Define tabs in styles, based on the content of non-printable text frames

For details see the README file.

(c) MIT ale rimoldi"""

try:
    import scribus
except ImportError as ex:
    print('\nThis script must be run from inside Scribus\n')
    raise ex

def show_error(message):
    scribus.messageBox('Scribus - Script Error', message, scribus.ICON_WARNING, scribus.BUTTON_OK)

def main():
    tabs_aligment = {'l': 0, 'r': 1, '.': 2, ',': 3, 'c': 4}
    if not scribus.haveDoc():
        show_error("No document open")
        return

    if scribus.selectionCount() != 1 or scribus.getObjectType() != 'TextFrame':
        show_error("You need a text selection")
        return

    current_unit=scribus.getUnit() #get unit and change it to mm
    scribus.setUnit(scribus.UNIT_MILLIMETERS)


    text_definition = scribus.getAllText()
    for style_text_definition in text_definition.split('\n'):
        style_definition = style_text_definition.split(',')
        style_name = style_definition[0]
        style_tabs = []
        for tabs_definition in style_definition[1:]:
            tabs = tabs_definition.split(':')
           
            position = int(tabs[0]) if tabs[0].isdigit() else float(tabs[0])
            # the tabs position is always in pt
            position = position * 2.835
            align = 0 if len(tabs) == 1 else tabs_aligment[tabs[1]]
            style_tabs.append((position, align))

        scribus.createParagraphStyle(name=style_name, tabs=style_tabs)

    scribus.setUnit(current_unit)

if __name__ == "__main__":
    main()

tabs_definer.gif

PastaShock

I think you just made my life easier. Thank you!

a.l.e

While writing the script, I've reported an issue with the tabs' unit:

https://bugs.scribus.net/view.php?id=17676

The bug has been fixed and, now, the tab values are defined in the document's unit.
I've patched the script and it does not convert anymore the values into points, if the version of Scribus is 1.7.1 or higher.

So, if you're using the current 1.7.1svn (as of the time of writing), you will need to get the fresh version of the script from the Github repository (linked above).
(If you're using an older 1.7.1svn you must stick to the older version of the script; if you're using 1.7.0 or 1.6.x you can use any version of the script... it's simple, isn't it? : - ).

omoro

A very basic solution :
Make a picture of the table with screen copy
Import the picture in a frame

Nobody will see the trick when it's printed...

crlMIDI

Workarounds (@PastaShock) seem to be the way to go here, though I'd rephrase that by proposing better connectivity between applications, mainly LibreOffice, Inkscape, LaTeX and Scribus. Each has its own essential uses for finished documents, but users with different experience and amounts of know-how need to be able to switch between them more easily.

Everyone needs to make last-minute alterations, without the chosen workarounds getting into a mess with directory structures, page layouts and so on.

Most often, a key user requirement of a workaround, not just for published work, is to have control over character fonts and sizes; good typographical practice generally requires variation to be limited here.

I read this thread hoping to find the current best solution for including tables in language teaching handouts for primary school children. Depending on the language, you may need various tables, for example for conjugating verbs. While the kids don't mind, the exercise in PAO, with images, frames and items of text, is exactly the same as for a local history exhibition or a poster at a scientific congress.

My simplest workaround for a small-ish table for school seems to be to make it in Writer, where nice formatting is easier than in Calc. I select the table and export it as PDF, which Scribus can import as vectors; 'Collect for Output' sets up a directory that can be used to keep the files together. Presently, LO seems to forget its export filepaths, but I guess that will be fixed. A limitation is that, as far as I can see, Scribus doesn't fix the aspect ratio of the image by default, and the original dimensions are not given under Properties – if you mess up you have to go back to the PDF.

PastaShock, in response to @a.l.e's proposal to use Tabs, is considering writing code to do that. A big advantage is that the tables are searchable. In fact, that's how LaTeX does it complete with lines, though as usual the code isn't too easy if you don't use it every day. I don't know if it would be possible to convert or port the LaTeX code to Scribus, so we could use the same coding for two applications (like with some equation editors) – perhaps that's what AI is supposed to be good for.

On the subject of AI, LaTeX is half a century old, and built from a huge number of well-documented macros. It's still very powerful, with a huge number of users, and a corresponding (sometimes conflicting) amount of help on the web. Perhaps an AI project might produce a user interface to provide more user-friendly guidance and enable LaTeX to interact better with Scribus.

Finally, Scribus already has a specific render frame for LateX. Render frames can used to code any content, including vectorial graphics from its Tikz ecosystem and nicely typeset extended blocks of text, if they fit on a page. Again, the text is not directly searchable. A local installation is needed. By contrast (to exaggerate a bit), Scribus concentrates more on individual typesetting tools which may require typesetting skills I don't have.  Render frames seem to be underdeveloped, at least with respect to the documentation, which I found hard to follow in the context of the normal LaTeX markup preamble which defines fonts and so on.

It's been noted that Scribus render frames are bitmap images and you have to find out how to adjust the settings. Inkskape makes vectorial render frames, but I don't want to hop between 3 applications...