Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||shortcut problem with subscript / superscript in Impress and Writer.|
|Component:||editing||Assignee:||AOO issues mailing list <issues>|
|Status:||UNCONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||flibby05, gladys.copaga, issues|
|Version:||OOo 2.0 Beta||Keywords:||oooqa|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
Description thecounter 2005-03-09 07:44:09 UTC
System: linux redhat9, openoffice 2.0 beta (1.9.79) 1. If I want to subscript or superscript in impress, I right-click on the mouse and look in the menue item "Style". There are no entries for subscript or superscript, as they are in the writer. 2. When I use the keyboard shortcuts as given in the description (Crtl+Shift+B or Crtl+Shift+P) only superscript works correctly (Crtl+Shift+P). Hitting Crtl+Shift+B first gives an underlined capital B which transforms into a nondisplayable character when the next character is entered, i.e. a box appears instead of the B and also the character entered next. 3. Looking to writer, the menu items as described in 1. are there, but the behaviour of the keyboard shortcuts is as in 2. 4. Sub- and superscripting via Format->Character->Position works fine in writer, but in impress it either put all characters in sub- or in superscript depending on what was selected. Even if one selects certain characters with the mouse, to put only these characters to sub- or superscript all other characters are affected. Also copying via the menu does not keep the attribute but leads to an adaption of the positioning of the characters where they have been copied. 5. Copying from writer into a text field of impress works and allows the display of normal sub- and superscripts within text fields.
Comment 1 wolframgarten 2005-03-09 09:18:00 UTC
Comment 2 christian.guenther 2005-03-09 14:59:13 UTC
Please write only 1 bug in 1 issue.
Comment 3 thecounter 2005-03-09 16:42:26 UTC
Sorry, thought the additional information would help. Should I open another issue for the writer bug?
Comment 4 christian.guenther 2005-03-09 17:29:34 UTC
It's ok. I write several issues for the bugs and features in this issue.
Comment 6 christian.guenther 2005-05-02 15:51:07 UTC
You want to rework the dialog. This issue has some good ideas for the new dialog. Please have a look.
Comment 7 matthias.mueller-prove 2005-05-02 16:57:42 UTC
Comment 8 ace_dent 2008-05-16 02:11:49 UTC
OpenOffice.org Issue Tracker - Feedback Request. The Issue you raised is currently 'Unconfirmed' pending review, but has not been updated within the last 3 years. Please consider re-testing with one of the latest versions of OOo, as the problem(s) may have already been addressed. Either use the recent stable version: http://download.openoffice.org/index.html or consider trying the new OOo 3 BETA (still in testing): http://download.openoffice.org/3.0beta/ Please report back the outcome so this Issue may be Closed or Progressed as necessary - otherwise it may be Resolved as Invalid in the future. You may also wish to search for (and note) any duplicates of this Issue that may have advanced further by checking the Issue Tracker: http://www.openoffice.org/issues/query.cgi Many thanks, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html
Comment 9 thecounter 2008-05-16 08:44:48 UTC
Hi, update for version 2.4, running on openSUSE 10.3, x86_64, build 18.104.22.168.7 taken from the openSUSE-openoffice-repository, STABLE version: 1. impress: + sub/superscript work with keyboard-shortcuts ctrl-shft-B / ctrl-shft-P + no entry in the right-click-menu-entry style as available in writer. 2. writer: + now, keyboard-shortcuts ctrl-shft-B / ctrl-shft-P do not work in writer I was no able to test the behaviour within the beta-version of openoffice 3. Now to the question whether to close the issue. The behaviour obviously has transformed in the recent versions of OpenOffice. I didn't keep track of all that and basically used the main-menue point "Format->Character" to change from normal to sub/superscript. This I did, since as a user of an office suite, I appreciate it very much if I can perform standard tasks, which can be done in all applications (like formatting of text), in the same way in all the applications. If a shortcut for such a task is available only in one of them or different in an other application, I will not use them but stick to the way of doing it which is the same for all application. Therefore, a question back: Should this issue be closed and a new one opened which is concerned with the wish to have consistent menue entries and shortcuts in all applications of the openoffice-suite? Best regards, Joachim
Comment 10 matthias.mueller-prove 2009-09-06 06:45:05 UTC
I am no longer officially active in OOo. Please take over.
Comment 11 mjahl 2010-06-06 08:13:43 UTC
I used OpenOffice.org 3.2.0, OOO320m12 (Build: 9483). Windows XP Professional with SP 3. o I was unable to replicate the problems related to sub/superscript using the short cut keys or the menu. o I also did not see any non-displayable or underlined characters while sub/superscripting as was reported in the original report. o I was able to sub/superscript without any problems. However, I was able to replicate the copy problem regardless of whether the menu was used or the short-cut keys “the menu does not keep the attribute but leads to an adaption of the positioning of the characters where they have been copied”. The critical condition, however, appears to be the state of the document into which the text is copied. Test A - Here are the steps I used: 1. Type: ‘E=MC^2’ and then return/new line. With the cursor in the new line, access Format > Character > Position. Note that the new line retains the ‘Superscript’ position. 2. Copy ‘E=MC^2’ to the new line. Anything pasted into the document at this point assimilates the formatting rules in effect (superscript) and the original formatting associated with the copied item is “lost”, so E=MC^2 is rendered as: ^E=MC2 (i.e., all super-scripted) If the user changes the character formatting for the new line to ‘Normal’ prior to pasting the text, it “works” and the pasted text is rendered as: E=MC^2. Test B – Here are the steps I used: 1. Type: ‘^1 This is a footnote.’ (only the '1' is super-scripted) and then return/new line. With the cursor in the new line, access Format > Character > Position. Note that the new line retains the ‘Normal’ position. 2. When I copy the footnote, it is rendered as: ‘1 This is a footnote.’ (All Normal). This seems to indicate that what drives the behavior here is not the sub/superscripting, but the state of the document where the text is pasted. This appears to be a bug, not an enhancement. My argument is based on the following information: o The OO documentation does not directly address the situation except to say that when “Text is selected: Copies the formatting of the last selected character and of the paragraph that contains the character.” I interpret this to mean that the paste behavior is determined by the last selected character. o I looked at Microsoft Word 2003 (11.8313.8221) SP3. It also retains the formatting associated with the last character when going to a new line (Format > Font: Effects). So in the E=MC2 example, the Font Effects indicate superscript. However, Word always retains the copied formatting regardless of the formatting that applies in the area of the document where the text is pasted. That is, when I duplicate my tests from OO in Word, I see: o E=MC2 rendered as E=MC2, and o 1 This is a footnote. rendered as 1 This is a footnote. While the copying of sub/superscripted text seems to work as documented, I think this is a bug for two reasons: 1. As a user, I expect text formatting to be retained when text is copied or cut (that is what ‘Copy’ means, isn’t it?). 2. Other applications (I tried Word) manifest the behavior I was expecting. If I see this application as one of my competitors, I would take this under serious consideration. Based on the observed behavior, the Bug Summary should be changed to “Copied/Cut text loses position formatting on Paste”.
Comment 12 Gladys 2019-11-15 19:34:48 UTC
Created attachment 86762 [details] inconsistency when sub or superscript position is set at the end of the text
Comment 13 Gladys 2019-11-15 19:50:55 UTC
OpenOffice 4.1.7 (build:9800) OS: Windows 10 Enterprise Product: Impress Different bugs were mentioned in this issue, the ones related to 'Impress' product were reviewed in the last OpenOffice version and got the following results: NO LONGER REPRODUCIBLE: ======================= 1. *Only superscript work with keyboard-shortcuts ctrl-shft-B / ctrl-shft-P* This is no longer reproducible because both sub/superscript works fine using the keyboard-shortcuts. 2. *Put all characters in sub- or superscript* This is no longer reproducible since only the selected text is affected with sub/superscript position format REPRODUCIBLE ============= 3. *There is no entry for in the sub/superscript right-click-menu style as available in writer* This is still reproducible but this is already reported (status CONFIRMED): https://bz.apache.org/ooo/show_bug.cgi?id=46563 4. *The menu does not keep the attribute but leads to an adaption of the positioning of the characters where they have been copied* This was isolated by 'mjahl' who suggested the title *Copied/Cut text loses position formatting on Paste* in the previous comment. This is still reproducible only if the last letter is set with either subscript or superscript position format. It can be considered as an inconsistency because it works in different way depending on what position format is set in the last letter, for example: + if sub/superscript position is set at the beginning or in the middle, so that the last letter has a ‘Normal' position format, then after copying and pasting the text, it will keep the original format (respecting all position formats) which is the way the competitors also works and looks good. + But, if sub/superscript position is set at the end, then after copying and pasting the text, the entire text has the last letter position format(it does not respect all position formats). Please, see attachment: attachment 86762 [details] This has been compared against other competitors products like Power Point (Windows) and LibreOffice(Ubuntu) and they keep all position formats (sub/superscript and normal positions) when copying and pasting independently what position format is set at the end of the text. STEPS: ------ 1. Open Impress - Create an empty presentation from 'Presentation Wizard' 2. Type the word 'this' in the 'Content' area 3. Set the superscript position in the first letter 't' - Select 't' - Right click -> Character -> Position -> Superscript - Click 'Ok' button 4. Select the entire word and Copy it (Crtl+c) 5. Put the cursor at the end of the word 6. Press 'Enter' key to be in a new line 7. Paste the word (Ctrl+v) 8. Notice that the entire word is copied and keep the original format (superscript position at the beginning and normal position at the end) 9. Reset the format - Select the entire word - Right click -> Default 10. Set the superscript position in the last letter 's' - Select 's' - Right click -> Character -> Position -> Superscript - Click Ok button 11. Copy the entire word (Crtl+c) 12. Put the cursor at the end of the word 13. Press 'Enter' key to be in a new line 14. Paste the word (Ctrl+v) 15. Notice that the entire word is copied with superscript position I did not find a new issue reported besides here. Please, advice if we need to open a new issue in case it was not reported yet or if the title of this current issue will be updated since keyboard-shortcuts is working fine. Note: It seems that copy/paste functions could have other issues because when copying a text that contains sub/superscript from Writer and pasting this to Impress, the position format is kept just once. If there is no issues reported, a new one will be opened.