For my documents, I import HTML files (that contain a table), generated outside of LibreOffice.
I am not able to manage table width consistently.
I have tried specifying table width in header/style HTML and in the table element itself (fixed).
But these tables, when imported in Writer, are still too wide for my page size (A4).
More, when I edit the table poperties to specify a fixed size (18cm) in Writer, the fixed width is lost when I reopen the document.
Therefore you are saving as HTML which is not intended for a paper page. I suspect variable table width is expected with html so it can fit screen size and contents size.
You didn’t tell how you “imported” the HTML files. I assume you Inserted>Text from File on the HTML attachments.
When you do so, your tables are indeed too wide because HTML or CSS has configured them so.
Right-click inside the tables and Table Properties. Go to Table tab.
You see that Alignment has been forced to Left with an explicit large Width. Click on Automatic. This disables the explicit width to constrain table within page margin.
File> Save. When you reopen, your table is still within page margins.
Usually when you insert “foreign” text into Writer, double check that “foreign” format is still active (many input filters try to convert “foreign” format to equivalent ODF internal format, eventually disabling expected limits like page width).
As said in the title, I used Insert section, then linked to HTML file.
If I use insert text, the width formatting in LibreOffice is kept after saving.
If I use section, LO width formatting is lost.
I tried with width set in HTML (at table and cell level) and with width not set at all in HTML. Same problem : LO formatting is lost.
I need to use section as I want to keep a link with HTML files that are externally produced and are regurlarly updated.
If at least I could set the width in LO and that is kept, I could live with that.
Regarding your sentence : double check that “foreign” format is still active (many input filters try to convert “foreign” format to equivalent ODF internal format, eventually disabling expected limits like page width).
Use the Style Inspector. If you see a lot of direct formatting, this is a sign that “foreign” format has been tentatively translated in some more or less equivalent form (the primitive does not exist in Writer or the converter could not guess the intent). Note that direct formatting already present in source material will make things even more difficult.
I had a look at your HTML files. They exhibit extensive “direct format”: instead of simply referencing a “style” (in Writer meaning) through class= attribute, formatting is repeated on every cell with style=.
You should try to consolidate your source with a more strict, methodical and organised formatting (if this is possible – if it is generated by computer inside a framework, probably no luck).
I experimented with your HTML in a blank document. Many strange things happen when section contents is linked to your files.
page style is switched to HTML
tables are aligned Left (instead of default Automatic) and their computed width (from CSS width in cells) is stored in Width
When total width is larger than available text are width in the page, Right spacing is adjusted so that table is not truncated to page width.
Now what are the differences between your two HTML files? Contents! Their CSS are identical. Tables are the same width, 840 px, but the “Request” one is displayed within margins while the “Response” overflows.
Looking more carefully at contents, I see that “Response” cells have short text. Then there is ample space to shrink the columns to page width.
This cannot be done in “Response” because you have a “super wide” item RepeatedSend…readerReponse" which is a single word and prevents any space reclaim.
It also appears that the way HTML is encoded leaves no initiative to Writer: line wraps are already imposed with <br/> interspersed everywhere. By the way, <br/> is XHTML, not HTML. The difference is probably irrelevant in your application but I know programs which are very picky about it.
@sokol92 has suggested a fix for your “Request”. I think a better generic fix is to systematically change Alignment property of all tables to Automatic. It won’t solve all issues but takes care of most of them.
What is not solved is the case of very long “words” which are then split at arbitrary positions. Note also that in the “Response” table, the “shrinking algorithm” reduces column widths to heading plus some lateral spacing. Unfortunately, this line-wraps the Mult interval descriptors on two lines, frequently with only the right bracket orphaned on the second line.
Enabling hyphenation in Table Contents paragraph style does not improve the situation
