Maximum number of columns in Writer table?

LO 7.2.5.2 (x64); Windows 10

I’m using Writer to create a table with many rows and many columns. Can’t use Calc because I need to embed images within some cells and that’s apparently not available currently in Calc (please enlighten me, if this is incorrect). I use a user-specified page size of 200cm x 50cm; not printable but it suits my needs.

I’m running into the inability to resize columns past 33. That is, I can resize columns 1 to 33, but not those beyond. Strangely, though, I can resize the entire table, and add new columns to the rightmost. And I can make the page even wider. But columns 34 and on do not resize, in any mode (automatic, left, etc.), neither via the table dialog nor the context menu (RClick > Size > Column Width…)

I suspect something’s up because I cannot see the column separator marker when I click on a separator beyond column 33, as if it’s just not allowed to move.

So, is there a limit for the number of columns in a Writer table? Or perhaps I’m bumping up against some other constraint.

Thanks for your help!

Can’t use Calc because I need to embed images…

It is possible to insert images into Calc and especially into table cells.

So, is there a limit for the number of columns in a Writer table?

I don’t know if anyone has tested it yet.


Please explain exactly what you plan to do with the table besides inserting images.
A better answer is quite possible if we know what exactly you want to do.

IMHO it is not a good idea to use such a big (Writer-) table in Writer.


And you can use Calc tables in Writer as well.

Creating a table in Writer

@Hrbrgr Thanks for your reply. Has Calc changed recently to work more easily with embedded images? Last time I tried, I had many problems with images not “sticking” to cells (even with Anchor to Cell) and generally behaving very oddly, so I gave up and settled on Writer tables instead. I especially like that I can sort tables both vertically and horizontally (i.e., rows AND columns).

As for Calc, I’ve just tried again, and lo and behold images now behave better. But there are still issues…

I’m building a matrix of LEGO Wheels (rows) and Tires (columns), in many-to-many relationships, with several properties for each (e.g., height, width, P/N, sets belonging to, superseded by, etc.)

Ideally, I would rather design a proper database, with an appropriate data model, and query to my heart’s content, BUT I wanted to just knock something off quickly for limited use. I didn’t have time for a lot of legwork, modeling, implementing, importing images, etc.

I’ve mocked up a simpler data set with Calc, but I haven’t found a way to sort columns based on a criteria in one or more rows (as opposed to the typical sorting rows based on a criteria in one or more columns).

For example, one row contains the Height as follows (in separate cells): 81.6, 14, 30.4, 62.4, 75, 43.2
I want to move columns according to these values.
Workaround so far is to move columns manually. Not ideal.

I agree that it’s not the best use of Writer tables, but it seemed to work quite well until I hit that wall.
Calc is probably not the best candidate either. As I mentioned, I’d prefer a database, and it will probably come to that.

As always with complex design, don’t rely on GUI editing. This is always inaccurate and rarely gives the intended result due to the quantised movement of the mouse.

I have no difficulty to resize any column after a right-click on the table and Table Properties. Go to the Columns tab and scroll the column numbers. You can also put the cursor in the column and Table>Size>Column Width

BEWARE! When you adjust a width, it is borrowed from the next column which is reduced/expanded accordingly. And you can’t reduce next column below 0.04cm, which could necessitate an iterative adjustment to get your desired layout.

Nota: I made my test on a standard A4 portrait page with 2cm margins. The 50 columns were very narrow. As a consequence of the aforementioned quantisation, I had no adjustment cursor. Only the menu/dialog worked. If this didn’t work for you, something else is at stake. My LO version is 7.2.5.2.0+ under Fedora 35.

Right, I had no problem getting exact column widths with either specific manual entry or dragging the column separators. That is, for the columns that did respond.

I didn’t notice the issue until I had 38 columns. It seems that the last column to respond to resize is 33. Perhaps if you tried with a paper width of 150cm and a table with as many columns you might see the issue as well.