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: 2021-10-07 12:38 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:

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
repro 7.2+ - but also who cares?
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)