It looks like there has been a partial regression in LibreOffice 220.127.116.11 when used on MacOSX 10.6.
A previous bug 50284 was closed when all bullet points were displaying correctly when the word doc attachment 60428 [details] and docx attachment 60429 [details] were opened in LibreOffice.
After installing LibreOffice 18.104.22.168 there appears to have been a partial regression in that some of the bullets points are not being displayed correctly.
They should look like attachment 60430 [details] and attachment 60431 [details].
I will attach screenshots of what they look like in LibreOffice 22.214.171.124.
My recollection is that the bullets were displaying correctly when using LibreOffice 4.0.
Created attachment 83098 [details]
Screenshot of incorrect bullet points in doc document.
Created attachment 83099 [details]
Screenshot showing incorrect display os bullets points in docx document
I have checked the documents using libreOffice 126.96.36.199 on Ubuntu 12.04, installed using the libreOffice ppa, and the documents display as expected.
So it looks like an issue on Max OSX only so far.
I believe 4.1 has changed the way it handles fonts, with the ability to embed fonts in documents. Did that change have this side effect?
I can confirm on OS X, it looks as a regression, but might also have other causes. The effect is the same.
I also can confirm the findings of email@example.com.
An excellent description of the problem. Although the link to att 83098 does not work. Att. 83099 gives an example of exactly the problem I get in an own existing document: only the main bullet is not correct.
In the earlier solved bug 50284 also the other bullets were incorrect. So it is not a 100% exact regression, but probably a man like Caolan McNamara (bug killer of bug 50284) could quickly analyze the problem.
I am not a programmer, but when I read the release notes of v 4.1 (https://wiki.documentfoundation.org/ReleaseNotes/4.1)
I come across the following line:
Import and export of graphical bullets of numberings in the DOC, DOCX and RTF filters i#120928 (Jian Hong Cheng - Apache: DOC part, Miklos Vajna: DOCX, RTF parts)
Could this 'improvement / extension' be the cause of the new problem?
I hope this is solved quickly because it is a real drawback for every potential new LibreOffice user coming from MS O.
Created attachment 84817 [details]
fixed in latest build from git
This is fixed (at least for me on OS X 10.8.4) using the latest build from git.
In LO-version 188.8.131.52 for Mac OS X 10.7.5 (up-to-date) this issue is still there.
As stated in the original bugs from which this is a regression: for the 'acceptance' of LO as an alternative for MS Office this is really killing!
A solution for this is far more important than new functionality!!!
(If the basic functionality is not there no one will want to use it).
For the success of LO I hope this get the highest priority.
Adding Caolan to CC
@Caolan : you fixed bug 50284, want to take a look at this one ?
If only to confirm that the fix is in master and will be backported ;-)
In my build from master (02/09/2013), attachment 60429 [details] displays fine.
OSX : 10.8.4
Build ID: d9b62a48d75e596888fcf10f5f73fed93e7b88a3
Confirming defect in
Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903
on OSX 10.8.4
Marking as regression
This should be good in 4.1.2, two problems, lack of registering the "opensymbol" font and a .docx specific issue with the "symbol" font on MacOSX
*** This bug has been marked as a duplicate of bug 68192 ***