Bug 157890 - LibreOffice conversion from ODT to DOCX - fontsize is wrong after conversion for empty lines
Summary: LibreOffice conversion from ODT to DOCX - fontsize is wrong after conversion ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.5.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Size
  Show dependency treegraph
 
Reported: 2023-10-23 00:23 UTC by indra.kusumo
Modified: 2025-12-09 03:12 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
font_size is not honor if text is empty when converting from odt to docx (326.35 KB, image/png)
2023-10-23 00:26 UTC, indra.kusumo
Details
Sample to test the issue (16.99 KB, application/vnd.oasis.opendocument.text)
2023-10-25 04:02 UTC, nhatthinh.phan
Details
Sample to test the issue (19.57 KB, application/vnd.oasis.opendocument.text)
2023-10-25 04:27 UTC, nhatthinh.phan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description indra.kusumo 2023-10-23 00:23:30 UTC
Description:
if controlling space in document done using fontsize when converting from odt to docx ( ms 2007 365 docx ) format the fontsize is not being honor.


Steps to Reproduce:
1. create libreoffice odt, the following example :
example text1 (set font = Arial font_size = 11 )
[empty line set font = Arial font_size = 5]
example text2 (set font = Arial font_size = 11 )

2. open the odt file with libreoffice version 7.5.4.2 and select save as word 2007_365_docx format 

3. the output is :
example text1 (set font = Arial font_size = 11 )
[empty line set font = Arial font_size = 11] 
example text2 (set font = Arial font_size = 11 )

Noted : 
- the 2nd line which is the empty line should be font_size 5 instead of font_size 11.
- in the case we have multiple of this empty line to control document formatting,
it might not pick the parent font_size it might pick the previous correct font_size.

Actual Results:
example text1 (set font = Arial font_size = 11 )
[empty line set font = Arial font_size = 11] 
example text2 (set font = Arial font_size = 11 )

Expected Results:
example text1 (set font = Arial font_size = 11 )
[empty line set font = Arial font_size = 5] 
example text2 (set font = Arial font_size = 11 )


Reproducible: Always


User Profile Reset: No

Additional Info:
This scenario is not an issue if the 2nd line has text ie sampe_between_text1_text2,
only an issue if they are empty. we used the empty line with smaller size to control the line height.

1. create libreoffice odt, the following example :
example text1 (set font = Arial font_size = 11 )
sampe_between_text1_text2 [set font = Arial font_size = 5]
example text2 (set font = Arial font_size = 11 )

2. open the odt file with libreoffice version 7.5.4.2 and select save as word 2007_365_docx format 

3. the output is :
example text1 (set font = Arial font_size = 11 )
sampe_between_text1_text2 [set font = Arial font_size = 5]
example text2 (set font = Arial font_size = 11 )
Comment 1 indra.kusumo 2023-10-23 00:26:48 UTC
Created attachment 190378 [details]
font_size is not honor if text is empty when converting from odt to docx
Comment 2 indra.kusumo 2023-10-23 01:46:02 UTC
started have issue in libre 7.5.4.2 and greater.
Comment 3 BogdanB 2023-10-25 02:50:34 UTC
Please attach a demo document in order to test this bug.
Comment 4 nhatthinh.phan 2023-10-25 04:02:14 UTC
Created attachment 190402 [details]
Sample to test the issue
Comment 5 nhatthinh.phan 2023-10-25 04:27:06 UTC
Created attachment 190403 [details]
Sample to test the issue

Open this file by LibreOffice Calc with the version from 7.5.4.2 and greater.
Then save it in *.docx
Close all the document and then open the docx file to see the difference to.
Please select View > Formatting Marks (Ctrl + F10) to check the difference easily.
Thanks.
Comment 6 nhatthinh.phan 2023-10-25 04:28:39 UTC
I am sorry open the attachment by LibreOffice Writer
Comment 7 BogdanB 2023-10-25 04:31:49 UTC
Confirm this bug with
Version: 7.6.0.3 (X86_64) / LibreOffice Community
Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: ro-RO (en_US); UI: en-US
Calc: threaded

