When the 'Subscript' and 'Superscript' buttons are displayed in the 'Text Formatting' toolbar, they create a different subscript and superscript size than the RadioButtons in Format>Character>Position. Steps to reproduce: - In Draw or Impress, start editing some text (select the text tool or click into a field like 'Click to add Title in Impress). In the Text Formatting toolbar appearing now, if the 'Subscript and 'Superscript' buttons are not displayed already, enable or add them (from category 'Format'). - In Draw or Impress, write new text such as 'E=mc2 H2O'. Select the first '2', and, using the RadioButtons in Format>Character>Position, format it as superscript. Do the same for the second '2', as a subscript. - Write the same text again and format the subscripts and superscripts with the buttons from the Text Formatting toolbar. Result: Inconsistent subscript and superscript sizes: Superscript created from Format>Character dialog has 70% size, created via the toolbar it has 58% size (checked by selecting the subscript and opening the Format>Character>Position dialog). Subscript sizes are 66% (Format Character) and 58% (toolbar). It looks awful when text like a2+b2=c2 (all '2' subscript) was formatted partly form the dialog, partly with the toolbar. What should be done: The same subscript and superscript sizes should be used everywhere. LibreOffice Writer uses 58% consistently. I'd prefer 66% or an item in the Preferences where I can set this value because 58% is too small. [Microsoft Word has had a preferences checkbox for larger subscripts/superscripts several years ago after switching to smaller subscripts/superscripts. My current version of Word uses 66% size for sub- and superscripts and does not have such an option in the preferences any more]. Possibly related issue: Bug 63082, subscript and superscript size incorrect after copy&paste https://www.libreoffice.org/bugzilla/show_bug.cgi?63082
Created attachment 77385 [details] Sample Document with screenshot Effect is [Reproducible] with "LibreOffice 3.6.6.1 " German UI/ German Locale [Build-ID: 5b93205] {pull date 2013-03-19} on German WIN7 Home Premium (64bit). Might be related to unchecked / checked "Auto" and probably other reasons, I will have to think about that.
I confirm issue on 4.1.1.2 under Win7 64bit. it's inherited from OOo, affects any LibO release and is still present in AOO as well. as Reiner already noted, the different size problem shows up only when the "Auto" checkbox is flagged. if you unflag it the subscript will have the same size as those added from the toolbar button. as Anastasius pointed out, Writer is not affected by this bug. only Draw and Impress are.
** 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-04-01
Still reproduced. Win 7 Pro 64-bit Version: 5.0.0.0.alpha0+ (x64) Build ID: 211c12b9c64facd1c12f637a5229bd6a6feb032a TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-18_01:51:17 Locale: fi_FI
http://pix.toile-libre.org/upload/original/1457644346.png
Me too. I confirm that in Impress, using ctrl-shift-B to set subscripts, one gets a very different subscript format to when one uses the same ctrl-shift-B in Writer. This is very bad, and there seems to be no current way to change settings/preferences/styles to fix 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
still repro in Версия: 6.2.0.0.beta1 ID сборки: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18 Потоков ЦП: 4; ОС:Windows 6.1; Отрисовка ИП: по умолчанию; VCL: win; Локаль: ru-RU (ru_RU); UI-Language: ru-RU Calc: threaded
It isn't fair to compare Format-Character menu with a toolbar button. The toolbar does everything without user interaction, while format-character menu simply opens up a dialog that the user has to agree with all of the settings. Format-character REMEMBERS the last settings that YOU ENTERED into that field. That is why you see a difference. On a clean user profile, Format-Character will use DFLT_ESC_PROP which is 58% There are a few enhancement requests here that could be valid, but specifically for the issue raised in comment 0 I would consider this NOTABUG. There are many bugs with AUTO subscripts in editeng(Draw/Writer textboxes) that I hope are being resolved via bug 80194. Once that is settled, I'll probably propose that the toolbar buttons will turn on automatic mode so that it is consistent with Writer, Format-Characters, and user-expectations. See https://gerrit.libreoffice.org/c/core/+/88998
Dear Anastasius, 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
Consistent between two methods now in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 61b41646c5a93ca24f2c9f143cdb0da2c9258989 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded This is since version 7.0. As suspected, Justin's work for bug 80194 fixed it. Fix bibisected in linux-64-7.0 repo to first _good_ commit 6b2440f6b652f16b3f46483c6b54efe7fed0e9be which points to: commit 2940d1905b921d9909b08b1e32014d3c44474ef0 author Justin Luth <justin_luth@sil.org> Mon Feb 17 20:20:31 2020 +0300 committer Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tue Mar 03 16:20:03 2020 +0100 tdf#80194 editeng: fix auto subscript calculations Thanks all!