Bug 34814 - FILESAVE(?) FILEOPEN Bullet lists in file saved as .doc or .docx are loaded incorrectly
Summary: FILESAVE(?) FILEOPEN Bullet lists in file saved as .doc or .docx are loaded ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: All All
: medium normal
Assignee: Luboš Luňák
URL:
Whiteboard: target:3.6.0 target:3.5.4
Keywords:
: 35065 35851 43866 45416 46974 (view as bug list)
Depends on:
Blocks: Bullet-Number-Outline-Lists DOCX mab3.5
  Show dependency treegraph
 
Reported: 2011-02-27 22:33 UTC by gt6
Modified: 2017-05-10 23:07 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
Original formatting (47.21 KB, image/png)
2011-02-27 22:33 UTC, gt6
Details
Reopened .doc file in libreoffice (47.00 KB, image/png)
2011-02-27 22:34 UTC, gt6
Details
Reopened .docx in libreoffice (58.90 KB, image/png)
2011-02-27 22:34 UTC, gt6
Details
Original .odt file, correct formatting (15.10 KB, application/vnd.oasis.opendocument.text)
2011-02-27 22:39 UTC, gt6
Details
Saved .docx file, square bullet points showing (4.92 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2011-02-27 22:40 UTC, gt6
Details
sw patch (688 bytes, patch)
2011-03-03 04:14 UTC, Luboš Luňák
Details
writerfilter patch (4.38 KB, patch)
2011-03-03 04:16 UTC, Luboš Luňák
Details
Bullets opened in .docx (113.59 KB, image/png)
2011-04-03 19:14 UTC, Zack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gt6 2011-02-27 22:33:29 UTC
Created attachment 43910 [details]
Original formatting

1) Make a new empty document in libreoffice
2) Add a line of text, make it a bullet list by pressing the bullet list button
3) Add some more bullets, maybe indent some of the bullets
4) Save as .doc or .docx
5) Close document
6) Open same document again in libreoffice
7) Bullets are now either moved about (if from .doc) or they show up as squares (if from .docx)

See attached screenshots, first is the original document, second is the reopened .doc, third is the reopened .docx.
Comment 1 gt6 2011-02-27 22:34:03 UTC
Created attachment 43911 [details]
Reopened .doc file in libreoffice
Comment 2 gt6 2011-02-27 22:34:33 UTC
Created attachment 43912 [details]
Reopened .docx in libreoffice
Comment 3 gt6 2011-02-27 22:39:39 UTC
Created attachment 43913 [details]
Original .odt file, correct formatting
Comment 4 gt6 2011-02-27 22:40:10 UTC
Created attachment 43914 [details]
Saved .docx file, square bullet points showing
Comment 5 gt6 2011-02-27 22:41:32 UTC
Actually, I revise my report on .doc files, the problem was that I saved as .doc 95 instead of 97/2000/XP.

The .docx bug however remains.
Comment 6 Cédric Bosdonnat 2011-02-28 01:44:07 UTC
Lubos, could you have a look at this issue?
Comment 7 Luboš Luňák 2011-02-28 09:34:56 UTC
Strange. Export appears to be correct, since msof can open the file correctly afterwards. In fact even import seems to be correct, as such, since msof can open the file correctly even after a roundtrip. Somehow just the internal structures are not set up correctly for showing up in the editor.
Comment 8 Luboš Luňák 2011-03-01 08:12:11 UTC
Ok, the trouble is with fonts. Those marks use a special font, which seems to be 'Wingdings' or 'Wingdings 2', even on Linux, where there is no such font (and these fonts are written in w:rFonts, but not in fontTable.xml). While reading the data the code doesn't seem to know anything about these fonts (even if fontTable.xml contains them because being written by msof) and uses wrong charset, resulting in the incorrect display. Manually hacking the two SetBulletFont calls in UNO in SW to explictly set the right charset works around the issue.
Comment 9 Luboš Luňák 2011-03-03 04:14:59 UTC
Created attachment 44069 [details]
sw patch

This one should fix the font not being listed in fontTable.xml (which I assume is needed for any font that is used by the document).
Comment 10 Luboš Luňák 2011-03-03 04:16:20 UTC
Created attachment 44070 [details]
writerfilter patch

