Problems with tables as images

Previous topic - Next topic

Farland

Okay so I see people on here saying that you shouldn't use tables in Scribus, because they aren't really ready for prime time. And indeed I have had tables crash Scribus multiple times. But here's the problem I'm up against. I can do tables at 300 dpi using MS Word, which I then export to a pdf, open in PS, save as a tiff, and insert as an image. That works fine, except I want to create the same document for print with all the images at 300 dpi and then also for digital, with the images capped at a lower resolution. You see the problem, I'm guessing: the text in tables in the digital file doesn't look great, because the tables are being downgraded in resolution. Any idea what I could do to address this problem?

GarryP

Why are you converting the PDF to a TIFF before putting it into an image frame?
Are you having problems when inserting the PDF itself into an image frame?
The preview you see on-screen isn't high resolution but the output from Scribus should be fine.

a.l.e

Here my "best choice", between the multiple ways one has for getting a table into Scribus:

https://webmshare.com/jq8dL

- create the table in Office
- export it to PDF
- open the PDF with Inkscape
- (shrink it from document to "table" size)
- export it to (plain) SVG
- import the SVG in Scribus
- (ungroup the SVG until it's not possible anymore and regroup it to (partially) avoid artifacts)
- place the table as a vector (text will not be editable) in your document.

With Scribus 1.5 you can try to directly load the PDF as a vector.

Farland

#3
Thank you both.

Gary, I hadn't tried importing the PDF straight. Would that help my issue or do you mean just in terms of a faster workflow?  I'm aware Scribus shows a lower res preview to keep the app functioning quickly. What I mean is the tables won't look good for screen when I export the final PDF with the images lower than 300 dpi.

a.l.e.: I'm using 1.5.3. If I import the svg file as a vector (how do I import it, btw? do I use the image frame to do that?) will it maintain resolution when I lower the res if all the other image files upon export? If so that would work for me if Scribus can handle it.

GarryP

If Office exports the tables as vectors (and fonts?*), and Scribus treats the vectors (and fonts*) in the "imported" PDF properly, there should be no issues with resolution when you export your document.
Vectors and fonts are resolution-independent so they should look right at any scale.
I've not done extensive testing but it's worked fine for me the few times I've used it in 1.4.6.
The best thing to do is try a few tests for yourself and see what happens.

* I don't know how Scribus handles fonts in an "imported" PDF so I don't know if it outlines them or not but as long as they're handled in a "vector-based manner" it should be fine.

Farland

#5
Alright, excellent.  I did a little bit of reading and testing just now, and it looks like I can import the PDF in Inkscape, save it as an SVG file (with the option of outlining fonts), import it in Scribus using Import>Get Vector File and it looks great.  Now my question is will handling a large amount of svg tables bog down Scribus? It seems to increase the size of the .sla file by a good amount (in the case of my imported test file, 1 MB) per imported vector? If I use this method, I need to import a rather large amount of tables as vectors.

GarryP

You should be able to import the table PDF directly into a Scribus image frame without converting it to a SVG in Inkscape.
I'm not sure what benefit you would get from the conversion - in the case you describe - except that you can more easily see what it looks like in Scribus before you export your document.

When you convert fonts to vectors you lose the "compression" that the font gives you. After conversion, every character is represented by a long string of coordinates (and other things) that describe the shape of that character rather than just a look-up from a character value to the vector tables in the font file. For example, every single "9" will be a long string of vector description and this long string will be repeated everywhere you have a "9". The same goes for every character. So, if you have lots of tables, you will have lots of repeated strings of vector descriptions and this will take up more memory.

Farland

#7
Okay, on testing, you make a good point-- importing the pdf as a vector file directly into Scribus does seem to eliminate the need to save it as an svg file.  That's great.  The pdf directly imported seems to increase the .sla file size by about 200 KB over the svg file, though.

So now my question is: is a quite large .sla file (ie one filled with vector tables) going to make it difficult to work in Scribus? Do you think it will bog down or crash Scribus? My laptop is decently powered.

Farland

Update: okay I went the Import pdf as vector route and it seems to be working out beautifully. It has definitely increased the size of the .sla file but Scribus seems to be handling it just fine. I'm thinking it will actually decrease the size of the final exported pdf while making it better quality. Thanks for all your help, guys!

Farland

Next update: I may have spoken too soon.  There was no problem working with the vector tables inside Scribus, but the exported PDF now seems unworkable.  It takes forever to open, it takes a long time to move from page to page, and it takes upwards of an hour to save. Is there anyway to save this? It turns out creating all tables as vector images may not have worked in the end.

GarryP

You could put your tables on a separate layer and temporarily switch that layer off to try and get some document-browsing speed back but that's not an ideal solution even if it works, and it doesn't help with save/load times.

You could try splitting the document into smaller "sub-documents" but that's not ideal either.

Another option would be to use LaTeX in a render frame but I'm fairly sure that just creates bitmaps anyway.

If importing the tables as vectors makes the document too large then you'll probably have to go back to using bitmaps and not capping the resolution for the non-print version.

If your tables are black and white then you could try converting the bitmaps to 1-bit indexed mode (in GIMP, menu Image -> Mode -> Indexed / 1-bit). Export them as TIFs (with LZW compression) and the file sizes should drop to about 10% of the originals. GIMP or ImageMagick might be able to process multiple images in batch mode but remember to not overwrite the originals.

I haven't tried using 1-bit images in Scribus, so you will have to do some testing before using it in a real document.

I'm not sure what else to suggest.

Farland

Alright, thanks for the advice.  It honestly seems like the best solution would be to build the tables right in Scribus. Is the table functionality really that bad?

GarryP

"Bad" really depends on what you want.
If you want something very simple then it's quite usable, but as soon as you want any complexity you might start to have trouble.
Tables are just grouped cells with a little bit of extra functionality thrown in.

Can you give visual examples of some tables you want to create, with some notes on how things need to be formatted? Also, how many tables - of each kind - do you need to create?
It's always easier to give advice when you can see what you're advising on.

You might need to use a mix of native tables and imported ones.

Farland

The tables I am trying to make are actually rather simple. I just have a LOT of them to make. 

One example would be something like the "Draconic Ancestry Table" on this page: https://www.5esrd.com/races/dragonborn/

Or like the tables on this page: http://www.5esrd.com/backgrounds/

a.l.e

with a bit of creativity, you can also use tabulators for that...

https://www.youtube.com/watch?v=V8LHozLpWa8&t=4s