Created attachment 61850 [details]
zip file contains a screenshot from MSO2010, a screen shot from LibO354rc1, and part of the document in question. I could not include the entire original document due to its content, I hope the document is testable.
Problem description: Reported by one of our users yesterday on 3.5.3 - I verified on Windows XP/LibO 3.5.3, Windows 7/LibO 3.5.3, and both 3.5.3 and later 3.5.4rc1 on my Mac OS X intel 10.6.8. All US English.
User received multiple contracts (in .doc format) via email that contain multiple numbering levels and bullet levels. The document import starts out fine properly formatting items 1.1 thru 3.4 as Times new Roman and as a numbered list. For some reason, numbered items 4.1, 4.2, 4.3 and 4.4 actually show up as symbols instead of "4.1" etc. When you click on the symbols, you see that they are being interpreted as a numbered list, but that the font is interpreted Wingding instead of Times New Roman.
After seeing this, I checked the bug list and found a similar bug (34814) was patched in 3.5.4rc1, so I tested it in 3.5.4rc1, but my document still imported incompletely.
I can apply a font substitution rule for Wingdings to Symbol and the document is readable - BUT that is not a fix because it is still interpreted as Wingdings. So if the document is modified, saved and emailed back, the user on the other end now sees wingding symbols.
FYI, I opened this on a VM running MSO2010 and noticed that it has its own font substitution issues in the document. Trying to find some reason or pattern that might cause the font issue, I noticed in MSO that the numbering for 3.1, 3.2, 3.3, and 3.4 are in Garamond and the item text is in Times new Roman. On 4.1 the numbering and the item text is in Times new Roman, on 4.2 and 4.3 the numbering is in TNR and the item text is in Garamond. It seems that the document switches from TNR and Garamond throughout the document and LibO picks up all of the font changes EXCEPT for the numbering.
Another example in the document is in section 10.2 - the subpoints are supposed to be numbered as (a), (b), (c), etc. It is all Times New Roman as well, but imports as Wingdings
Steps to reproduce:
1. Open imported document
2. Check on numbered lists buy clicking on them to test font substitution
Current behavior: Numbered lists do not format correctly throughout entire document - turn into symbols
Platform (if different from the browser):
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5
REPRODUCIBLE on MacOS X 10.6.8 German (Intel) with:
* LibreOffice 3.4.6 (OOO340m1, Build:602), German Langpack installed.
* LibreOffice 184.108.40.206 (Build-ID: 7306755-f4f605c-738527d-1cf4bc1-9930dc8), German Langpack installed.
* LOdev version 3.6.0alpha0+ (Build ID: f8e94ec; installation file: master~2012-05-21_00.57.17_LibO-Dev_3.6.0alpha0_MacOS_x86_install_en-US.dmg), US English langpack installed.
The numbers of the numbered lists in Article IV and in section 10.2 appear in Windings. You may look first at section 10.2, because this section is easier to recognize as a numbered list. I will attach a screenshot showing this section in LibreOffice 220.127.116.11 (!).
-- I have set the 'Version' field to 3.4.6, because the bug is already present in this version. It is probably much older ...
-- I have changed the 'Summary' field a bit, to make it easier to find this issue (for bullet lists, we have already bug 34814, so IMHO this report should focus on numbered lists).
It is possible that this bug was fixed in LibO 3.5.4 for Windows and Linux (?) -- 'digital ant' and me have tested 3.5.4 on MacOS X only --, but it is still present in LibO 3.5.4 for MacOS X and in the current Master for MacOS X. Could someone else please test this issue on Windows and Linux to verify if this idea is true? If it is true, i.e. if the bug is fixed in LibO 3.5.4 for Windows and Linux, then please change the Platform field to 'MacOS'.
Created attachment 62021 [details]
Screenshot showing the corrupted numbered list from section 10.2 in LibO 18.104.22.168 on MacOS X
This issue could be related to bug 50284, which states that bullet lists, which are now imported correctly from .doc/.docx files on Windows (see bug 34814), are still not imported correctly on MacOS X.
I have an update to possibly narrow the cause: I opened the original doc in Word 2010, selected all text and set it all to Times New Roman. Saved the file. Then opened it in 3.5.4rc1 with no numbering issues - same result in 3.5.3 as well (Win and Mac - US English). It would seem that the massive font switching in the original doc was the culprit.
The problem still exists in LO 4.1 beta 1 on Linux 64bit.
** Please read this message in its entirety before responding **
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 on a currently supported version of LibreOffice (22.214.171.124 or later): https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
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)
Thank you for your help!
-- The LibreOffice QA Team
This NEW Message was generated on: 2015-03-03
Problem is gone now -> WFM.
Win 7 Pro 64-bit, LibO Version: 126.96.36.199
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432