This I think should implement reading w:charset, both the ECMA and ISO ways. But the read value doesn't seem to be used later.
Comment 11 Vossman 2011-03-31 06:13:10 UTC
Confirmed still a problem in LO 3.3.3, I assume these patches will be applied to 3.4? Is bug now closed? I am going to propose it as a 3.4 most annoying bug.
Comment 12 Luboš Luňák 2011-04-01 04:59:14 UTC
As comment #10 says, the fix is incomplete.
Comment 13 Zack 2011-04-03 19:09:57 UTC
(In reply to comment #5)
> Actually, I revise my report on .doc files, the problem was that I saved as
> .doc 95 instead of 97/2000/XP.
> 
> The .docx bug however remains.

Saving as a 97/2000/XP .doc file produces the exact same results as saving as a .docx file for me.
Comment 14 Zack 2011-04-03 19:14:45 UTC
Created attachment 45206 [details]
Bullets opened in .docx

Actually, the bullets look different for me than they do for the OP.  I'll attach a screenshot of what mine look like.  I opened the .docx that was attached here, but whether the file is a .docx or a .doc the bullets look the exact same for me.
Comment 15 Zack 2011-04-03 19:16:52 UTC
*** Bug 35851 has been marked as a duplicate of this bug. ***
Comment 16 Vossman 2011-07-19 18:04:57 UTC
is anyone working on this, changing from ASSIGNED to NEW
Comment 17 Cor Nouws 2011-07-25 15:22:21 UTC
*** Bug 35065 has been marked as a duplicate of this bug. ***
Comment 18 sergey 2011-07-26 22:06:11 UTC
Bug and workaround (see 35065) are the same for 3.4.2 RC2/Windows OOO340m1 (Build:202)
Comment 19 sergey 2011-09-01 22:12:20 UTC
I am unable to reproduce this bug in fresh install of Windows XP corportate, with and without russian MUI installed and russian locale selected.

And LO 3.4.3 on old machines seems to still have it.
May be there is some concerns with previous installation of Microsoft Office?
Comment 20 sergey 2011-09-01 23:00:43 UTC
more about russian and english versions of windows.
The same file looks different!
Bullet looks as disk in EN version but as mercedes sign in RU version.
And, if go to settings and manually choose U+2022 when formatting the list, bullet symbol is shown correctly in both version.
But if not do it, the symbol is U+F0F1 (some character from unicode "private use area") - it can be seen in properties or in binary comparation of good and bad files. It seems that main concern is about this U+F0F1 character, which looks differently in different OSes. Main question: why is it used and how to force U+2022 by default instead?
Comment 21 Shaun Crampton 2011-10-02 18:53:16 UTC
I'm seeing this bug in version 3.3.3 OOO330m19 (build 301) (Ubuntu).  I save as .doc 97/XP and then reopen in either LO (same machine) or Word (on a Mac) and see the Mercedes symbol.  The Ubuntu machine is in the UK locale.  Font is arial.
Comment 22 Shaun Crampton 2011-10-02 18:59:37 UTC
PS. By UK, I mean United Kingdom (enGB).

(In reply to comment #21)
> I'm seeing this bug in version 3.3.3 OOO330m19 (build 301) (Ubuntu).  I save as
> .doc 97/XP and then reopen in either LO (same machine) or Word (on a Mac) and
> see the Mercedes symbol.  The Ubuntu machine is in the UK locale.  Font is
> arial.
Comment 23 Shaun Crampton 2011-10-02 19:33:51 UTC
I just upgraded but I still see the issue with the following version, again I tried word 97/XP format:

LibreOffice 3.3.4 
OOO330m19 (Build:401)
tag libreoffice-3.3.3.1, Ubuntu package 1:3.3.4-0ubuntu1

This is a pretty debilitating bug for those affected.  I'm having to email documents to a friend with Word and then edit each bullet back to being a circle before I send out a document.
Comment 24 westley52 2012-01-16 11:10:33 UTC
I agree that this is a pretty debilitating bug - particularly for people writing resumes in this difficult economy.  Instead of true bullet points, the people receiving the resumes are receiving a weird character if shared in Word format.  This definitely does not look professional.
Comment 25 Chris Peñalver 2012-01-16 16:21:46 UTC
Lubos Lunak, the problem exporting the attachment https://bugs.freedesktop.org/attachment.cgi?id=43913 to .docx (either version) or Microsoft Word 97/2000/XP/2003 .doc is unreproducible.

The amendment from Comment #5 is still reproducible exporting the attachment to Microsoft Word 95 .doc as the spacing between the bullet and the words are eliminated.

lsb_release -rd
Description: Ubuntu precise (development branch)
Release: 12.04

apt-cache policy libreoffice-writer
libreoffice-writer:
  Installed: 1:3.5.0~beta2-2ubuntu3
  Candidate: 1:3.5.0~beta2-2ubuntu3
  Version table:
 *** 1:3.5.0~beta2-2ubuntu3 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status

Marking back to ASSIGNED.

Vossman, as noted above, this bug has been Assigned To: Lubos Lunak. Please do not toggle the Status.
Comment 26 Korrawit Pruegsanusak 2012-01-20 03:26:54 UTC
Lubos, I see that you have committed a fix:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=58de34f6330e7093238bae2a14982e598867b336

So, could we mark this bug as fixed?
Comment 27 Luboš Luňák 2012-01-20 08:25:30 UTC
No, it is only a part of the fix.
Comment 28 Tim Richardson 2012-02-02 02:50:07 UTC
*** Bug 45416 has been marked as a duplicate of this bug. ***
Comment 29 Andras Timar 2012-03-05 08:00:23 UTC
*** Bug 46974 has been marked as a duplicate of this bug. ***
Comment 30 Rainer Bielefeld Retired 2012-03-27 01:23:51 UTC
3.4 lifecycle is terminated, so shifted to "Bug 37361 - LibreOffice 3.5 most annoying bugs"
Comment 31 Not Assigned 2012-05-09 06:14:49 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=13e6af8860f42daf49474a7ae9779baa0f8f2630

Related: fdo#34814 check if a missing font is a known symbol font
Comment 32 Luboš Luňák 2012-05-09 06:49:50 UTC
Fixed.
Comment 33 Not Assigned 2012-05-09 06:54:15 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1dc9f21667237bf61ec8d2a9e50b7fb8a61d475b&g=libreoffice-3-5

Related: fdo#34814 check if a missing font is a known symbol font


It will be available in LibreOffice 3.5.4.
Comment 34 Roman Eisele 2012-05-09 07:16:13 UTC
*** Bug 43866 has been marked as a duplicate of this bug. ***
Comment 35 Roman Eisele 2012-05-13 02:44:24 UTC
Maybe I miss something, but I can still reproduce this bug on MacOS X with LOdev version 3.6.0alpha0+ (Build ID: 9e536d2; installation file: master~2012-05-11_06.13.05_LibO-Dev_3.6.0alpha0_MacOS_x86_install_en-US.dmg).

Shouldn't the fix from comment #31 (2012-05-09 06:14:49 PDT) be in this build? Or does the fix not fix the problem on MacOS X?

I tried the 'Original .odt file, correct formatting' from the Attachments list above. If I open it with the Master build, it looks fine, but if I save it as .doc or .docx file, close the file and open the new .doc or .docx file, it looks still wrong (no bullets visible, instead just generic placeholder glyphs).

If someone else could please try (a) on Windows and/or Linux and (b) on MacOS, we could decide if I just missed something or if we should reopen this report or if we should create a new, separate bug report (if the bug is still reproducible, but this time only on MacOS). Thank you!
Comment 36 Roman Eisele 2012-05-13 03:16:43 UTC
And also still reproducible with LOdev version 3.6.0alpha0+ (Build ID: e3bc45b; installation file: master~2012-05-13_00.05.49_LibO-Dev_3.6.0alpha0_MacOS_x86_install_en-US.dmg), again on MacOS X. So actually a special MacOS issue (-> will open a separate bug report), or ...? Pls. confirm.
Comment 37 Luboš Luňák 2012-05-14 07:57:02 UTC
Document from comment #3, when re-saved as .doc or .docx, works fine for me with master build on Linux.
Comment 38 digital ant 2012-05-19 09:25:31 UTC
I tested this in 3.5.4rc1, found the same behavior in numbered lists. Wasn't sure if it was the same bug since it wasn't a bullet, so I created another...
https://bugs.freedesktop.org/show_bug.cgi?id=50119
Comment 39 Roman Eisele 2012-05-23 10:06:27 UTC
(In reply to comment #37)
> Document from comment #3, when re-saved as .doc or .docx, works fine for me
> with master build on Linux.

I have waited some days if someone could confirm the fix on Windows, but if I understand correctly the absence of any complains just means the same thing ;-) So, this issue is fixed now for Windows and Linux. But it is not yet fixed in LibreOffice 3.5.4.1 and the current LOdev (Master) on MacOS X, or, if you prefer another wording, there is still a very similar bug in LibreOffice for MacOS X.

For this special MacOS issue I have created the new bug 50284.
Any discussion regarding the remaining issue on MacOS should go to that bug report (and not here).

@Lubos Lunak,
@Caolan McNamara:
It is great that this long-standing issue is now fixed. Thank you very much! Now it would be wonderful, if you could take a look at the remaining MacOS issue (bug 50284) and try to fix it, too ;-) Thank you very much in advance ...
Comment 40 Roman Eisele 2012-05-23 10:28:57 UTC
*** Bug 41321 has been marked as a duplicate of this bug. ***
Comment 41 Alex Thurgood 2012-05-24 03:18:26 UTC
(In reply to comment #39)

Hi Roman,


> For this special MacOS issue I have created the new bug 50284.
> Any discussion regarding the remaining issue on MacOS should go to that bug
> report (and not here).
> 


Will check it out later when I get some time.


Alex