Description: Setting of Document Properties "Only embed fonts that are used in documents" (File -> Properties -> Tab: Font -> Cat: Font embedding -> Option: Only embed fonts that are used in documents) affects table properties of tables inserted into a Writer document. Steps to Reproduce: 1. Open a new Writer document 2. Insert a table (more than one colums) 3. Set Aligment to "Left" ( or "Center") on Table Properties 4. Set Column Width to any uneven distribution (e.g 1=2.00 cm, 2=8.00 cm, 3=6.00cm) 5. Set File -> Properties -> Tab: Font -> Cat: Font embedding -> Option: Only embed fonts that are used in documents 6. Save the file 7. Open or Reload the file Actual Results: Table properties are reset to "Automatic" alignment and Column Widths are are evenly distributed (any borders are removed) Expected Results: Setting in Document Properties "Only embed fonts that are used in documents" should *not* affect any table properties. Especially any setting made to "Alignment" / "Column Widths" / "Borders" should be preserved. Reproducible: Always User Profile Reset: Yes Additional Info: See also question at https://ask.libreoffice.org/en/question/205348/table-column-width-changes-after-saving-closing/?comment=205416#post-id-205416 Reporters configuration: Version: 6.3.0.4, Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde5; Locale: de-DE (en_US.UTF-8); UI-Language: en-US, Calc: threaded
The problem is in XMLFontAutoStylePool::exportXML, which calls XMLFontAutoStylePool::getUsedFontList. The latter in turn calls SwXMLExport::collectAutoStyles, and that one indirectly writes the autostyle entries. It is used in SwXMLExport::ExportAutoStyles_ called from SvXMLExport::ImplExportAutoStyles, and there it is wrapped into XML_AUTOMATIC_STYLES element. The resulting XML structure in content.xml is > <office:document-content ...> > ... > <office:font-face-decls> > <style:style style:name="Table1" style:family="table"> > <style:table-properties style:width="17.013cm" fo:margin-left="0cm" table:align="left"/> > </style:style> > <style:style style:name="Table1.A" style:family="table-column"> > <style:table-column-properties style:column-width="1.508cm"/> > </style:style> > ... > <style:font-face style:name="Arial1" svg:font-family="Arial" style:font-family-generic="swiss"/> > ... > </office:font-face-decls> > <office:automatic-styles/> > ... where automatic styles, including those with table properties, are inside office:font-face-decls element, and the office:automatic-styles element is empty. Adding Tomaž Vajngerl, the author of https://git.libreoffice.org/core/+/1a8435a23e84f3ceeee580eb9d4404a738d98888. Tomaž, the problem existed before the said patch (didn't try to check if that's a regression, or had it existed from the start of introducing the setting), but you are the expert here; do you have an idea how to fix this? Note that this problem occurs even when fonts aren't embedded at all (i.e., the top setting "Embed fonts in the document" in the dialog is unchecked) - so there's also likely performance problem, that some code unnecessarily runs when not needed. Already reproducible with Version: 6.2.0.0.alpha0+ Build ID: 68d3a44bc96041982cb38c140c0f9628dc8547c5 CPU threads: 12; OS: Windows 10.0; UI render: GL; Locale: ru-RU (ru_RU); Calc: group threaded
Version: 6.2.7.1 Build ID: 20(Build:1) CPU threads: 8; OS: Linux 4.12; UI render: GL; VCL: kde5; Locale: fr-FR (en_US.UTF-8); UI-Language: en-US Calc: threaded I can confirm I could reproduce the issue. If the check box is set for the "only embed..." option there is no way to change the table aspect. Workaround: uncheck it ^^
confirm that in version 6.3.4 on windows7 the bug exist yet, in linux opensuse Version: 6.4.0.1 it's not possible to check "only embed..." becouse on the reopen isn't conserved the checked status. confirm the workaround works (uncheck "only embed...") if you check instead "Embed fonts in the document" everything works fine but the files are the double in Mb. please solve this bug :-)
I also have problems with tables. I can for example successively set for good the overall looks of the table under the Table Properties > Borders > Style but whatever I choose and set at Table Properties > Borders > Width gets enacted but not remembered between closing and re-opening of LibreOffice Writer And that was happening before I started to check out options available at File -> Properties -> Font [it does not matter what I choose or deselect there] Version: 6.2.5.2 (x64) Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win;
(In reply to JosifJosif from comment #4) > I also have problems with tables. Although my files are mostly some old DOCX, probably every one of them created by the means of coping on the drive some other DOCX file So I tried out this: 1] selected all 2] copied the content 3] created a new file 4] pasted all 5] saved the file as ODT And now I am finally able to have my tables with the Style of Borders permanently with the same setting. In other words: the old malfunctioning table was pasted to a new ODT file and now it works as it should
Hi. I also had this issue. It drived me crazy before I found this bug. I unchecked all "embed fonts" paramaters and now my tables keep their size in my CV. Please fix this bug it is very annoying, I lost 3 hours finding the cause of this bad column sizing.
I confirm the issue on LO 6.4.4.2 x64 (both Windows and Linux). It's extremely annoying, especially when you need to share documents with complicated design and special fonts (especially in when working in research and you need collaborative work, so no PDF use). Please find a decent solution for this bug.
I can verify the bug, too. And I really hope it would be fixed, soon. Also I wonder why the bug classification is low. The loss of all table format data is in the end a loss of data. (Which costs me several hours today and yesterday.) I always assumed that bugs which cause a loss of data would have a higher priority.
*** Bug 130432 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 124470 ***
This bug is still there in 7.0.0.3 on Linux Mint 20.04.
(In reply to Mike Sapsard from comment #11) Of course. If you look at the main bug 124470, which this bug is duplicate of, you will see that the fix for branch 7.0 is in version 7.0.1.