Description: When insert a heading between two headings of the same level in a docx document, outline is not applied for the inserted heading. Steps: 1. New Writer, type to paragraphs of text; 2. Apply all paragraphs as "Heading 1" style; 3. Set outline numbering of Heading 1 to "1,2,3..." (tools->outline numbering). 4. Save as DOCX (MSO 2007/10/13 xml) 5. Reopen, insert a new paragraph between the above paragraphs, apply as "Heading 1" style also. Current behaviou: Outline numbering is not applied to the new paragraph inserted in step 5. Expected: Outline numbering is applied to the new paragraph inserted in step 5. This bug behaviour do not happen with ODT format. Possibly a regression.
(In reply to comment #0) > 1. New Writer, type to paragraphs of text; Sorry, I mean "..type two paragraphs..."
Created attachment 96638 [details] The example docx file. In this step: > 5. Reopen, insert a new paragraph between the above paragraphs, apply as "Heading 1" style also. Please set the style as "body text" before you set it to "Heading 1" again.
I found some more simple steps to reproduce: 1. New Writer, two paragraphs; 2. Apply the two paragraphs as "Heading 1" style, save as DOCX; 3. Reopen, try to apply outline numbering to heading 1. Current behaviour: You are not able to apply outline numbering of any style to the headings.
Created attachment 96639 [details] a more simple docx to example.
Confirmed in Linux Mint in 3.3.0, 4.2.5 and 4.3.0 with steps from comment 3. Unfortunately, the docx file in comment 4 wasnt suitable as the text was set to '标题 1' style and not 'Heading 1'. In order to get the right results, i could set the outline numbering for Heading 1, then hightlight the 2 paragraphs, and set their style to Heading 2, and then back to Heading 1, and then the numbering will show up.
I can confirm this bug still exists. A deal breaker for me. If chapter numbering does not work then I cannot use the Word Processor. And since I only use a WYSIWYG Word Processor if I have to share docs w/ people that don't know how to use LaTeX MS's .doc(x) format is the ONLY way to go. Hope this'll get some priority.
Seems like a duplicate of: https://bugs.documentfoundation.org//show_bug.cgi?id=50774
(In reply to Kevin Suo from comment #3) > I found some more simple steps to reproduce: > > 1. New Writer, two paragraphs; > 2. Apply the two paragraphs as "Heading 1" style, save as DOCX; > 3. Reopen, try to apply outline numbering to heading 1. The two paragraphs in your sample document are "标题 1", not "Heading 1" > Current behavior: > You are not able to apply outline numbering of any style to the headings. When I do the same in my LibreOffice 4.4.3.2 on Ubuntu 32 bits, the only problem I see after reopening the docx: before the first paragraph with heading 1 there is the number '1' and before the second paragraph with heading 1 there is the number '2'. (should try to find that bug) So the mentioned problem either is specific to the document, or to the installation.. Kevin, can you please attach a .odt file that you use to create the docx? thanks, Cor
Created attachment 115524 [details] test files from 4.4.3.2 Ubuntu 32 bits, Dutch locale
Removing from mab4.4, and adding to DOCX-limitations meta.
@meneerjansen00@gmail.com Please don't add your pet bugs to the MAB tracker - that is not the way to raise awareness to a bug that you yourself say "is a dealbreaker for ME." Manipulating priorities and/or MAB trackers in order to raise awareness of pet bugs is frowned upon. You can learn how things work, why comments like "this is a dealbreaker FOR ME" is not useful at all, (and things you can do to help) by reading: https://joelmadero.wordpress.com/2014/10/11/user-expectations-and-the-reality-of-our-community/ If you're interested in becoming more involved with QA to learn how things are done, feel free to join us at: webchat.freenode.net/?channels=libreoffice-qa Thanks for your understanding.
(In reply to Joel Madero from comment #11) > @meneerjansen00@gmail.com > > Please don't add your pet bugs to the MAB tracker - that is not the way to Hi Joel, I can understand your little irritation here, since there is a high pressure on the QA team :) But I have no reason to think that meneerjansen (sounds rather Dutch by the way) really wants to promote a pet bug. I expect it more being a case of limited experience with our complicated work flow. Or too big enthusiasm to lend a helping hand. Anyway: great that you pointed to the documentation. @meneerjanser If you have questions and the opportunity to chime in at irc, we'll be glad to try to help. As much as we would appreciate to see you active in our bugzilla and testing in the future. By working closely together, we can really make LibreOffice better and better. (you won't see me there active that much, busy with other work) Cheers, Cor
Just came across this little discussion and... (In reply to Cor Nouws from comment #12) > I can understand your little irritation here, since there is a high pressure > on the QA team :) ...and if you don't mind _my_ chiming in, what is the best way to get an information on things in source code, like where is done what? On bug tracker I'm told to go to the developers' list with that kind of questions. I ask on the developers' list and get no replies. Would that mean nobody is involved with the particular piece of code and that it just 'floats along'? Or are there better places for such queries?
@Kevin, per comment 8, the NEEDINFO is to you for the original document as .odt @Yury, the code is reasonably well self documented--but it helps to have a map of how elements are connected. So from the Wiki: https://wiki.documentfoundation.org/Development/Code_Overview Other guidance in Wiki, as well as on the Dev ML and IRC channel. In this case, believe handling of outline numbering during the writer -> OOXML -> writer is an export/import filter issue on the round trip. Which is why the original document is needed to follow its filter conversions. I think it mostly lives here: http://opengrok.libreoffice.org/xref/core/sw/source/filter/ww8/
Created attachment 115699 [details] Original ODT document ODT file with a correct Outline Numbering
Created attachment 115700 [details] DOCX version DOCX version of the original ODT document
Hi all. I confirm this bug in version 4.4.3.2 for Mac OSX. I attached two documents: on e ODT and its DOCX version. In the ODT you can see that the Outline Numbering works fine and in the status bar at the bottom of the Writer windows, when the cursor is on a heding text, you can read "Outline Numbering". After you save it to DOCX format and you reopen it, when the cursor is on a heading text, in the status bar you can read some WWWNumX numbering structure. The Outline Numbering is lost. And also its configuration: if you enter the Tools -> Outline numbering you have to associate each Outline level to a Style from the beginning. Hope this helps for the solution. regards Lorenzo
(In reply to V Stuart Foote from comment #14) > @Yury, the code is reasonably well self documented--but it helps to have a > map of how elements are connected. So from the Wiki: > > https://wiki.documentfoundation.org/Development/Code_Overview Nothing crops up on search on my problem there, but thanks all the same for the link.
Hi Lorenzo, (In reply to Saffax from comment #17) > > Hope this helps for the solution. Thanks! In any case it helps to confirm the issue. I see related problems, bit a bit worse, when I do the test in LibreOffice 3.3.4 and 3.4.6. Looking to my #comment 8: if I change the test document and activate outline numbering before saving as docx, the same problem shows.
(In reply to Yury from comment #18) > Nothing crops up on search on my problem there, but thanks all the same for > the link. If that does not work, chime in on irc #libreoffice-dev and ask your precise question. HTH, Cor
(In reply to Cor Nouws from comment #12) > (In reply to Joel Madero from comment #11) > > @meneerjansen00@gmail.com > > > > Please don't add your pet bugs to the MAB tracker - that is not the way to > > Hi Joel, > > I can understand your little irritation here, since there is a high pressure > on the QA team :) > > But I have no reason to think that meneerjansen (sounds rather Dutch by the > way) really wants to promote a pet bug. I expect it more being a case of > limited experience with our complicated work flow. Or too big enthusiasm to > lend a helping hand. > > Anyway: great that you pointed to the documentation. > > @meneerjanser > If you have questions and the opportunity to chime in at irc, we'll be glad > to try to help. As much as we would appreciate to see you active in our > bugzilla and testing in the future. By working closely together, we can > really make LibreOffice better and better. > > (you won't see me there active that much, busy with other work) > > Cheers, > Cor Dear Cor, dear Joel, I haven't been here for a quite while (dunno how to activate e-mail notification in case of added comments) and I am happy to see that this bugzilla report is regularly fed w/ comments. Being just a simple user, however, I do not see any progress on the issue even though I'm convinced that hard work is being done on this bug by you developers. What I meant by "dealbreaker" is that many people will probably think the same way as I do but do not take the trouble of filing a bug report or comment in a bug report (read on). This is the opposite of what software developers want: they want as many people to use the fruit of their labor. I realize now that I chose the complete wrong words to encourage and stimulate developers. ====================================== [off topic] There a many reasons that people do not file bug reports even though one is always asked to do so in forums: 1. The layout of bugzilla sites is not very clear (and that is putting it mildly). For somebody like me it's almost impossible to figure out what to click, what it all means, how to activate mail-notification, how to find duplicates etc. etc. It's a real pain to do anything w/ bugzilla sites. 2. When you come here you are FTFM'ed and asked to go to yet another medium (i.e. chat) for the bug. The bug is described crystal clear, nothing to add except to ask for (high) priority and the progress on it. So dear Joel, I've read the Wordpress Blog entry to which you posted the link. I agree w/ everything that is said there. :) However, I do not know what a MAB tracker is. Some weeks ago I must have activated it without realizing what it is. I shouldn't have. I'm awfully sorry, but like I said the interface/layout of this site is almost impossible to understand within a hour or so. I also do not know what a pet bug is (pet bug meaning "minor" bug?). Sorry for using the words "deal breaker" and "me". But if you think that chapter numbering in a word processor is a minor thing, then you might be the best of developers, but then you've clearly never written a document in a word processor as opposed to a text editor. One of the few advantages of a word processor over a text editor is the automated numbering of chapters and sub chapters and henceforth the automated generation of the table of contents. Non-working - or extremely buggy - chapter/outline numbering is a deal breaker for any word processor. Sorry for the strong language, but that's the way it is. It is most definitely NOT my pet bug: chapter numbering is the first thing one starts to use when starting to write a document in a word processor. This way of communicating might come over to you as hostile, but most people think that devs in bugzillas have no feelings at all and therefore use strong language. For this I apologize sincerely. Believe it or not: by emphasizing in my own little amateurish way I wanted to express that developers might want to pause on developing some other bugs because this one is quite big and important. I really think this is THE bug to work on. If not, I dare any of the developers to mention a bug bigger and more important that this one. And as for the exportation to Micro$oft Word: that is also one the most used functions of Libre/Open Office in my experience. Where I come from (the scientific world) we are forced to use a word processor sometimes if LaTeX is not being understood by the (non scientific) people that we HAVE to share documents with sometimes. In those cases we scientists have learned, ever since 1986 (the year TeX was released), that is no good to RTFM to people to learn how to use LaTeX. So I understand the argument of software developers that one had rather add input to the development of LO, as opposed to expecting people who know how to program to do it. If that was the sole behavior of us scientist we'd never walked on the moon or will we ever find a solution for the green house effect. So let me develop a solution for you and your kids for these kinds of things - using my particular set of skills - and then you find a solution for chapter numbering in LO documents that are exported to .docx, okay? And, yes, I do voluntarily work for free too. When I can. But programming is unfortunately not one of them. And from me too people expect me to perform like a professional. I forgive them: they have every right to encourage me if I present myself as a person that will get things done for them, even if it's for free. Because if I would't somebody else would (for money or for free). And if they would't: life would be more clear and more manageable for them. Your skills and talents may lie in programming, mine unfortunately do not. I can never, ever, help you lessen the burden of developing software, just like you can never lessen the burden of me solving environmental issues. All the best w/ developing my beloved Libre Office and determining priorities. :) [sorry for the long off topic, I hope it helps instead of irate, honestly!] Dear Cor, [off topic] first of all: yep, I'm Dutch. Visit the Nedlinux forum some time if you're a Linux user or want to start as one. :) [semi on topic] Indeed: you guessed perfectly well what I meant. Again, I apologize for certain things I did by mistake to file this bug or to write about it. ========================================== [on topic] 1. The duplicate of this bug (https://bugs.documentfoundation.org//show_bug.cgi?id=50774) is older than this one but it has lesser recent comments. I don't know precesely how, but a moderator of this bugzilla might want tot consider merging the two... 2. Any progress on solving the bug? (or did I miss a progress report in the lay out which is a bit confusing to me?)
Finally realized that 'MAB' means "most annoying bug". See bug 79641 (which is the bug called "LibreOffice 4.4 most annoying bugs").
Certainly, it is an annoyance when using Microsoft proprietary formats, but at its core it is an interoperability issue in import and export filtering of DOCX (OOXML) styles. It is not an issue when the document is held in ODF native formatting, which would be much more critical an issue. Not a MAB critical issue.
Mistakenly I posted some comments in the "Most Annoying Bugs" (MAB, bug 79641) topic instead of here. Here are those comments, a moderator might delete them from the MAB. ==================================================== (In reply to V Stuart Foote from comment #72) > (In reply to meneerjansen00 from comment #71) > > I take it then that we do not have to count on (work starting on) a fix for > > this bug to come anytime soon? That will be quite disappointing for a lot of > > LO users I'm afraid... > > Not at all, work on the WW8 import/export filters is continual. For example, > if you follow the samples and discussion of bug 50774 there has been noted > improvement. > I'm afraid I do not see a lot of improvement in that bub. I do see some discussions. But no patch or suggested solution. I'm sorry > Otherwise, concise test cases with annotated comparisons in the XML of OOXML > and ODF rendering of the sample documents will provide needed incentive to > devs for correcting the filters. That as opposed to general statements that > it is "not working". > I'm afraid you lost me there. I'm willing to do anything youy want me to. But I do not understand what y'all would like me to give. Is the example doc not good enough? Can you not reproduce the bug? Please help me to provide you with the proper testing documents. On a side note, the description in bug 76817 comment #3 is crystal clear to me. And very reproducable. I'm afraid I do not know waht the devs would like more. If I would, I'd provide y'all with what you want in the bug report you want. I'd like to help or provide input, but I really do not know how anymore. Bug 76817 commnent #3 is so clear already... > Filing useful bug reports aside, a user can put the onus back on Microsoft > and export from there as ODF (e.g. .odt), rather than OOXML (e.g. .docx). Or > in a more parochial sense work only in LibreOffice rendered ODF--that is > what LibreOffice as a project is obliged to support. In this hard dog eat dog worl I'm afraid the smaller fish has to accept that the bigger fish is boss. Same thing goed for LaTeX (www.latex-project.org) and any other way to produce documents. Best regards, Jansen =========================================== ========================================== @V Stuart Foote I'm gonna have to read up on the Office Open XML (OOXML) format/file type (which, confusingly to me, is called .docx in LO), the native Word 2007 (and higher Word versions) file format (also called .docx) and ye 'ol .doc format. This is not to be confused w/ the 'open document file' (ODF) format which, I believe, has been used by Libre- and OpenOffice since a long time. Documents in the ODT format have the extension .odT (with the T from Text, not the D for document) which is also confusing to me (I thought that native LO and 'ye 'ol OOo documents ndend in .odF). I found a nice article about this: https://brattahlid.wordpress.com/2012/05/08/is-docx-really-an-open-standard/ Sorry for all this off topic stuff by me that really belongs in a chat or support forum. I'm getting old. Back in the days there was only M$ Word (i.e. .doc) and OpenOffice (which I thought saved in the .odf extension). As for now, what I did to create a document that my Word loving friends can read, edit and save is: 1. Open Libre Office. 2. Create new Writer document. 3. Write some text. 4. Choose: File > Save as > Microsoft Word 97/2000/XP/2003 (.doc). FYI: I used to choose .doc because I thought that .docx was less well supported in OOo/LO... 5. Or I choose: File > Save as > Microsoft Word 2007/2010/2013 XML (.docx) I never even noticed that in LO there's also an option way down at the bottom called "Office Open XML (.docx)". Until today I've never heard of this format. Until today I really couldn't give a rats *ss 'bout M$'s fiddling w/ .doc and .docx format. I just don't care. If people want to use proprietary software and operating systems that's their problem, not mine. Boy was I wrong! I'll try to create an .docx LO (that is Office Open XML, not Microsoft .docx!) document and I'll test if the outline numbering probelm is also there. As for me the question remains how MS Word 2007+ handles OOXML .docx files that were created by LO. Does it leave LO's .docx format intact or not? And how does LO handle M$ created .docx files, does the outline numbering bug appear of doesn't it? To be continued. Hope y'all will forgive me all the confusion I might have created and the overly long comments that posted here. One is never to old to learn. :-) ============================================= ========================================= 1. Reading the blog that I mentioned earlier is highly recommended for all people who have ever used MS Office '97 to 2003! See: https://brattahlid.wordpress.com/2012/05/08/is-docx-really-an-open-standard It clarifies why there are two ways of saving a document as .docX! 2. Tried to reproduce the bug by making a document in LO and saving it in Office Open OOXML format (i.e. NOT MS's version of OOXML/docX!). 3. Bug still there. 4. When one saves the document in LO's native open document format (ODF, confusingly ending in .odT) bug is not there. Conclusion: the bug does not have anything to do with Microsoft's crappy implementation of the OOXML standard. The bug has to do w/ the way Libre Office generates a document in the the OPEN document standard OOXML (confusingly also called .docx, not LO's fault, see aforementioned blog). This bug, strangely enough, probably has nothing to do w/. Microsoft! =========================================== =============================================== Created attachment 116900 [details] Two documets made w/ LO in OOXML format and re-saved as... Two test documents. Both made in LO. One is saved as OOXML (LO's version of OOXML, not MS's version!). The other was made in LO, saved as OOXML (it had the bug) and after that saved as .odT which only made the bug disappear after reapplying ALL outline numbered styles. So using .odt as an intermediate when ou receive a Word doc will not work. ============================================ =========================================================
Curious to know if anyone picked this up after the comments last week. To summarize: this bug does not have anything to do with Microsoft's implementation of the OOXML standard ("their" version of .docx). The bug has to do w/ the way Libre Office generates a document in the the open document standard OOXML (also called .docx).
(In reply to meneerjansen00 from comment #25) > Curious to know if anyone picked this up after the comments last week. I intend to have a further look, but since the amount of text etc, I'm not sure when. But there are others too..
(In reply to Cor Nouws from comment #26) > (In reply to meneerjansen00 from comment #25) > > Curious to know if anyone picked this up after the comments last week. > > I intend to have a further look, but since the amount of text etc, I'm not > sure when. > But there are others too.. With amount of text you mean my comments? For that I apologize: I wanted to clear things up and provide developers w/ as much input as possible. But it all comes down to my last comment: Libre Office generates a documents in the the (open document standard) OOXML the wrong way concerning outline numbering.
@meneerjansen: yes, it has to do with the OOXML implementation. I think this issue is sufficiently triaged: comment 15/17 give a reproducable file + instructions. comment 19 mentions, despite the current bug, some improvements over older versions of LibreOffice. It is not a regression.
@miklos: if you ever touch the area of outline numbering for docx/OOXML, this issue might be of interest :) thanks,
When outline paragraphs are stored they get their own numbering style. You can see this if you look into format/paragraph/outline&numbering, Numbering style. It contains e.g. a WWNum1. On import this word numbering style is not (can not be?) mapped to Writer's outline numbering. It is also not applied to the 'Heading X' style but to the paragraphs.
Migrating Whiteboard tags to Keywords: (filter:docx) [NinjaEdit]
Mark Hung committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=78284714b73a8307174c596295894e8f3951e09a tdf#76817: fix missing heading styles assigned to outline levels in ooxml It will be available in 5.2.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.
(In reply to Commit Notification from comment #32 @Mark Hung: Thank you so much for the fix, is there any plan to backport this to any of the released versions such as 5.1?
Adding Mark Hung to assign field. Requesting backport to older versions.
I attempted to backport Mark's patch on gerrit but it failed. https://gerrit.libreoffice.org/#/c/22086/
(In reply to Yousuf (Jay) Philips from comment #35) Cherry pick fails - so we need to manualy prepare another patch for other branches?
https://gerrit.libreoffice.org/#/c/22441/
Mark Hung committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb35db2c709d2d5fd1f86e84478944416cf7f6e0&h=libreoffice-5-1 tdf#76817: fix missing heading styles assigned to outline levels in ooxml It will be available in 5.1.2. 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.
Created attachment 123368 [details] tested with document in daily build 20160225 Hi, I did a test with file https://bugs.documentfoundation.org/attachment.cgi?id=96638&action=edit Attached the result. I do not see what has changed, sorry. Test in Version: 5.2.0.0.alpha0+ Build ID: 98a8eafa915b8d57b8bdccab9981e537d77f6f4a CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-02-25_00:51:35 Locale: nl-NL (nl_NL.UTF-8)
(In reply to Cor Nouws from comment #39) I confirm that the commit does not fix the issue I mentioned in comment 3. However, it seems that this commit does fix bug 80985.
Downloaded and installed LO Fresh ver. 5.1.3 (64 bit). Indeed: unfortunately bug still there. Most certainly hope this filter bug wil get solved soon.
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Created attachment 139050 [details] Headings2003.docx: testing example created by Word 2003 I didn't like any of the reproducing example documents, so I made my own simple one using Word. The problem is that Writer has this strange "Chapter Numbering" style (or "outline numbering" as shown by the paragraph style dialog...) that doesn't show up in the list styles. On import, the heading style's associated numbering list (although copied to Chapter Numbering) is saved as a new list style. That WWNumX list style is applied to the "existing" headings, but the strange "Chapter Numbering" style is applied to new headings, thus the disconnect between the numbering.
*** Bug 87052 has been marked as a duplicate of this bug. ***
two part fix: both export and import needed adjusting. -import: https://gerrit.libreoffice.org/47827 -export: https://gerrit.libreoffice.org/47828 Developed in order to round-trip the example file from comment 43. Used example file from comment 15 to confirm. Also fixes example from duplicate bug 87052.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7201d157a2ff2f0a8b6bb8fa57e31871187cbc81 tdf#76817 ooxmlimport: connect Heading to existing numbers It will be available in 6.1.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8e9e705de29a1a3d9b964c9350aa2a3a17cce6f9 tdf#76817 ooxmlexport: only use stylename for Outline list It will be available in 6.1.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.
Looks resolved. Justin, please comment on backport for 6.0 and 5.4. Looks to me that Bug 102619 is somewhat similar, but not duplicate. While testing this, I created Bug 115104.
(In reply to Timur from comment #48) > Justin, please comment on backport for 6.0 and 5.4. I have no intention to initiate backports for numbering bug fixes. I'm very happy that these fixes are going in with 9 months of testing ahead of them before they hit production. :-)
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d42de21c10bfefeaffabc5c939e7830a09f7dca revert tdf#76817 ooxmlimport: connect Heading to existing numbers It will be available in 6.1.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.
Reverted the commit from comment 46 and re-opened the bug, because an example document from bug 50774 is made worse by that commit. I'm not surprised that a regression was found - almost impossible to make changes in this area without doing so. Reverting does two things. -most importantly, it allows me to walk away from this without causing harm. I hate causing regressions, and this patch has not yet hit a released version of LibreOffice. -it gives a chance for the compatibility tools to find how many documents were fixed by the patch, and now are broken again. It is easily possible that more are fixed than broken - and so this can be revisited in 6.2. It is worth noting that the patch from comment 46 aligns docx with doc. Both of them display bug 50774 the same way. And .doc does not have this bug's problem. Microsoft's numbering implementation is very complex, and very different from LO's internal design. So a lot of "emulation" needs to happen, which by definition means certain features simply cannot work. It is a balancing act between supporting the most common cases, and breaking once-working odd-ball cases. (And my impression is that the current import implementation is a mess - not using style name references, but directly applying the properties to the paragraph, with lots of code scattered around handling edge cases...)
(In reply to Justin L from comment #51) > Reverted the commit from comment 46 and re-opened the bug, because an > example document from bug 50774 is made worse by that commit. I'm not > surprised that a regression was found - almost impossible to make changes in > this area without doing so. > > Reverting does two things. > -most importantly, it allows me to walk away from this without causing harm. > I hate causing regressions, and this patch has not yet hit a released > version of LibreOffice. > -it gives a chance for the compatibility tools to find how many documents > were fixed by the patch, and now are broken again. It is easily possible > that more are fixed than broken - and so this can be revisited in 6.2. > > It is worth noting that the patch from comment 46 aligns docx with doc. Both > of them display bug 50774 the same way. And .doc does not have this bug's > problem. > > Microsoft's numbering implementation is very complex, and very different > from LO's internal design. So a lot of "emulation" needs to happen, which by > definition means certain features simply cannot work. It is a balancing act > between supporting the most common cases, and breaking once-working odd-ball > cases. (And my impression is that the current import implementation is a > mess - not using style name references, but directly applying the properties > to the paragraph, with lots of code scattered around handling edge cases...) Do you mean that we should learn to live w/ the fact that exchanging documents with MSOffice users will never be possible if one uses chapter numbering (or rather: outline numbering)? And am I right that you say that we CAN, however, exchange chapter numbered documents w/ MSOffice users as long as we use good old .doc format and not .docx?
(In reply to meneerjansen00 from comment #52) > Do you mean that we should learn to live w/ the fact that exchanging > documents with MSOffice users will never be possible if one uses chapter > numbering (or rather: outline numbering)? Not really. What I mean is that a talented programmer should dedicate a couple of months of their life to re-write/enhance this area of LibreOffice (and then spend several more months supporting their changes). > And am I right that you say that we CAN, however, exchange chapter numbered > documents w/ MSOffice users as long as we use good old .doc format and not > .docx? No. I'm saying that if your document doesn't look good in .docx, try .doc format and then pick whichever one works better for your particular document.
(In reply to Justin L from comment #53) > (In reply to meneerjansen00 from comment #52) > > Do you mean that we should learn to live w/ the fact that exchanging > > documents with MSOffice users will never be possible if one uses chapter > > numbering (or rather: outline numbering)? > Not really. What I mean is that a talented programmer should dedicate a > couple of months of their life to re-write/enhance this area of LibreOffice > (and then spend several more months supporting their changes). > > > And am I right that you say that we CAN, however, exchange chapter numbered > > documents w/ MSOffice users as long as we use good old .doc format and not > > .docx? > No. I'm saying that if your document doesn't look good in .docx, try .doc > format and then pick whichever one works better for your particular document. Equally exchange ODF rather than OOXML (Microsoft Office "implements" the standards)--then the LibreOffice project has more obligation to make it interoperable.
I can confirm this bug with when saving as DOCX (Strict and Transitional) but not ODF and DOC LO Version: 6.1.2.1 Build ID: 1:6.1.2-0ubuntu1 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group threaded
*** Bug 121066 has been marked as a duplicate of this bug. ***
Bug still replicated in. Version: 6.3.0.0.beta1 (x64) Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded
Repro 6.4+ after the fix in bug 95848.
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
possible duplicate- bug 130446
Bug 107683 might help to solve?
Still repro. Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: bfbf745470cb6f99532523fdeffca061b37d8393 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 31 May 2020
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2128d59ab91da853652305390d56b3287bcb67b1 tdf#76817: DOCX import: fix chapter numbering It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/de1b634a151c198584dc152676183f519c50a2da tdf#76817: DOCX import: fix custom chapter numbering It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 162043 [details] Screenshot of attachment #139050 [details] in current master vs bibisect 7.1 The document from comment #43 looks good now in todays nightly: Version: 7.1.0.0.alpha0+ (x64) Build ID: 33a720ab802491f15b247e09755cd36205b6f435 CPU szálak: 4; OS: Windows 6.3 Build 9600; Felületmegjelenítés: alapértelmezett; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL Compared to bibisect-7.1 from 4 days ago: Version: 7.1.0.0.alpha0+ (x64) Build ID: ff508f6d8a3e58d29e9e7622006a7103fb0a2849 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL The document from comment #15 is still not good when saved as docx & reloaded. That case should be handled under bug #130446
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/7ed62ccc2bc436001bbf033db22ec2f19c70fdf2 tdf#76817: DOCX import: fix chapter numbering It will be available in 7.0.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/eb90d729178b3acec3f0045b96e1011d57d57bb6 tdf#76817: DOCX import: fix custom chapter numbering It will be available in 7.0.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5568d92c5c705b4d728af859dc44afdd64e72195 tdf#76817 DOCX: fix round-tripped outline numbering It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/c850d7288650c37a3c569fd4891ecdf725b3a279 tdf#76817 DOCX: fix round-tripped outline numbering It will be available in 7.0.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 130446 has been marked as a duplicate of this bug. ***
(In reply to NISZ LibreOffice Team from comment #65) > The document from comment #43 looks good now in todays nightly: Bug looks fixed. I tried with examples here and duplicates. I don't have MSO at the moment to open RT DOCX also there so I didn't set Verified. > The document from comment #15 is still not good when saved as docx & > reloaded. That case should be handled under bug #130446 I wouldn't agree. Bug 130446 didn't have good Description and what was clarified in Comment 6 is OK now, so I duplicated. What I see wrong is general LO behavior, regardless of format. Regression that numbering is not updated on insert in between, until reload. I'll See Also.
(In reply to Timur from comment #71) > Bug looks fixed. I tried with examples here and duplicates. > I don't have MSO at the moment to open RT DOCX also there so I didn't set > Verified. I'm afraid the bug pops up after opening your docx in MSO. That's when troubles start. So opening it in MSO and after that in LO is of paramount importance to make sure bug is gone...
I take it all back! You guys are great! How to determine if bug is gone: 1. Create a document in LO7. Add chapters and subchapters and apply Chapter Numbering. 2. Save document in LO7 as 'Word 2007-365 (.docx)'. 3. Open document in MSO (I used Word 2007 because that version is supported by Wine). Add chapter somewhere in the middle of the doc. Notice that chapter numbering is all right. 4. Now open the document in LO7. Add a chapter again somewhere in the middle. Notice that all chapters and subchapters are re-numbered just fine.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2f9d909a01f90197c3029a446f8aac8135f53f48 tdf#76817 tdf#141966 ooxmlexport: write OutlineRule if not inherited It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.