Issue 47781 - inconsistent behaviour in formatting after autoformat
Summary: inconsistent behaviour in formatting after autoformat
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: OOo 2.0.1
Hardware: PC Windows, all
: P4 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: oooqa
Depends on:
Blocks:
 
Reported: 2005-04-20 00:28 UTC by chriscrawford100
Modified: 2013-08-07 14:38 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description chriscrawford100 2005-04-20 00:28:23 UTC
To reproduce:

Create a new Writer doc using all default settings (as of 1.9.79).
Type "1st" - the "st" will change size to a smaller font.
Hit backspace and type a character. - the character will be at the proper size
(12 by default)
Hit backspace again to erase the character.
Type another character. This time the character will be at the tiny font used by
the numeral abbreviation, and will remain at that size. Even manually changing
the font size will not restore the output text to its proper size.
Comment 1 stx123 2005-04-20 09:10:41 UTC
moving to component Word processor...
Comment 2 michael.ruess 2005-04-20 09:21:13 UTC
Reassigned to SBA.
Comment 3 hwoarang 2005-12-09 11:45:14 UTC
easy reproduced with OOo2.0.1rc3 Win98SE.

P2:
    * A critical usability problem;
    * UI responsiveness of a non-essential feature is extremely poor, rendering
the feature unusable;
Comment 4 andreschnabel 2005-12-10 22:02:27 UTC
hwoarang: please don't change the version info. Version should always be set to
the version, where the issue first habe been found.

If it is necessary to inform development, that the issue is still reproducable
in newer builds, please leave a comment.

This one is btw. not a defect, this behaves as designed, but user did
misinterpred the functionality.

Asfter typing 1st, the font size it not changed .. "st" will be tagged as
"position up" (sorry, have no english build here. You can check this in
character format, page 3 (position).

Either remove this option or apply the default formatting (Menu Format - standard)

-> closing as invalid
Comment 5 andreschnabel 2005-12-10 22:02:43 UTC
.
Comment 6 chriscrawford100 2005-12-11 00:14:56 UTC
You're correct that I misinterpreted what the program was doing when a suffix
was added to a numeral. I believed the font size was changing, but I now see
that the position is. I also see that by resetting the formating or going to the
third tab of the Character formatting screen a user can set the position back to
normal.

However there is still a minor defect here. The bug I see is the inconsistency
of behavior. Following the steps in the intial bug report will demonstrate this
inconsistency in the latest version. Just disregard the inaccurate Summary I
entered. If need be I can re-enter the bug with a proper summary.

Keep in mind that I don't consider the changing of font position after a user
types a numeral and a suffix to be a bug itself - I understand that is the
intended functionality.
Comment 7 andreschnabel 2005-12-11 10:01:46 UTC
ok, I see your point and changed the summary.

Something similar happens when typing *abc* -> its changed to bold, next
character would not be bold. 
Remove this character, type anew -> becomes bold.

I set prio to 4, as this seems a minor problem to me (this is common behaviour
at least since 1.1 and I didn't find this reported yet)
Comment 8 jack.warchold 2005-12-22 13:35:17 UTC
reassigned to me to find the proper developer
set target OOo later
Comment 9 jack.warchold 2006-01-31 12:13:06 UTC
reassigend to fme
please take a look on this