[Upstream] bullet points change to rectangle glyphs after saving attached as docx and reopening

Created attachment 43910
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.

Created attachment 43911
Reopened .doc file in libreoffice

Created attachment 43912
Reopened .docx in libreoffice

Created attachment 43913
Original .odt file, correct formatting

Created attachment 43914
Saved .docx file, square bullet points showing

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.

Lubos, could you have a look at this issue?

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.

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.

Created attachment 44069
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).

Created attachment 44070
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.

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.

As comment #10 says, the fix is incomplete.

(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.

Created attachment 45206
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.

*** Bug 35851 has been marked as a duplicate of this bug. ***

is anyone working on this, changing from ASSIGNED to NEW

*** Bug 35065 has been marked as a duplicate of this bug. ***

Bug and workaround (see 35065) are the same for 3.4.2 RC2/Windows OOO340m1 (Build:202)

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?

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?

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.

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.

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.

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.

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.

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?

No, it is only a part of the fix.

*** Bug 45416 has been marked as a duplicate of this bug. ***

*** Bug 46974 has been marked as a duplicate of this bug. ***

3.4 lifecycle is terminated, so shifted to "Bug 37361 - LibreOffice 3.5 most annoying bugs"

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

Fixed.

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.

*** Bug 43866 has been marked as a duplicate of this bug. ***

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!

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.

Document from comment #3, when re-saved as .doc or .docx, works fine for me with master build on Linux.

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

(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 ...

*** Bug 41321 has been marked as a duplicate of this bug. ***

(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

I don't get this… where is the corresponding MacOS issue? The link above to "bug 50284" takes me to a bug "[has patch] flashplugin-nonfree does not install".

I still have this bug in LO 3.5.5.3 on MacOS 10.7.4. A bit annoying. Well… if it weren't annoying, it would be not a bug, but a feature! :-)