Bug 127036 - [TABLE] Table properties reset if Document Properties "Only embed fonts that are used in documents" is set
Summary: [TABLE] Table properties reset if Document Properties "Only embed fonts that ...
Status: VERIFIED DUPLICATE of bug 124470
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2019-08-19 20:57 UTC by [REDACTED]
Modified: 2020-10-14 08:30 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description [REDACTED] 2019-08-19 20:57:44 UTC
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:, 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
Comment 1 Mike Kaganski 2019-08-20 12:12:18 UTC
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:
Build ID: 68d3a44bc96041982cb38c140c0f9628dc8547c5
CPU threads: 12; OS: Windows 10.0; UI render: GL; 
Locale: ru-RU (ru_RU); Calc: group threaded
Comment 2 hurukan 2019-10-29 20:03:46 UTC
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 ^^
Comment 3 pier andre 2020-01-24 16:18:12 UTC
confirm that in version 6.3.4 on windows7 the bug exist yet, in linux opensuse Version: 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 :-)
Comment 4 JosifJosif 2020-03-09 15:09:56 UTC
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: (x64)
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win;
Comment 5 JosifJosif 2020-03-09 19:17:23 UTC
(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
Comment 6 berturion 2020-06-04 14:02:15 UTC
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.
Comment 7 MonsieurLune 2020-07-05 06:49:01 UTC
I confirm the issue on LO 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.
Comment 8 Dagaz 2020-07-28 16:10:14 UTC
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.
Comment 9 Mike Kaganski 2020-08-04 14:20:00 UTC
*** Bug 130432 has been marked as a duplicate of this bug. ***
Comment 10 Mike Kaganski 2020-08-04 15:08:36 UTC

*** This bug has been marked as a duplicate of bug 124470 ***
Comment 11 Mike Sapsard 2020-10-14 08:09:12 UTC
This bug is still there in on Linux Mint 20.04.
Comment 12 Mike Kaganski 2020-10-14 08:30:59 UTC
(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.