Created attachment 120162 [details] Failing document When opening the attached file, "Windows PowerShell Language Specification Version 3.0.docx", The appendix on Grammar has quite different outline labels. === Microsoft Office Word 2007 B. Grammar This appendix contains summaries of the lexical and syntactic grammars found in the main document. B.1 Lexical grammar input: input-elementsopt signature-blockopt input-elements: input-element input-elements input-element input-element: === LibreOffice Writer O. Grammar P. This appendix contains summaries of the lexical and syntactic grammars found in the main document. Q. Lexical grammar R. input: input-elementsopt signature-blockopt S. input-elements: input-element input-elements input-element T. input-element:
Confirmed with v4.4.6.3 under windows 7 x64. Confirmed with v3.3.4 under windows 7 x64. Confirmed with v5.0.3.2 under mint 17.2 x64.
Confirmed with 5.1.4.2 (x64) under Microsoft Windows [Version 10.0.10586]
Created attachment 126453 [details] Failing document - reduced Looks like custom numbering in the multilevel list. Easier to see on the reduced document. Even shorther, it's like this: === Microsoft Word A. Comment-Based Help A.1 Introduction A.2 Help directives A.2.1 .DESCRIPTION ... Section-Break (Next Page) B. Grammar B.1 Lexical grammar C. References === LibreOffice Writer A. Comment-Based Help B. Introduction C. Help directives D. .DESCRIPTION ... Page Break E. Grammar F. Lexical grammar G. References
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still wrong in Version: 6.3.0.0.alpha0+ (x64) Build ID: eca59b6b8a0cf826ac59f77aec9acf045340c23f CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-16_03:48:12 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
Still wrong in: Version: 6.1.4.2 (x64) Build ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group threaded
Paul, thank you for following your bug. But we test with master version from https://dev-builds.libreoffice.org/daily/master/ or using SI-GUI program. Current master is 6.4 and we may use + to indicate it. Repro with 6.4+.
Don't see why it should be a high severity bug. Reported in 2016 and inherit from OOo
Created attachment 154223 [details] Screenshot of the example document in LO 6.4 and Word Still present in Verzió: 6.4.0.0.alpha0+ (x64) Build az.: 4883da6fd25e4645a3b30cb58212a2f666dae75a CPU szálak: 8; OS: Windows 10.0; Felületmegjelenítés: GL; VCL: win; Területi beállítások: hu-HU (hu_HU); Felület nyelve: hu-HU Calc: CL
*** Bug 129531 has been marked as a duplicate of this bug. ***
Szabolcs Toth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/125dd0be473d15681049814c3982f1ae2c66660f tdf#95495 DOCX import: fix inherited list level of custom styles It will be available in 7.0.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.
Verified for DOCX: attachment 120162 [details] and attachment 126453 [details] from this bug attachment 102915 [details] from duplicated bug 129531 attachment 131891 [details] from bug 106541 (that's left for DOC) attachment 106541 from bug 75748 Great this was fixed. Szabolcs, thanks and please always comment on a plan to backport.
(In reply to Timur from comment #12) > Verified for DOCX: > attachment 120162 [details] and attachment 126453 [details] from this bug > attachment 102915 [details] from duplicated bug 129531 > attachment 131891 [details] from bug 106541 (that's left for DOC) > attachment 106541 from bug 75748 > > Great this was fixed. > Szabolcs, thanks and please always comment on a plan to backport. backport? why ?
Thanks a lot Timur. So, to backport or not to backport?
I'd prefer not to backport it. it's not a regression not a highest/high priority bug. Besides, inherit from OOo bug, thus better to wait for next major release and have more time to test it. My 2 cents
Since I asked, and thank you for your inquiry ,here is a response, not insisting on this one, but giving general explanation. My view is that any bug fix should be considered for backport. Best practice is that a developer makes a comment during the initial commit "I will backport to Fresh (and Still)" or "Will not backport (because..)", accessing potential impact. So avoiding questions and discussion. Long-time devs do both regularly. Reason is to have fix sooner, because current version will take a ti to coe to Fresh and a lot of time to come to X.Y.last of Still, which is a preferred version in deployments. And to have more people test Fresh while fix is hot. I don't think that "inherited from OO" is a reason not to do backport or not to consider a bug a bigger deal. I personally much value those, as a big step forward. Anyway, all this is just my opinion. But I think there should be a "backport" link and policy determined by ESC and explained at https://wiki.documentfoundation.org/Development.
Thank you for your thoughts. After considering both of your responses, I consulted my team and we decided to backport the fix. Main reason is: this bug has a few duplicates.
(In reply to Szabolcs Toth from comment #17) > Thank you for your thoughts. > > After considering both of your responses, I consulted my team and we decided > to backport the fix. Main reason is: this bug has a few duplicates. fair enough!
(In reply to Timur from comment #16) > Since I asked, and thank you for your inquiry ,here is a response, not > insisting on this one, but giving general explanation. > > My view is that any bug fix should be considered for backport. > Best practice is that a developer makes a comment during the initial commit > "I will backport to Fresh (and Still)" or "Will not backport (because..)", > accessing potential impact. So avoiding questions and discussion. > Long-time devs do both regularly. > > Reason is to have fix sooner, because current version will take a ti to coe > to Fresh and a lot of time to come to X.Y.last of Still, which is a > preferred version in deployments. I do agree, in fact, I backported most of the the fixes between the branch off and the first RC1. the problem at this point it: we backport it now, it makes it to the next minor release ( 6.4.2 to be released on week 12 ). if the fix caused a regression, it would take at least 1 months ( in the best case scenario ) to be reported, triaged, fixed and backported, which makes it too late to be backported to 6.4.3. Finally, it makes it to 6.4.4 which is already a still version. what happens if the second fix introduced a second regression at this point ? > And to have more people test Fresh while fix is hot. > I don't think that "inherited from OO" is a reason not to do backport or not > to consider a bug a bigger deal. My point was: it's inherit from OOo, any user having this issue has had it for years, I don't think it's a problem for this user to wait a few more months... > I personally much value those, as a big step forward. > > Anyway, all this is just my opinion. > But I think there should be a "backport" link and policy determined by ESC > and explained at https://wiki.documentfoundation.org/Development. Yes, I agree, it should be better explained in the wiki. I can create a draft and then propose it in the ESC meeting
Szabolcs Toth committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/7c339186b4b41ce22229a591cb8fb14ec3120567 tdf#95495 DOCX import: fix inherited list level of custom styles It will be available in 6.4.2. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c50315c55dbb5daf86ccb2a91468c05a53e926e9 tdf#95495 ooxmlexport3: less implementation-specific unit test It will be available in 7.0.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/520de5a4b2a11412a41ad64b65675a9180fb97db tdf#95495 writerfilter: clear obsolete hack It will be available in 7.3.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.