When you have a numbered list in Writer that starts with a word in small caps then that small caps formatting also applies to the numbering. This means, for instance, you can't have a small Roman numbering with, say, small caps words like this, (i) GRAMMATICALITY (ii) ASPECT which is just plain illogical and annoying.
Created attachment 57015 [details] test case But my be so should be? Please, see in another offices, how there is this situation. Meanwhile start list items with space and leave this space unformatted.
what kind of a stupid comment is that?? So, I leave a space and then once the bullet point text goes into the next line this destroys the hanging indent!? This is nonsense. In Word, you can double-click on the paragraph mark and format the paragraph separately from the text and don't have to leave a space there that kills the alignment of the indent, and that's how this SHOULD work.
Sorry for stupid comment. Meanwhile try this: To force list to be with specific format in Writer do following: 1. Place mouse cursor on any item and left click it. All items becomes in grey squares 2. Change format of character to desired (for example:font size, bold, italic, red color) 3. If format appears already desired, then change to wrong format and then back to desired (we want font size 12 and it is already 12, then change to 14 and than back to 12) In Impress all list items are independent form each other, so to change format of all list, select explicitly ALL list.
Thanks for the tip. However, it doesn't work on my machine even in your file. For instance, 1 I loaded your test case document; 2 I triple-click into the first line and press CTRL-B to make it all bold; 3 I click once onto the "i." and the grey highlighting appears; 4a What DOES work is then right-click and "Clear direct formatting"; 4b What does NOT work is then changing the format to anything. For instance, when I change the color to green, nothing happens, neither to the numbering nor to the "Asdfz". Strange ...
Thanks for additional testing. It is because used Roman numbers. With Arabic numbers it works. But with Roman numbers not works and even if change to Arabic, it still not works. IMHO it is a bug. When I select list with Roman numbers, change attributes and see on "undo" button, I see that attributes changed. But nothing changed. In msWord 2003 formatting of list works as described in comment 3.
*** Bug 60331 has been marked as a duplicate of this bug. ***
** 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 (4.4.1 or later): 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-07-18
Still repro. Format>>Character>>Tab: Font Effects and under Effects select. Small Capitals Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: fcc2415ade6ae93710bbbda9f7e163045e323105 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-21_16:55:13 Locale: fi-FI (fi_FI)
** 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.2.5 or 5.3.0 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-20170306
Still reproducible. Version: 6.2.0.0.alpha0+ (x64) Build ID: e46f8a9a4e3c5b0542c0813b476b449f3af8d607 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-07_23:36:50 Locale: de-AT (de_AT); Calc: CL The bad thing with this issue is, that you even can't correct the capitalization with a character style that has a font effect 'Without' or 'Lowercase'.
Dear kaesezeh, 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
Seems to be a different rendition of bug 97005, bug 136718, bug 136536, and bug 131785
Note: footnotes have the same problem... I think https://cgit.freedesktop.org/libreoffice/core/commit/?id=478f9ad06412c910d0264f76962a6d5e1a01aaa2 is probably a good code pointer. It added overlines as a similar exception to underlines. But it is a BIG commit, and I don't know for sure if it handled ignoring overlines on numbering right away or if that was added later... If you add this line to txtfld.cxx // i18463: // Underline style of paragraph font should not be considered pNumFnt->SetUnderline( LINESTYLE_NONE ); // Overline style of paragraph font should not be considered pNumFnt->SetOverline( LINESTYLE_NONE ); + pNumFnt->SetCaseMap(SvxCaseMap::NotMapped); then any line with an underline or overline also fixes the case mapping. But what triggers the font to be used (or repainted)???
Sometimes Writer delays loading the document, and then it doesn't convert to smallCaps. But normally you can see it load OK, then within seconds shift to smallCaps. I tried adding SvxCaseMap::NotMapped != GetCaseMap() everywhere I saw a similar comparison to GetOverline() and GetStrikeout(), but that didn't work. I'm lost.
(In reply to kaesezeh from comment #2) > This is nonsense. In Word, you can double-click on the paragraph > mark and format the paragraph Yes - this kind of nonsense in MS Word is exactly why we have this problem in LO. LO thankfully doesn't allow formatting the CR, and so this hacky nonsense needed to be added for interoperability reasons. Unfortunately, MS seems to have made an exception for "small caps". Although the red from the paragraph marker affects the numbering, the small caps property does not. (Tested in MS Word 2010.)
Interesting thing. In SwTextFormatter::NewNumberPortion, if I force changing the color also if (pNumFnt->GetCaseMap() != SvxCaseMap::NotMapped) { pNumFnt->SetCaseMap(SvxCaseMap::NotMapped); pNumFnt->SetColor(COL_GREEN); } then it works, but if I don't set the color, the casemap still displays.
Created attachment 194822 [details] 43767_caseMapNumbering.odt: testing lowercase, Titlecase, UPPERCASE, SmallCaps DOCX round-trip: the MS UI only has checkboxes for "All caps" and "Small caps", so when saving to DOCX the attempt to "lowercase" and "titlecase" are dropped. Interestingly, while MS doesn't mirror "small caps" onto the list number, it does mirror "uppercase".
(In reply to Justin L from comment #16) > if I don't set the color, the casemap still displays. That is because inftxt.cxx SwFontSave doesn't switch fonts because they have the same cacheId when only CaseMap or SuperScript are changed. Sadly, there is no comment saying why SwFontSave should NOT switch to a requested font. The existing comment just states the obvious, and was added when creating yet another exception... commit 221c5dc5269cd480c4d4771e3de13339c47c7ab4 Author: Frank Meies on Tue Jul 17 08:11:33 2001 +0000 Fix #89771#: Attributes for special portions (number, footnote, drop caps) at beginning of paragraph Also sadly there is no SwFont.operator==, or SvxFont.operator==. One would expect those to exist, but no comments saying why they don't. Do we really never compare fonts in writer?
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5c6c6a73e9c58ad934a4f89505d5b3e2b781e0b9 tdf#43767 mso-format layout: no smallcaps applied to numbering It will be available in 25.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.
Comment 19's patch fixes the Microsoft formats. I don't like these adhoc exceptions, so I didn't attempt to apply them to ODF formats. Let's keep it simple for ODF - any char format that applies to the entire paragraph should apply to numbering as well (except for the existing underline/overline exceptions). I'll leave this bug report open to for anyone who disagrees with me and wants their name attached to complicating ODF.