Created attachment 97808 [details] shows now the numerals are displayed in word viewer (top) and libO (bottom) I downloaded the .docx file found at < http://download.microsoft.com/documents/rus/microsoft4you/How_to_license_the_operating_system_Windows_8_new.docx > and noticed that the numerals of the number list found on page 2 didnt retain their formatting. The strange thing is that if i save the file as a .odt and then reopen the .odt, the formatting will then be displayed.
Reproducible, tested using Windows 8.1 with LibreOffice Version: 4.3.0.0.alpha1+ Build ID: f4a6837025a293312cbc43b9c527851362f11030 TinderBox: Win-x86@47-TDF, Branch:MASTER, Time: 2014-04-26_09:21:18 There might be some dupes around. Can't find them right now. But lets mark this as NEW right away. Kind regards, Joren
Created attachment 98033 [details] Word 2013 left, LibreOffice right
This report (opening a DOCX) would seem related to bug 49785 (save ODT as DOCX). Opening the document linked in comment 0 under GNU/Linux highlights an improvement in the handling of the second main heading in recent versions: - v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a and v4.2.5.2 Build ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5 both render the problem as shown in attachments. - v4.3.0.2 Build ID: 14ed55896fdfcb93ff437b85c4f3e1923d2b1409 renders the identifier as expected.
Created attachment 102312 [details] 4.2.5 VS 4.3.0 Yes if you take just the numbered list entry 2 on page 6, it looks like its fine in 4.3.0, but if you take the numbered list entry 1 on page 2, you will see it in bold when its not supposed to be. Also noticed that bullet points that were purple in 4.2.5 are now gray in 4.3.0 (bug 80961).
(In reply to comment #4) > but if you take the numbered list entry 1 on page 2, you will > see it in bold when its not supposed to be. Here is a bit more information on this. The XML for list item #1 (page 2) is: <w:p w:rsidR="0054188B" w:rsidRPr="0054188B" w:rsidRDefault="0054188B" w:rsidP="0054188B"> <w:pPr> <w:keepNext/> <w:numPr> <w:ilvl w:val="0"/> <w:numId w:val="16"/> </w:numPr> <w:spacing w:before="480" w:after="160" w:line="420" w:lineRule="exact"/> <w:outlineLvl w:val="0"/> <w:rPr> <w:rFonts w:ascii="Segoe UI Light" w:eastAsia="Times New Roman" w:hAnsi="Segoe UI Light" w:cs="Times New Roman"/> <w:b/> <w:bCs/> <w:color w:val="68217A"/> <w:kern w:val="36"/> <w:sz w:val="36"/> <w:szCs w:val="20"/> <w:lang w:val="ru-RU"/> </w:rPr> </w:pPr> <w:r w:rsidRPr="0054188B"> <w:rPr> <w:rFonts w:ascii="Segoe UI Light" w:eastAsia="Times New Roman" w:hAnsi="Segoe UI Light" w:cs="Times New Roman"/> <w:bCs/> <w:color w:val="68217A"/> <w:kern w:val="36"/> <w:sz w:val="36"/> <w:szCs w:val="20"/> <w:lang w:val="ru-RU"/> </w:rPr> <w:t>Выбор лицензии операционной системы Windows 8</w:t> </w:r> </w:p> The w:b (Bold) element in the first run properties (w:rPr) definition for the paragraph properties (w:pPr) is likely the reason why the identifier in this case is displaying in bold. The w:bCs (Complex Script Bold) elements do not apply as Cyrillic (U+0400-04FF) is in the High ANSI, rather than Complex Script, font group, under OOXML. The next identical-level list item (#2) on page 6 of the document does not have this bold element definition in the XML. The example in ISO/IEC 29500:2012, §17.3.2.7, p.273 tends to indicate that a bold rendering in the case of list item #1 (page 2) is accurate. > Also noticed that bullet points that were purple in 4.2.5 > are now gray in 4.3.0 (bug 80961). This appears to be much the same issue i.e., they are now being rendered as defined in the XML. I will respond separately in that bug. Both these issues appear to illustrate that no currently available version of MS Office is compliant with (i.e., interprets correctly) OOXML Strict. What MS Word renders on screen cannot be taken as "correct". Only what is defined in ISO/IEC 29500 is correct, and even that is open to interpretation.
Jay, it is possible that my prior analysis (comment 5) of the bold list identifier merely indicates why it is now appearing in bold (the <w:b/> element). The underlying reason though may actually be a regression in handling the overriding character style (if there is one) for this identifier, as indicated by Michael Stahl in bug 80961. In this case I can't locate a corresponding character style. Despite what it looks like I am actually trying to help, although I am not always correct. Apologies if this is the case here.
Created attachment 102698 [details] file with bold number list Owen, no need for apologize as we are all trying to make LibO better and sometimes we arent able to fully get our messages across when we type. :) I did some more checking and both Kingsoft Writer and Calligra Words show it in non-bold. I opened the file in word 2013 and selected the number list and added bold to it, which does effect both number list entries, and have attached it. Hopefully this will make it easier to figure out.
(In reply to comment #7) > I opened the file in word 2013 and selected the number list and > added bold to it, which does effect both number list entries, and have > attached it. Hopefully this will make it easier to figure out. Thanks Jay. The key change seems to be this diff in word/numbering.xml: 1378c1378,1379 < <w:b w:val="0"/> --- > <w:b/> > <w:bCs w:val="0"/> Line numbers 1378-79 indicate <w:abstractNum w:abstractNumId="20"> which I believe is a character style, although of a different type?
Created attachment 117135 [details] Sample docx file with numbering displaying differently I don't know if this is the same issue or not, but here is a sample document with numbering that is displayed differently (look especially at font size for last 'A' and 'B'). 'Microsoft Office 2013' on Windows 8 'LibreOffice 4.4.4.3' on Ubuntu 14.04.
Created attachment 117163 [details] Compare LO versions and MS Comparing diff. LO versions and MS I conclude that the original bug reported for LO 4.2.3 (small and black) looked better (was fixed?) in 4.2.6 (proper color and size), like MS, and then it went for worse in 4.3 (black) and even more worse now (black and bold).
** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Still reproducible with: Version: 5.4.0.0.alpha0+ Build ID: a9f56091b6422ec8c42f09b8472200ae4ab12548 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-12-05_23:12:26 Locale: nl-NL (nl_NL); Calc: CL
(In reply to Owen Genat (retired) from comment #5) > <w:numPr> > <w:ilvl w:val="0"/> > <w:numId w:val="16"/> > </w:numPr> This is the numbering properties with a reference to numId=16 (available as WWNum16 list style), which can be found in /word/numbering.xml like so <w:num w:numId="16"> <w:abstractNumId w:val="20" /> </w:num> This references the abstractNumId=20 (available as ListLabel 20 character style), which also can be found numbering.xml like so <w:abstractNum w:abstractNumId="20"> ... <w:lvl w:ilvl="0" w:tplc="0419000F"> <w:start w:val="1" /> <w:numFmt w:val="decimal" /> <w:lvlText w:val="%1." /> <w:lvlJc w:val="left" /> <w:pPr> <w:ind w:left="720" w:hanging="360" /> </w:pPr> <w:rPr> <w:rFonts w:hint="default" /> <w:b w:val="0" /> </w:rPr> </w:lvl> ... </w:abstractNum> And the run properties from here are to overwrite the paragraph run properties below > <w:rPr> > <w:rFonts w:ascii="Segoe UI Light" w:eastAsia="Times New Roman" > w:hAnsi="Segoe UI Light" w:cs="Times New Roman"/> > <w:b/> > <w:bCs/> > <w:color w:val="68217A"/> > <w:kern w:val="36"/> > <w:sz w:val="36"/> > <w:szCs w:val="20"/> > <w:lang w:val="ru-RU"/> > </w:rPr> > </w:pPr> resulting in a combined paragraph/numbering run properties of <w:rPr> <w:rFonts w:hint="default" w:ascii="Segoe UI Light" .../> <w:b w:val="0" /> <w:bCs/> <w:color w:val="68217A"/> <w:kern w:val="36"/> <w:sz w:val="36"/> <w:szCs w:val="20"/> <w:lang w:val="ru-RU"/> </w:rPr> so the numbering should be not-bold and purple, but instead it currently is bold and black. @Justin, @Mike: What are your thoughts on this? Listlabel 20 is correctly pulling in the latin font size (<w:sz>), but doesnt correctly pull in the font color (<w:color>), no-bold (<w:b>) or the font name or size in asian and ctl. @Regina: seems like not having direct formatting that can be applied to different list items/characters means we'll be struggling with the likes of this.
** 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
DOCX looks better now. Test LO 6.2 and 6.4+. I'll close. Chuck's attachment 117135 [details] also opens OK.
Confirmed fixed in 6.4 because of commit 2c0d3ce5292b45a8897758508ee61801e4e8340d Author: Samuel Mehrbrodt Date: Fri Aug 30 15:19:49 2019 +0200 tdf#64222 Consistently apply direct formatting to numbering *** This bug has been marked as a duplicate of bug 64222 ***