Issue 44551 - shortcut problem with subscript / superscript in Impress and Writer.
Summary: shortcut problem with subscript / superscript in Impress and Writer.
Status: UNCONFIRMED
Alias: None
Product: Impress
Classification: Application
Component: editing (show other issues)
Version: OOo 2.0 Beta
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: oooqa
Depends on:
Blocks:
 
Reported: 2005-03-09 07:44 UTC by thecounter
Modified: 2019-11-15 19:50 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
inconsistency when sub or superscript position is set at the end of the text (63.58 KB, image/png)
2019-11-15 19:34 UTC, Gladys
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
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
Reassigned.
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 5 flibby05 2005-04-03 20:38:29 UTC
point 1: new issue filed, issue number is issue 46563
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
edit summary
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 2.4.0.3.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.