Description: When opening attached DOCX file in LibreOffice 5.3.3.2 the list numbers are in italics, when in the original document opened in Microsoft Office the numbers are plain. Steps to Reproduce: 1. Open attached file 2. Check numbers 3. Numbers are rendered italicized Actual Results: List numbers are rendered italicized. Expected Results: List numbers are rendered plain. Reproducible: Always User Profile Reset: No - reported on multiple systems Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Created attachment 134010 [details] File with number incorrectly italicized when opened in LibreOffice 5.3.3.2
Created attachment 134011 [details] PDF showing MS Office rendering list numbers plain while LibreOffice renders them in italics
issue confirmed under Win7 x64 using LibO 5.3.3.2. status NEW
Found in Versie: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28 but not in Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89
bibisect41max points to commit 1c22545edf9085b9f2656ca92781158b6b123db3 Author: Jian Hong Cheng CommitDate: Thu Mar 14 10:08:38 2013 +0100 Fix issue #i119405 [https://bz.apache.org/ooo/show_bug.cgi?id=119405]: Numbering text style changed after importing the *.doc
** 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 repro in Version: 6.2.0.0.alpha1+ Build ID: 6896f39ffd8a6c4b32b8f601a6a93678247456bd CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-11-05_22:40:18 Locale: ru-RU (ru_RU); Calc: threaded
Dear Gabriel Bowater, 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
Repro for DOC in LO 7.0+. No repro if DOC saved in MSO as DOCX.
*** This bug has been marked as a duplicate of bug 79330 ***
This one also has features similar to bug 68988. I think both of these "duplicate" bugs have multiple problems. So let's keep this one out as a unique bug report since it focuses on the italics problem (and the bold numbering of bug 68988's attachment 85272 [details]). I'm guessing the problem is in the addition of //Ensure the default char fmt is initialized for any level of num ruler if no customized attr If I understand that right, he is saying that even if there was no formatting specified, let's create a named character format for it. Well, if there was no special formatting, why do we need a charstyle for it? And where is the italic/bold information coming from that is being placed in this charstyle? Just eliminating this section fixes this bug and causes no unit test failures (but doesn't fix the main issues in the "duplicate" bugs). It also helps NOT spamming the character styles.
If 9037 - italics-in-para-causes-italic-numbered-list.doc is first round-tripped by Word 2003, then it opens up properly. So there might be something a bit wrong or corrupt with this file.
(In reply to Justin L from comment #5) > bibisect41max points to commit 1c22545edf9085b9f2656ca92781158b6b123db3 > Author: Jian Hong Cheng > CommitDate: Thu Mar 14 10:08:38 2013 +0100 > Fix issue #i119405 [https://bz.apache.org/ooo/show_bug.cgi?id=119405]: > Numbering text style changed after importing the *.doc I think the premise of this entire commit is wrong. From what I can see, it is affecting the entire numbering style when one of the paragraphs has CR formatting. Well, that might be fine to affect the numbering for THAT PARAGRAPH based on the CR, but it shouldn't affect the numbering attributes as a whole. Even worse for "9037 - italics-in-para-causes-italic-numbered-list.doc", it appears that the italics definition is coming from "[Option 1: New Zealand Customs Service, paragraphs 2.1 – 2.7]". But this isn't even defined in the CR. And yet it seems to be applying the italics to the character style WW8Num1z0 - and so it affects every numbering on level one. But quite honestly, I can't follow the code at all - even in a debugger. So I have little confidence that I understand what is really happening. But my impression is that this commit is almost entirely wrong, and should be completely reverted (except for the two Ignore functions that are being re-used for layout - which is where this is being handled for DOCX anyway, and possibly even for DOC).
(In reply to Justin L from comment #13) > and possibly even for DOC). Yes, in 2018 Mike K set this compatibility flag for DOC for bug 117923 source/filter/ww8/ww8par.cxx- m_rDoc.getIDocumentSettingAccess().set( DocumentSettingId::APPLY_PARAGRAPH_MARK_FORMAT_TO_NUMBERING, true);
(In reply to Justin L from comment #13) > I think the premise of this entire commit is wrong. From what I can see, it > is affecting the entire numbering style when one of the paragraphs has CR > formatting. Well, that might be fine to affect the numbering for THAT > PARAGRAPH based on the CR, but it shouldn't affect the numbering attributes > as a whole. The guys making that patch knew that. They document in https://bz.apache.org/ooo/show_bug.cgi?id=119405#c11: Negative Impact: Although most common user scenarios can be met by the solution,there are still negative impacts.Because the attributes of paragraph end mark(0x0D) will be set to the character style binding to the given level of a number rule,it will have the global impact..Other paragraphs that are applied with the same number rule's level will also be changed.Please refer to the Test Case 6, the color of the bullet will be changed finally. Generally, MS Word users will have their numbering/bullets the same attributes/style when using the same level's of number rule,correspondingly,the impacted scenarios are rarely.
Created attachment 170372 [details] FillableSAP-Trim.doc: OOo bug that breaks with the revert I reviewed the unit tests in the Apache bugzilla, and C0 and C7 examples are based off of the same document. They both break with the revert. The rest of the documents look fine.
Created attachment 170401 [details] FillableSAP_mosdump.doc: An MSO_dump - turning binary into (semi)readable code <transformed value="Dredging Project\x0DAssessment Techniques Needed for the Dredging Project \x0D"/> What I understood from this is that the carriage return at the end of the problematic paragraph is in the MIDDLE of a character run. (This seems slightly unusually, but definitely NOT uncommon.) This run of characters definitely includes the Bold character attribute.
Created attachment 170405 [details] 108518_numberingTest.doc: hand-made testing doc - last size/colour won. Proposed fixes: -https://gerrit.libreoffice.org/c/core/+/112319 tdf#108518 partial revert tdf#64222 sw: better DOCX im/export And I think waiting until 7.3 will be the actual fix -https://gerrit.libreoffice.org/c/core/+/112320 tdf#108518 revert OOo hack: Fix issue #i119405: Numbering text style
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0a32371cc2f93fad7954e0fe9c48976aae6c5b9f tdf#108518 partial revert tdf#64222 sw: better DOCX im/export 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/343d4d32f00053bd72cfe240125835fe25ce264f tdf#108518 revert OOo hack: Fix issue #i119405: Numbering text style 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.
No backporting please - unless you want to handle the fallout yourself.
(In reply to Justin L from comment #21) > No backporting please - unless you want to handle the fallout yourself. Hi Justin, even no backporting to 7.2 branch? it was created yesterday...
(In reply to Xisco Faulí from comment #22) > (In reply to Justin L from comment #21) > > No backporting please - unless you want to handle the fallout yourself. > > Hi Justin, > even no backporting to 7.2 branch? it was created yesterday... I don't think so . Justin waited for the 7.3 branch point before pushing.. but well answering a question not directed to me.
(In reply to Xisco Faulí from comment #22) > even no backporting to 7.2 branch? it was created yesterday... I know. See Comment 18.
It's ok in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: c703b2d22c3f45825d9c9d790c3b5a4b6f97e776 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: threaded Not italic.