Hi everyone, I use paragraph, character and page styles very often. In the last weeks, I've noticed a strange behaviour. Obviously LibreOffice (3.6.2.2 under Windows 7 Service Pack 1) defines automatically values for character styles. One example: I have the character style "Emphased". Under the "Organizer" tab, you'll find at "Contains" the following information: "bold + bold + bold". When I change the font color, it is added here correcly ("RGB 197, 0, 11 + bold + bold + bold"). When I click on the "Font" tab and change NOTHING (I only open the tab), the font size will be added automatically to "Contains": "RGB 197, 0, 11 + 11pt + bold + 11pt + bold + bold". In consequence, text marked as "Emphased" is always 11 pt, no matter if it's in a normal paragraph, a heading or a footnote. I am not able to delete or to reset the font size informations. In LO 3.3.0 Portable and in LO 3.4.3, this bug doesn't occure. The text is only red and bold, but font size depends on the paragraph style like it should. Have a nice day! Julius
When I change the font size in writer from the default one by changing the size in the size window, it does change the size as I type, but as soon as I use "enter" it turns the size of what I have written into the default size. If I select and then increase the size, it changes the size, but when I use "enter" it deletes! Previous versions did not have that but. Sylvain
Hi, I think I have located the bug. In Tools - Options - LibreOffice Writer - Basic Fonts (Western) I normally have OpenSans with 10.5 pt. By changing the font size to a round number (natural number, positive integer) like 10 pt or 11 pt, the bug disappears. So, it seems that LO doesn't like .5 values. Julius @Sylvain It would be nice a have one bug report for each bug, so please create a new bug report for your specific problem.
I can confirm the bug of Julius. I performed these steps: 1. Open new text document 2. Set option LibreOffice Writer>Basic Fonts (Western)>Default>Size“ to 11pt 3. View preferences of character style Emphasis (Context menu > Modify...), the font size should be 11pt 4. Change character colour of style Emphasis to green, then OK 5. Insert heading with paragraph style „Heading1“, character size is 16.1pt 6. Select a word of the heading 7. Assign character style Emphasis to this word. The character colour changes to green and the style to italic. But the character size is still 16.1pt although the (displayed??) character size of style Emphasis is 11pt. Perform the same steps with character size 10.5pt in step 2. In this case at step 7 the character colour changes to green and the style to italic. So far it is equal. But the character size changes to 10.5pt (!!!). You see the behaviour is different. So one of the cases should be wrong. I tend to the first case, hence when I use this style I expect that the displayed size is also assigned to the selected text. But other users may think different. They may like to use the style Emphasis only to change one characteristic of a character (e. g. change colour to blue) and the other characteristics (e. g. character size) should not be changed. I think Julius expected such a behaviour. A solution for both expectations could be a selection possibility “No Change” for the characteristics of a character style (Size, Font, Style, Font color...). This is probably a major change of the code, but the current implementation could lead to confusion and it is difficult to detect the reason for this confusion (Option “Size of basic font”).
Considering that the described behaviour is (a) new and (b) only occurs when the basic font is not a round number, I think that it's not intended. Anyway, I strongly support your idea of a "no change" value. In CSS, they have an value called "inherit".
The initial description: > When I click on the "Font" tab and change NOTHING (I only > open the tab), the font size will be added automatically to "Contains": "RGB > 197, 0, 11 + 11pt + bold + 11pt + bold + bold". In consequence, text marked > as "Emphased" is always 11 pt, no matter if it's in a normal paragraph, a > heading or a footnote. I am not able to delete or to reset the font size > informations. ... and subsequent additions (e.g., comment #3): 4. Change character colour of style Emphasis to green ... both deal with setting some attribute other than font size and then having the character style override the font size of the paragraph style. Bug 33224 details the same general problem for Asian text. The report here has then been clarified in the comments to indicate a more-specific aspect with the underlying Default Western font size (set via Tools > Options > LibreOffice Writer > Basic Fonts (Western) > Default) further influencing this behaviour i.e., whether this field is an integer value or not. I can only confirm this more-specific aspect here under Ubuntu 10.04 x86_64 using v4.1.4.2 when I modify some other character style property e.g., as indicated in the quoted step (4) from comment #3. Simply setting the underlying Default Western font size to a non-integer value (e.g., 9.5pt, 10.5pt) and applying the Emphasis character style (unmodified) does not change the size of the text it is applied to. Bug 61452 describes a problem with what is displayed in the Contains section of the Organizer tab for a character style i.e., what is presented in the description of this bug. Summary amended for clarity. Platform set to All/All. Importance set to medium. Severity set to normal.
** 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.2 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-05-02
Bug checked again according the procedure of comment 3. Bug still exists in version 4.4.3 with Win7. There is a slight difference in step 5: The character size is 18.2pt. Hint: Before trying to reproduce this bug it may be necessary to reset the properties of the character style 'Emphasis' to standard values.
** 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
Bug still exists in version 5.2.1 with Win7. Bug already exists in version 3.3.0. Hence inherited from OOo.
** 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
I can't reproduce the issue of unwanted font size in character style dialog with Version: 6.2.0.0.alpha0+ (x64) Build ID: 18c5089df091bddeb8c2dc339776671964389040 CPU threads: 8; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-12_23:24:12 Locale: de-AT (de_AT); Calc: CL But another one should test it before closing this bug as WORKSFORME.
Checked bug again according to comment 3. (Win10) Now with versions 6.1.0 and 6.1.1 the behaviour is equal in both cases [Basic Fonts (Western) > Default > Size“ set to 11pt or to 10.5pt]: In both cases the font size is not reduced. The font size retains at 18.2. With version 6.0.6 the difference still exists. So there has been a change between 6.0.6 and 6.1.0. But the general problem, how inherited characteristics should be displayed in style dialogues is not solved with version 6.1.x. It's still not transparent how characteristics get their values if you use styles. Users will still be at least irritated.
(In reply to Harald Koester from comment #12) > Checked bug again according to comment 3. (Win10) Thanks, Harald, for testing. > But the general problem, how inherited characteristics should be displayed > in style dialogues is not solved with version 6.1.x. It's still not > transparent how characteristics get their values if you use styles. Users > will still be at least irritated. This is covered by Bug 88559 - Display of inherited attributes from parent styles in Styles dialog. So I close this as WFM until somebody post the relevant commit.