The long-standing bug with bullet lists from .doc and .docx files was finally fixed in LibreOffice 3.5.4.1 (see bug 34814 with discusssion and patches). This is wonderful, thank you very much. However, this bug is not yet fixed on MacOS X, or to put in in other words: there is still a very very similar issue not yet fixed especially in LibreOffice for MacOS. To prove this, just open the .docx sample file for bug 34814 (attachment 43914 [details]) on MacOS X. Both * LibreOffice 3.5.4.1 (Build-ID: 7306755-f4f605c-738527d-1cf4bc1-9930dc8) * LOdev 3.6.0alpha0+ (Build ID: f8e94ec; date: 2012-05-21) still show strange glyphs instead of the normal bullet character. I will attach screenshots showing this. Even more interesting is to test attachment 60428 [details] and attachment 60429 [details], a .doc and a .docx file both created with MS Office 2007 and both just showing the default formatting settings of MS Office 2007, including a hierachical bullet list with sub-lists. If you open these files on MacOS X, you see that LibreOffice 3.5.4.1 and LOdev import some of the bullet types correctly (the bullets for the 2nd and 3rd list level), but others are corrupted (the bullets for the 1st and 4th list level). I will attach screenshots of these sample files, too. Additional hint: the two wrong glyph symbols visible on the screenshots are interesting. * The one, a three-pointed star similar to a Mercedes star, comes from the Windings font. * The other, a black box containing a symbol similar to a W, is actually a generic placeholder glyph inserted by MacOS X. It comes from the 'LastResort' font, a part of MacOS X itself. If I take a look at the contents of that font, I find that the W-like symbol is used as a placeholder for the Unicode code points U+E001 to U+E03F. This suggests that LibreOffice turns the bullet glyphs from the .doc and .docx files into some Unicode glyphs with a Unicode index betweeen U+E001 and U+E03F. Please note: This issue could be related to bug 50119, which is a similar problem with numbered lists.
Created attachment 62022 [details] How lo_ods.docx (attachment 43910 [details]) looks in LibO 3.5.4.1 on MacOS X
Created attachment 62023 [details] How lo_ods.docx (attachment 43914 [details]) looks in LibO 3.5.4.1 on MacOS X
Created attachment 62024 [details] How lo_ods.docx (attachment 43914 [details]) looks in LOdev 2012-05-21 on MacOS X.png
Created attachment 62025 [details] How attachment 60428 [details] (Word 2007 defaults .doc file) looks in LibO 3.5.4.1 on MacOS X.png
Created attachment 62026 [details] How attachment 60429 [details] (Word 2007 defaults .docx file) looks in LibO 3.5.4.1 on MacOS X
@digital ant, @junk_2010: You have both written bug reports about incorrect import of bullet/numbered lists from .doc/.docx files with LibreOffice on MacOS. Now the general bug about importing bullet lists is fixed (see bug 34814). But IMHO there ist still an issue about the import of bullet lists from .doc/.docx files especially on MacOS X, therefore I have created this special bug report for this MacOS issue. Could you please help to confirm this issue? I ask you because you are using LibreOffice on MacOS X. Just download LibreOffice 3.5.4rc1 from http://www.libreoffice.org/download/pre-releases/, if not already done, install it on a MacOS machine, and test the attachments mentioned in my description: attachment 43914 [details], attachment 60428 [details], and attachment 60429 [details] (you may know these files already ;-). Do you see the same strange glyphs (or other strange glyphs, that does not make a big difference) instead of the correct bullet glyphs, just like my screenshots attached to this present report show?! If you could confirm this issue, it would be very helpful. Thank you very much!
I have a problem to understand the FILESAVE component part of this bug. "lo_ods.docx" looks fine for me with "LibreOffice 3.5.4.2 (RC2) German UI/Locale [Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18] on German WIN7 Home Premium (64bit), also with MS WORD Viewer. I reduce this bug to FILEOPEN for now. @Roman Can you please explain the FILESAVE problem?
(In reply to comment #7) > I have a problem to understand the FILESAVE component part of this bug. [...] > @Roman > Can you please explain the FILESAVE problem? @Rainer: Oh, sorry, this is my fault! I first copied the Summary field from bug 34814 (because both bugs are so similar) and then adapted it, but obviously I forgot to remove the "FILESAVE". I don't see a FILESAVE component, too, only a FILEOPEN issue. (BTW: Was there really a FILESAVE issue in bug 34814? If not, we should remove "FILESAVE" from the Summary of that bug, too ...) Therefore, thank you for your question and for correction of the Summary field! IMHO it is correct as it stands now ("FILEOPEN .doc/.docx (MSO2007) Bullet lists show wrong bullet symbols MacOS X"). Set Status back to UNCONFIRMED, still looking for someone else to confirm this issue (on MacOS only, of course) ...
(In reply to comment #8) Hi Roman, > > Set Status back to UNCONFIRMED, still looking for someone else to confirm this > issue (on MacOS only, of course) ... I will check it out when I get some time... Alex
> (BTW: Was there really a FILESAVE issue in bug 34814? If not, we should remove > "FILESAVE" from the Summary of that bug, too ...) I am rather sure that the FILEOPEN in that Summary is wrong and superfluous, but some of the comments were too imprecise and I was too lazy to reproduce all testing for a Fixed Bug. Because you share my doubts I added a question mark there. @Shaun: It seems you have a Mac, can you help here with a confirmation?
I have downloaded and installed LibreOffice 3.5.4 RC2 (2012-05-24) on Max OSX 10.6 Intel Architecture. The issue with bullet points still exists for both the doc and docx imports of attachment 60428 [details] and attachment 60429 [details]. I will attach screenshots to show.
Created attachment 62181 [details] Screenshot of LibreOffice 3.5.4 RC2 doc import
Created attachment 62182 [details] Screenshot of LibreOffice 3.5.4 RC2 docx import
(In reply to comment #11) > I have downloaded and installed LibreOffice 3.5.4 RC2 (2012-05-24) on Max OSX > 10.6 Intel Architecture. > > The issue with bullet points still exists for both the doc and docx imports of > attachment 60428 [details] and attachment 60429 [details]. > > I will attach screenshots to show. @junk_2010: Thank you very much for testing this issue! So it is confirmed now that this issue is still a problem on MacOS X. Therefore, I change the Status to NEW.
@Lubos Lunak, @Caolan McNamara: It is great that the long-standing about wrong import of bullet lists from .doc/.docx (bug 34814) is fixed now. Thank you very much! But on MacOS X, there is still a very similar problem. I have added your address to the CC list because you have fixed bug 34814. It would be wonderful, if you could also take a look at the remaining MacOS X issue ... Thank you very much! @Thorsten Behrens: I have added your address to the CC list because you are our MacOS X expert, and this is (after the fix of bug 34814) now a MacOS-only issue. But it is still important. Thank you for taken a look at it!
don't have a mac unfortunately
(In reply to comment #16) > don't have a mac unfortunately Is there anything I (as a simple QA volunteer and Mac user) could do to help you with tracking down this issue?
I'm glad this issue is solved for windows and linux user! :-) But as a Mac user I hope this issue stays on the hot list because it prevents me to use and promote this software at my clients. As a submitter of one of the originals of this bug (Bug 41321) some years ago I already said that a solution of an issue like this is much more important for the growth of LibreOffice than some fancy new stuff. The basic stuff should first work to enable the adaptation of LibreOffice in far more professional organizations. I absolutely do not want to be rude - I know that all the work is done by volunteers - but just for the real break through of LibreOffice it is important to focus on "simple" issues like this. I'm not an IT specialist but as a Mac user of course I want to test solutions! Good luck!
Created attachment 64567 [details] Screenshot showing bullet points in v3.6.0.2 in MacOSX from docx import Screenshot showing bullet points in v3.6.0.2 in MacOSX from docx import
Created attachment 64568 [details] pdf showing bullet points in v3.6.0.2 in MacOSX from docx import This is a pdf exported from LibreOffice v3.6.0.2 after a docx import. The bullet points display correctly in the pdf. They displayed incorrectly when viewed on the screen, see screenshot in attachment #64567 [details].
I have uploaded two attachements after trying LibreOffice v3.6.0.2 on MacOSX. The bullet point display on screen is still incorrect for imported doc and docx files. However, if from LibreOffice a pdf of the file is exported the bullet points are correct. I have just uploaded the docx examples: screenshot attachment #64567 [details]. pdf export attachment #64568 [details].
dtardon->junk_2010: please _do not_ change the version field to _a newer_ version! The meaning of this field is the oldest version where the bug has been reproduced.
My apologies. I presumed "wrongly" that the version field would be used to check which bugs were confirmed with the latest version, as it is only the latest version that I presume would be likely to be "fixed". For the ignorant like me perhaps someone could consider changing the "Version:" field text to being "blue underlined", so there could be pop up of a short description of the purpose of the field when you hover over it, like occurs for other fields like "Component" and/or a link you can click on for an explaination like the "Component" and "Importance" fields? The same i suggest would be useful for the "Platform" field text.
*** Bug 53150 has been marked as a duplicate of this bug. ***
Created attachment 65505 [details] Default and styled bullet lists, ODS format
Created attachment 65506 [details] Default and styled bullet lists, DOC format (Word 97/2000/XP/2003)
Created attachment 65507 [details] Default and styled bullet lists, screenshot after reopening DOC
Please see my 3 attachments, "Default and styled bullet lists". Saving as DOC, closing and reopening changes the bullet symbol, *ONLY* if the bullet symbol is the default one. If you change the bullet symbol, then the new symbol is preserved upon save as DOC, close and reopen. Perhaps good to check whether the information about which bullet character to use is being saved in the document, or if that information is not saved. Then, upon reopen, LO would not be able to find the bullet character info and it fills up by using that square character. Created using LO 3.5.5.3 running over OSX 10.7.4.
In addition to my earlier comment (19): The original version of this bug was on the 'Most annoying bugs list'. After a fix for the Linux and Windows versions it was split in a resolved part (win and lin) and a new part (this bug). Why did the new part not return on the list with most annoying bugs? In my opinion it really is one of the most annoying bugs for a real breakthrough of LibreOffice. See my arguments in my earlier comment (and in predecessors of this bug). I hope it returns on that list to keep the right focus for the development team! Good luck!
(In reply to comment #30) > I hope it returns on that list Done. > to keep the right focus for the development team! Let’s pray that this really happens ... ;-)
(In reply to comment #31) > (In reply to comment #30) > > to keep the right focus for the development team! > Let’s pray that this really happens ... ;-) My previous comment was a bit loose; in order to prevent misunderstandings, some clarification may be necessary: I did neither want to say that our developers have lost the right focus (they are really doing a great job, fixing bug after bug, and adding valuable features -- they just can't do everything at once, because there are just too many problems to fix them at once, which is not a wonder, given the complexity of an office suite), nor did I want to insult someone’s religious feelings (I know that some people are very sensitive about this area); I just wanted to suggest that a nomination as MAB alone does not guarantee that this bug will be fixed soon -- as I said above, there are just too many problems to fix them at once.
I can confirm that on MaxOS X this is still an issue with LibreOffice 3.6.1.
I am using LO 3.5.6.2 on Mac OSX and can confirm this, truly annoying, bug. I had it in all LO Mac versions so far, but never using LO on Linux or Windows. Thank you for any efforts fixing it.
*** Bug 55554 has been marked as a duplicate of this bug. ***
ALL : What peeved me the most with regard to this bug is that 34814 was marked as resolved fixed for all platforms, when in fact it wasn't, since we are all still here on OSX waiting for something to happen. Since when is a bug declared fixed, when it has appeared on all the OSes we support, and then only repaired for some of them ? What was the evidence for the problem on OSX being different ? Also confirming that this bug is still present on OSX daily build from 01/10/2012. Alex
(In reply to comment #36) > What peeved me the most with regard to this bug is that 34814 was marked as > resolved fixed for all platforms, when in fact it wasn't, since we are all > still here on OSX waiting for something to happen. I have to agree. > Since when is a bug declared fixed, when it has appeared on all the OSes we > support, and then only repaired for some of them ? > > What was the evidence for the problem on OSX being different ? Historical explanation: I created a new bug report (this one) for the remaining problems on Mac OS X, instead of opening bug 34814 again, because of bad experiences in a similar case before. In that case, a bug was declared as fixed; but I could still reproduce it on Mac OS X, therefore I opened that bug again; then somebody (not even a developer) told me in a rather unfriendly manner I should not have done so, but had to open another bug for the remaining problems, and closed the bug again. Therefore I wanted “to do it right” in this case. ;-) So please don’t blame me for opening this additional bug report, instead of reopening bug 34814: I just wanted not to be insulted again. Additional reasoning: If the commits which fixed bug 34814 did not fix it on Mac OS X, it seems likely that on Mac OS X this bug has another (or: an additional) reason. Therefore it may be appropriate to handle this reason separately, i.e. in a new, dedicated bug report. But please let’s not argue about bug report politics, the more important point is: how can we get this issue fixed? Finally? I sometimes think/fear that this issue is related to some other symbol/glyph/character problems which are specific to LibreOffice on Mac OS X, e.g. bug 49645. So maybe someone needs to look into that issues, too, to find the reason for the present bug ...
(In reply to comment #37) > I sometimes think/fear that this issue is related to some other > symbol/glyph/character problems which are specific to LibreOffice on Mac OS > X, e.g. bug 49645. Sorry -- please forget bug 49645: it is too complicated as an example. Let’s concentrate on the bullets problem here.
Hi Roman, I didn't mean to criticise you for having opened this bug report, especially after all the work you've done triaging bug reports on OSX, and of course, it had to go somewhere :-)) but I still feel that 34814 shouldn't have been closed. If the font substitution code is different on OSX than on Linux/Windows, then one of the devs should have said so and made that the reason for creating a new issue, else we could all just open up a host of "Mac specific bugs" for the hell of it, claiming that the code is different (this is true for some things). Anyway, rather than waste time debating on it, as you say, what can we do to try and get this fixed ? We need someone who understands the intricacies of the Mac font management interfaces, and can dive into the corresponding deprecated ATSUI code used in LO on Mac to try and find out what's going. I don't know anyone on the dev team who has the time to do that, so we'll probably end up dumping this on Thorsten or Norbert again. Alex
Sigh, Thorsten's already on CC, so we're gonna have to wait...
And it is already in the MAB category.
Yes, as far as I can see there is nothing left we (bug wranglers) can do. Once I asked Caolán McNamara who has fixed many similar bugs, but he can’t take that Mac issue (see comment #16). What we really need are more Mac developers, but from where should we take them? Apple has enough money now to donate millions to LibO and other FLOSS software development without even noticing the expense, but who could persuade them to do so? But all such reasoning does not help ...
@ Norbert Thiebaud: Hello Norbert, this is a long standing issue, not dramatic, but very annoying, and while it was fixed for Windows and Linux (bug 34814), it is still reproducible on Mac OS X. I know that you have got much more important things to do, but maybe there is a chance that you could take a look at it ... there are many people who would be extremely happy about any progress in this issue ;-) Thank you very much in advance!
*** Bug 50474 has been marked as a duplicate of this bug. ***
Probably 55959 is a duplicate bug: https://bugs.freedesktop.org/show_bug.cgi?id=55959 Can someone please confirm?
*** Bug 55959 has been marked as a duplicate of this bug. ***
Is this related to opening .DOC files with special characters - such as the degree symbol? I get the same LastResort character in place of all the degree symbols. Or should I create a new bug report for that?
Although bug 55959 is a duplicate bug of this one do not forget the attachments to it, they may come in handy checking if the patch works.
Since the time has come to move all remaining and still important issues from the “LibreOffice 3.5 most annoying bugs” list to the “LibreOffice 3.6 most annoying bugs” list, and since this bug still prevails and dwells in LibreOffice 3.6.x and 4.0, and since many users agree that this little issue is (due to the sheer frequence of .doc/.docx files with bullet lists) still very annoying, and since the predecessor of this bug, bug 34814, *was* a “most annyoing bug” (just for all platforms, while this remaining issue is specific to LibreOffice on Mac OS X), I therefore move this bug from the 3.5 to the 3.6 most annyoing bugs list. ;-) But, of course, this does not help much to get a fix for this issue :-( @ Caolán McNamara: (In reply to comment #16) > don't have a mac unfortunately Hi Caolán, could you -- being our bug-killing hero, and having got a Mac now, IIRC --, could you please please ... you know what I am going to say ;-) Thank you very much ...
Created attachment 71662 [details] How lo_ods.docx (attachment 43914 [details]) looks in MSWord 2010
let me try and unpick this layer by layer a) comment #1 part 1: re attachment 43914 [details] in .docx format. The picture of this .docx rendered under MacOSX shown as https://bugs.freedesktop.org/attachment.cgi?id=62023 matches the picture of this .docx rendered by Microsoft Word 2010 as in my attachment of https://bugs.freedesktop.org/attachment.cgi?id=71662 i.e. three-pointed star. My MacOSX shows the same result as your screenshot, and comes with pre-installed Wingdings, Wingdings 2 and Wingdings 3 fonts, I assume yours does so given your screenshot. The symbol truly is set to be 0xF1 from Wingdings 2 so there's no bug in comment #1 part 1, its supposed to look like that.
a) comment #1 part 2: re https://bugs.freedesktop.org/attachment.cgi?id=60428 the bullet is a bullet from the "symbol" font and MacOSX comes with that font, but not with the bullet at the same place. So we may have to some up with something to do our recode magic not only when a known font is missing, but at a glyph replacement level where the font is not missing, but glyphs from it are.
@ Caolán: (In reply to comment #51) > let me try and unpick this layer by layer Thank you very much for taking up this issue! (In reply to comment #52) > https://bugs.freedesktop.org/attachment.cgi?id=60428 the bullet is a bullet > from the "symbol" font and MacOSX comes with that font, but not with the > bullet at the same place. So we may have to some up with something to do our > recode magic not only when a known font is missing, but at a glyph > replacement level where the font is not missing, but glyphs from it are. IMHO it may be well worth doing so, because the different encoding of the “Symbol” font on different platforms causes more problems in LibreOffice besides this bullets bug; cf. especially bug 49645 - “FILEOPEN particular MSWORD2008 .docx: misinterprets letters from Symbol font“. In the comment https://bugs.freedesktop.org/show_bug.cgi?id=49645#c10 Fridrich Strba already provided a mapping table, which IMHO could be used here ...
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=84a99c009e76582e79cc8341e2931d5b8261bb68 Related: fdo#50284 apple's modern symbol font is unicode encoded The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7be7b800fb72ffa63f60cf1e1ce1e7b206eb1e43&g=libreoffice-4-0 Related: fdo#50284 apple's modern symbol font is unicode encoded It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
b) comment #1 part 2: re https://bugs.freedesktop.org/attachment.cgi?id=60428 and https://bugs.freedesktop.org/attachment.cgi?id=60429 With the above commit to force a recode from old-school symbol encoding to apple/unicode encoding of the symbol font on MacOSX it now appears those work fine. c) comment #26 now loading that https://bugs.freedesktop.org/attachment.cgi?id=65505 and saving as .doc and reloading appears to give the same results as the original .odt, so that also seems to work fine now. d) comment #27 loading that pre-converted .doc of https://bugs.freedesktop.org/attachment.cgi?id=65506 now also seems to work fine now. That would seem to cover all the directly attached bugs piled up here. So I'll call this closed and submit proposed fixes for 3-6. I'll go through the duplicates and de-duplicate any that are still outstanding. Only re-open this bug if any of... https://bugs.freedesktop.org/attachment.cgi?id=43914 (comment #1) https://bugs.freedesktop.org/attachment.cgi?id=60428 (comment #1) https://bugs.freedesktop.org/attachment.cgi?id=60429 (comment #1) https://bugs.freedesktop.org/attachment.cgi?id=65505 (comment #26) or https://bugs.freedesktop.org/attachment.cgi?id=65506 (comment #27) still fail on MacOSX. Otherwise open a new bug and we'll handle them individually.
*** Bug 41321 has been marked as a duplicate of this bug. ***
(In reply to comment #55) > Caolan McNamara committed a patch related to this issue. > It has been pushed to "libreoffice-4-0": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=7be7b800fb72ffa63f60cf1e1ce1e7b206eb1e43&g=libreoffice-4-0 > > Related: fdo#50284 apple's modern symbol font is unicode encoded > > > It will be available in LibreOffice 4.0. > > The patch should be included in the daily builds available at > http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > http://wiki.documentfoundation.org/Testing_Daily_Builds > Affected users are encouraged to test the fix and report feedback. Hello Caolan (and Roman), I'm one of the guys who originally submitted this bug (already some years ago in OO times and on 29-9-2012 again in LO as bug 41321 => later: 50284). I'm really glad that "the end" is within sight now. At least it looks like that. At least thanks for the effort! I would really like to test it, but I am an end user. I am a kind of super user but not an IT specialist. So what should I do: Wait 24 hours and download a build here: http://dev-builds.libreoffice.org/daily/ But I see that that is 4.0 beta1 and you are talking about beta 3. Is that version available within 24-28 hours???? Can I help or should I wait? Kind regards, Marcel
(In reply to comment #58) > I would really like to test it, but I am an end user. I am a kind of super > user but not an IT specialist. > So what should I do: > Wait 24 hours and download a build here: > http://dev-builds.libreoffice.org/daily/ > > But I see that that is 4.0 beta1 and you are talking about beta 3. > Is that version available within 24-28 hours???? > Can I help or should I wait? You can probably test the bug fix right now, if you do not use the master (= 4.1) daily builds from http://dev-builds.libreoffice.org/daily/master/ ; to be more specific, IMHO the master build at http://dev-builds.libreoffice.org/daily/master/MacOSX-Intel@1-built_no-moz_on_10.6.8/2012-12-19_04.13.37/ *should* already include Caolán’s bug fix ...
(In reply to comment #59) > You can probably test the bug fix right now, if you do not use the master (= > 4.1) daily builds from http://dev-builds.libreoffice.org/daily/master/ Correction: a stupid typo; please ignore the “not” and read > You can probably test the bug fix right now, if you *use* the master (= 4.1) > daily builds ...
(In reply to comment #60) > (In reply to comment #59) > > You can probably test the bug fix right now, if you do not use the master (= > > 4.1) daily builds from > http://dev-builds.libreoffice.org/daily/master/ > > Correction: a stupid typo; please ignore the “not” and read > > You can probably test the bug fix right now, if you *use* the master (= 4.1) > > daily builds ... Hello Roman, Thanks for your tips. I have immediately tested it using master~2012-12-19_04.13.37_LibO-Dev_4.1.0.0.alpha0_MacOS_x86_install_en-US.dmg and ... I am very VERY HAPPY!!!!! I have used an existing Word doc with bulleted and numbered lists with 3 to 4 levels and all signs and indents are correctly imported in Libre Office. After opening them in Libre Office I did again save them as .doc (still in LO) and I did open that file again in Word (and in LO) and the signs are still correct. So it was only a rather small test and I have not yet tested docx (but I don't expect problems there) and it is only one documente I've tested. I'm very hopeful though that this long outstanding issue is finally solved! It really looks like Caolan is a bug killer (and now in Mac OS X too)! Thanks Caolan for your nice piece of work! If this really is solved in 4.1.0 then I suggest that your marketing people give al lot of attention to this issue when 4.1 is introduced because this issue was really preventing professional organizations from using LO. Until now I could not advice them to start using LO (because they would lynch me if they would run into these kind of errors on day one). So this solution will lead to new business opportunities for LO! If you would like me to do some more testing, please let me know. THANKS - THANKS - THANKS Roman and Caolan! :-) Marcel
VERIFIED as FIXED: I have tested this issue myself with the latest master build, like Marcel, and can confirm that it is fixed -- attachment 60428 [details] and attachment 60429 [details] are now displayed correctly, with the right bullet glyphs in all list levels. So -- thank you, Caolán, very very much for fixing this long-standing issue! (In reply to comment #61) > THANKS - THANKS - THANKS Roman and Caolan! :-) Oh, you don’t need to thank me; Caolán is the one who did all the work. I am just a simple-minded bug wrangler who continues to annoy our developers by reminding them from time to time of such long-standing issues ;-)
(In reply to comment #62) > (In reply to comment #61) > > THANKS - THANKS - THANKS Roman and Caolan! :-) > Oh, you don’t need to thank me; Caolán is the one who did all the work. I am > just a simple-minded bug wrangler who continues to annoy our developers by > reminding them from time to time of such long-standing issues ;-) Luckily for end users like me there are also simple-minded bug wranglers who "push" developers to the the right thing! ;-) Otherwise we would end having a very nice but useless / 'unsellable' product... And I know it has been a bit frustrating for you too to wait, coordinate and push for such a long time. So thank you as well Roman! (and please go on, like in tennis: set by set, game by game, point by point). Marcel
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=11cc324da0e0008bca10ac19aca274cfec54ec2f&h=libreoffice-3-6 Related: fdo#50284 apple's modern symbol font is unicode encoded It will be available in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I can confirm that using LibreOffice 4.0.0.1 installed on a macbook running OSX 10.6 (Snow Leopard) that the bullet points in both the: doc attachement 60428 docx attachment 60429 [details] display correctly. Thank-you for fixing this.
Thanks again Caolin and Roman, It IS available in 3.6.5 now and it works. Please inform the "guys" of marketing about this. This was really a show stopper for many professional organizations to use Libre Office and its predecessors. Now this is solved I'm sure the potential growth of LibreOffice is increased dramatically! Something to discuss at the next conference? Good luck. Marcel (In reply to comment #64) > Caolan McNamara committed a patch related to this issue. > It has been pushed to "libreoffice-3-6": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=11cc324da0e0008bca10ac19aca274cfec54ec2f&h=libreoffice-3-6 > > Related: fdo#50284 apple's modern symbol font is unicode encoded > > > It will be available in LibreOffice 3.6.5. > > The patch should be included in the daily builds available at > http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > http://wiki.documentfoundation.org/Testing_Daily_Builds > Affected users are encouraged to test the fix and report feedback.
I believe that as of libreOffice 4.1.0.4 there has been a regression of this issue in that some bullets are no longer displaying correctly. I have opened bug 67412 for this.