Steps to reproduce:
- Open the file from comment 5. Lines 2-5 are 6pt.
- Save as Word 2010-365 and File-Reload. Lines 2-5 are 11pt.
Comment 8 BogdanB 2023-10-25 16:41:14 UTC
Repro also with
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 25286bc04142741b7731dae50891c1dde47b78c4
CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 9 BogdanB 2023-10-25 16:53:40 UTC
Mike, can you take a look?

author	Mike Kaganski <mike.kaganski@collabora.com>	2023-05-10 20:39:12 +0300
committer	Mike Kaganski <mike.kaganski@collabora.com>	2023-05-12 08:50:02 +0200
commit c2cfeed369a2b0f6d91d1093d3876357277411c9 (patch)
tree 2f56b19c7b38d3aeb4dd38eeeecea388723273c9
parent b69db38a38b09e158e8d46d8b717db85860ca874 (diff)
tdf#155238: Reimplement how ListAutoFormat is stored to ODF
This reimplements commits 6249858a8972aef077e0249bd93cfe8f01bce4d6
(sw: ODT import/export of DOCX's paragraph marker formatting,
2022-12-19) and 209dce614c43f63f63f5b42a746665c0ec1cbfe3 (sw: fix
ODT import of paragraph marker formatting, 2022-12-20).

Instead of using an empty trailing span for the ListAutoFormat data,
introduce a new loext:marker-style-name attribute for text:p element,
referencing a text autostyle.

The problems with the previous implementation were that (1) it was
impossible (or very difficult) to disambiguate several empty trailing
spans, in case it was needed; and (2) this was incompatible change,
with other ODF implementations treating the trailing span normally.

I couldn't manage to incorporate the attribute to paragraph autostyle,
because of problems referencing different autostyles one from another,
so put it directly to the paragraph attributes.

Change-Id: I33473147f1f774c24cbbc57bf0c4f3a1d83ce5bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151645
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151681
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Comment 10 BogdanB 2023-10-25 16:55:05 UTC
 5e68c7b10ef216b605a25fed2e0a29bc417b9bc8 is the first bad commit
commit 5e68c7b10ef216b605a25fed2e0a29bc417b9bc8
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Fri May 12 08:59:49 2023 +0200

    source c2cfeed369a2b0f6d91d1093d3876357277411c9
    
    source c2cfeed369a2b0f6d91d1093d3876357277411c9

 instdir/program/libdbalo.so       | Bin 3997816 -> 3997816 bytes
 instdir/program/libdbaxmllo.so    | Bin 461960 -> 461960 bytes
 instdir/program/libeditenglo.so   | Bin 3269016 -> 3269016 bytes
 instdir/program/liblnglo.so       | Bin 1066520 -> 1066520 bytes
 instdir/program/librptxmllo.so    | Bin 548400 -> 548400 bytes
 instdir/program/libsclo.so        | Bin 22003488 -> 22003488 bytes
 instdir/program/libsmlo.so        | Bin 2292360 -> 2292360 bytes
 instdir/program/libsvgfilterlo.so | Bin 967392 -> 967392 bytes
 instdir/program/libsvxcorelo.so   | Bin 12178008 -> 12178008 bytes
 instdir/program/libswlo.so        | Bin 23390688 -> 23390464 bytes
 instdir/program/libxoflo.so       | Bin 431816 -> 431816 bytes
 instdir/program/libxolo.so        | Bin 6304112 -> 6304304 bytes
 instdir/program/setuprc           |   2 +-
 instdir/program/versionrc         |   2 +-
 14 files changed, 2 insertions(+), 2 deletions(-)
Comment 11 Mike Kaganski 2023-10-31 13:59:39 UTC
Two issues here.
1. No UI for managing "ListAutoFormat" (i.e., what in Word represents a paragraph marker): once applied (e.g. on import), it sticks to a paragraph, and can't be changed / removed, other than clearing direct formatting (Ctrl+M);
2. Different handling of "empty line (or only spaces) + paragraph marker" in Writer (with IgnoreTabsAndBlanksForLineCalculation set, as in attachment 190403 [details]). Word then takes height of marker as the line height. This is related to bug 153128.
Comment 12 QA Administrators 2025-12-09 03:12:17 UTC
Dear indra.kusumo,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug