Created attachment 71910 [details] Demo document of faulty inheritance. Instructions included. Most of the time, I try to make my styles as ambiguous as possible, and use inheritance to cover the remaining properties, to facilitate potential future editing. (When editing styles, I use the Organizer tab to see what properties are specifically defined for a style, and use the reset/default/standard button on the appropriate property tab to clear those properties I want inherited.) For instance, if I set the default style font, I can then not adjust the font in any other styles and this property will be inherited by child styles. There are, however, some conditions under which this seems not to work properly. The best example I can think of is line indentation and spacing for headers, though this is by no means the only instance. Regardless of what indentation I select for the parent class 'Heading', I find that all the child classes will default to an indentation of 0cm left, 0cm right, and -0.76cm first line for some unknown reason. In addition, if I specify the values for indentation for the child styles, by association(?) the paragraph spacing values are automatically specified (can't remember if they default to 0cm or the inherited values). This means that I cannot specify indentation without also specifying paragraph spacing. The ultimate effect of these two problems is that I cannot define indentation and spacing for headers using the parent 'Heading' Style and expect them to be inherited; I must also enter in the same values for all the child heading styles. This may or may not be related, but I have found that (font) sizes for character styles will always be based off of 12pt when written as percentages (AFAIK), and are not inherited from the parent (paragraph) style. This is not a v4.0.0.0beta1 regression. Win7x64Ult.
To test & explain the character styles bug: Open a new document and type some text. Go to the Styles & Formatting window and modify the Default Style font size to be 16pt. In the Styles and Formatting window, go to Character Styles (second button above the list of styles) and modify the Emphasis character style font size to be 150% (just type 150% into the font size dropdown). Select the line of text you typed in the document, and set it to the Default Style paragraph style. Then set it to the Emphasis character style. From this you would expect that the text become 16pt*150%=24pt. But, as you should have seen in the demo document as well, the resulting font size is 12pt*150%=18pt.
This is a DUPLICATE of bug 54627 > Most of the time, I try to make my styles as ambiguous as possible, and use > inheritance to cover the remaining properties, to facilitate potential > future editing. > (When editing styles, I use the Organizer tab to see what properties are > specifically defined for a style, and use the reset/default/standard button > on the appropriate property tab to clear those properties I want inherited.) > For instance, if I set the default style font, I can then not adjust the > font in any other styles and this property will be inherited by child styles. > There are, however, some conditions under which this seems not to work > properly. > The best example I can think of is line indentation and spacing for headers, > though this is by no means the only instance. > Regardless of what indentation I select for the parent class 'Heading', I > find that all the child classes will default to an indentation of 0cm left, > 0cm right, and -0.76cm first line for some unknown reason. > In addition, if I specify the values for indentation for the child styles, > by association(?) the paragraph spacing values are automatically specified > (can't remember if they default to 0cm or the inherited values). > This means that I cannot specify indentation without also specifying > paragraph spacing. > The ultimate effect of these two problems is that I cannot define > indentation and spacing for headers using the parent 'Heading' Style and > expect them to be inherited; I must also enter in the same values for all > the child heading styles. ---------------------------------------------------------------------------- This is a NEW bug > This may or may not be related, but I have found that (font) sizes for > character styles will always be based off of 12pt when written as > percentages (AFAIK), and are not inherited from the parent (paragraph) style. > > This is not a v4.0.0.0beta1 regression. > Win7x64Ult. I can reproduce under Ubuntu 12.10 and Mac OSX 10.8.2; LibreOffice 3.6.4.3 as well as LibreOffice 4.0.0.0b1. Thanks for reporting.
I have looked at the duplicate bug, and feel I should point out that: -My demo document is not broken and was created in LibreOffice, not OpenOffice -This report is (more) specific as to the conditions under which the problem occurs -This report/document includes specific steps that reliably reproduce the problem(s) -The bugs in this report can be reproduced both in v3.6.4.3 and v4.0.0.0beta1 Therefore I believe that this report should not be resolved in the same manner as its predecessor, bug 54627.
This looks to be a duplicate of bug 58730 which was fixed in 4.0.0 RC2.
There are apparently 3 different issues in this bug (I initially thought they were all one problem): 1. If indentation for a paragraph heading style is specified, spacing values are also automatically specified (and can no longer be inherited). This issue seems to be resolved as of v4.0.0.3, so this may be the duplicate. 2. Indentation for paragraph heading styles does not inherit correctly, it always defaults to .76cm before and -.76cm first line (see demo document). This issue still exists as of v4.0.0.3. 3. Percentage sizes (e.g. 150%) for character styles do not inherit correctly, they are always based off of 12pt (so 150% always produces 18pt font). See first comment for details. This issue still exists as of v4.0.0.3.
Created attachment 94918 [details] Example to generalize in all dialogues concerning formats (char, paragraph, page) Example to generalize in all dialogues concerning formats (char, paragraph, page)
** 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
Confirmed all the behaviors described in attachment 71910 [details], except the last step: "Modify the 'Heading 1' style once more. Observe ('Organizer' tab) that the spacing values have now specified themselves." For me, the spacing values did not become specified. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58 Locale: fi-FI (fi_FI)
(In reply to y3kcjd5 from comment #5) > There are apparently 3 different issues in this bug (I initially thought > they were all one problem): Could you please resolve this issue and make clear separate issues of what is still a problem :) That increases the chance that people will look at it. Thanks a lot for you help! Cor
The paragraph style indentation and character style font size inheritance are still a problem. Win 7 Pro 64-bit Version: 5.2.0.0.alpha1+ Build ID: d848960a3e77a8608a48f3ba394928c955f1e2d9 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-04-25_06:03:51 Locale: fi-FI (fi_FI)
The current state of things is consistent with comment #5. The spacing inheritance getting screwed up (1) is fixed, but the other two problems (2 and 3) are still relevant. In the demo document (1st attachment) the text from "Go to the 'Indents & Spacing' tab and enter '0'" to "Observe ('Organizer' tab) that the spacing values have now specified themselves." is no longer relevant. The rest still is.
** 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
Confirmed consistent with comment #5 and comment #11 as of version 6.4.1.2, Build ID 4d224e95b98b138af42a64d84056446d09082932
Dear y3kcjd5, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to y3kcjd5 from comment #5) > 2. Indentation for paragraph heading styles does not inherit correctly, it > always defaults to .76cm before and -.76cm first line (see demo document). > This issue still exists as of v4.0.0.3. Still reproduced in current trunk build: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e71934471442a8bbba7e661d3ebe5f708627c5d6 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Same in OOo 3.3. > 3. Percentage sizes (e.g. 150%) for character styles do not inherit > correctly, they are always based off of 12pt (so 150% always produces 18pt > font). See first comment for details. This issue still exists as of v4.0.0.3. Tracked in bug 99544.