Bug 106471 - FILESAVE DOCX: diamond bullet size increased because symbol changed (per comment 5)
Summary: FILESAVE DOCX: diamond bullet size increased because symbol changed (per comm...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
Keywords: filter:doc, filter:docx
Depends on:
Blocks: DOCX-Bullet-Number-Outline-Lists
  Show dependency treegraph
Reported: 2017-03-10 09:17 UTC by Oliver Sander
Modified: 2023-10-08 03:16 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Test file (9.31 KB, application/vnd.oasis.opendocument.text)
2017-03-10 09:17 UTC, Oliver Sander
Test file saved as docx (5.11 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-03-10 09:18 UTC, Oliver Sander
Test compared MSO LO (28.05 KB, image/png)
2019-09-09 14:57 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Sander 2017-03-10 09:17:09 UTC
Given: text document in .odt, with a list with a single item.  The symbol next to that list is a black diamond.  Saving to docx and reopening makes the diamond grow larger.

Steps to Reproduce:
1. save as docx
2. close LO
2. reopen the docx

Actual Results:  
The black diamond is noticeably larger now.

Expected Results:
The black diamond should keep its size.

Reproducible: Always

User Profile Reset: No

Additional Info:
Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f
CPU Threads: 4; OS Version: Linux 4.9; UI Render: default; VCL: gtk2; 
Locale: de-DE (de_DE.UTF-8); Calc: group

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Comment 1 Oliver Sander 2017-03-10 09:17:47 UTC
Created attachment 131787 [details]
Test file
Comment 2 Oliver Sander 2017-03-10 09:18:15 UTC
Created attachment 131788 [details]
Test file saved as docx
Comment 3 Xisco Faulí 2017-03-10 10:05:19 UTC
Reproduced in

Build ID: d3676ceeec55a41337ce5e6bc596f4f100d0638e
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group


Build ID: a2c9d4f8bbde97f175bae4df771273a61251f40
Comment 4 Johnny_M 2017-03-11 13:23:37 UTC
This happens on export to DOC as well. But not on export to RTF.

Build ID: 1:5.2.5~rc1-0ubuntu1~yakkety0
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 5 Patrick Jaap 2017-03-13 14:47:24 UTC
This is not a 'Bug', it's a feature... The diamond symbol (0x800c) is not part of MS Office fonts, and therefore it is replaced by 0xf035. Unfortunately, the size of the replacement is bigger than the original. 

Responsible for the new symbol is the function "bestFitOpenSymbolToMSFont" in the "filter" module (called in doc + docx export). With a deactivated conversion, MS Office renders an error-symbol.

So the options are:
 - should we find a better replacement?
 - should we decrease the font size in this case?
 - should we remove the diamond symbol in the recommended list bullets, since it causes problems?

Comment 6 QA Administrators 2018-06-26 02:43:38 UTC Comment hidden (obsolete)
Comment 7 Patrick Jaap 2018-06-26 09:21:14 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2019-06-27 02:53:13 UTC Comment hidden (obsolete)
Comment 9 Patrick Jaap 2019-06-28 13:13:57 UTC
Unchanged in current master
Comment 10 Timur 2019-09-09 14:57:10 UTC
Created attachment 154058 [details]
Test compared MSO LO
Comment 11 Buovjaga 2020-06-02 14:58:46 UTC
Still repro. Already in 3.3.0

Arch Linux 64-bit
Build ID: bfbf745470cb6f99532523fdeffca061b37d8393
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 31 May 2020
Comment 12 Justin L 2021-04-27 07:15:55 UTC Comment hidden (obsolete)
Comment 13 Telesto 2021-10-07 12:38:21 UTC
(In reply to Justin L from comment #12)
> repro 7.2+ - but also who cares?

I do ;-). At the point it starts affecting how content is split across pages. See bug bug 85964 (more specifically duplicate bug 135610)
Comment 14 QA Administrators 2023-10-08 03:16:06 UTC
Dear Oliver Sander,

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