You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openoffice.apache.org by bu...@apache.org on 2015/11/24 22:31:40 UTC
[Issue 126689] New: Bizarre font size input filter behavior
https://bz.apache.org/ooo/show_bug.cgi?id=126689
Issue ID: 126689
Issue Type: DEFECT
Summary: Bizarre font size input filter behavior
Product: Writer
Version: 4.1.1
Hardware: PC
OS: Windows 10
Status: UNCONFIRMED
Severity: Minor
Priority: P5 (lowest)
Component: formatting
Assignee: issues@openoffice.apache.org
Reporter: stross.stephan@gmail.com
Tested on a Windows 10 PC, with 16GB of RAM, and an i7-4712MQ processor @
2.3GHz
Open Office Build Info:
AOO411m6(Build:9775) - Rev. 1617669
2014-08-13 09:06:54 (Mi, 13 Aug 2014)
While testing the class of values that are accepted and rejected by the font
size input filter, I noticed some frankly bewildering behavior from the font
size box.
1. I attempted to input text into the field. It's accepted, and then deleted
and replaced with the previous valid value. I thought to myself "Oh, it deletes
invalid input and replaces it with the last valid input. That's good"
2. I attempted to do mathematical operations within the input box, to see how
it's behavior would be altered. I expected it to perceive it as invalid input,
or to parse and evaluate the expression. What occurred, which I did not expect,
was that all operations were filtered from the input, and then all digits were
appended together and treated as one number. for example, 10*5 is interpreted
as 105, rather than 50, or simply being rejected. Further experimentation shows
that all non-numeric input, except for one decimal point, is filtered from the
input before it's interpreted.
3. I tried one last type of input that I hadn't yet; negative values. When
given any negative values, rather than filtering the negative sign as expected,
and as it did in example #2, it interprets the given value, AS A NEGATIVE
NUMBER, and then restricts it to the minimum font size of 2.
This bug report exists to suggest that a single, simple, and intuitive manner
be adopted for handling all input into the font size field, and other fields
that exhibit this behavior throughout the program, because as it stands, they
appear to have far too many different ways of handling input for something as
simple as a numeric input field. I would propose a simple call to parseFloat,
and if it fails, leave the value as the last valid one, else, make it positive
and set it, as opposed to whatever complicated chain of checks and filtering is
occurring now.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126689] Bizarre font size input filter behavior
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126689
--- Comment #9 from Peter <pe...@apache.org> ---
Actually I forgot about this. :(
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126689] Bizarre font size input filter behavior
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126689
Peter <le...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |leginee@gmail.com
--- Comment #7 from Peter <le...@gmail.com> ---
I would accept this as a bug.
The decimal number change is at least suspicious. I will try and look into
this.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126689] Bizarre font size input filter behavior
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126689
Ayush Jha <ay...@live.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ayush_jha@live.com
--- Comment #1 from Ayush Jha <ay...@live.com> ---
Created attachment 85323
--> https://bz.apache.org/ooo/attachment.cgi?id=85323&action=edit
Test case for text '8k' in Font size
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126689] Bizarre font size input filter behavior
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126689
--- Comment #3 from Ayush Jha <ay...@live.com> ---
Configuration used for Reproducing the bug: Windows 10 64-bit,
Apache Open Office Writer Build AOO420m1(Build:9800) - Rev. 1692551
Rev.1692551
In addition to what the original report mentions, I tried entering an
Alphanumeric entry for the font size, (screenshots for which are attached to
this comment) namely '8k', and the Program rightly truncated the text so as to
only accept '8'.
On the other hand, when I entered an entry in the field such that it starts
with a number and ends with a number, BUT has a character in between, it
rightly truncates the string again, so as to include only the
numerical-portion, e.g for '8k9', '89' is entered as the font size, and rightly
so, as the user's accidental keystrokes may get ignored by the program.
When a float number with a large significant value is entered into the font
size field, it simply rounds it off.
Similar to issue #4279(https://bz.apache.org/ooo/show_bug.cgi?id=4279), if You
enter a percentage value in the field, Writer simply removes the '%' and enters
100pts as the font size. This makes it clear that the font size filter only
accepts absolute values.
Also, in my follow-up tests I noticed that Writer does an unexpected
rounding-off when a float number is entered. E.g: When '25.3' is entered in the
font size filter, it is reduced to '25.2', the same is seen for some other
values like '25.8' getting reduced to '25.7'. What makes this all the more
unusual is the fact that it is observed only for certain values in the 10^-1
decimal place, for instance in this case at (3 * 10^-1) and for (8 * 10^-1).
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126689] Bizarre font size input filter behavior
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126689
Keith N. McKenna <kn...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |knmc@apache.org
Ever confirmed|0 |1
Status|UNCONFIRMED |CONFIRMED
--- Comment #5 from Keith N. McKenna <kn...@apache.org> ---
Marking this confirmed based on the tests by Ayush and Malhabsi2013.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126689] Bizarre font size input filter behavior
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126689
--- Comment #2 from Ayush Jha <ay...@live.com> ---
Created attachment 85324
--> https://bz.apache.org/ooo/attachment.cgi?id=85324&action=edit
Test Case result for entering '8k' as font size
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126689] Bizarre font size input filter behavior
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126689
malhabsi2013 <ma...@my.fit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |malhabsi2013@my.fit.edu
--- Comment #4 from malhabsi2013 <ma...@my.fit.edu> ---
Replicated this bug on a Windows 10 PC.
After reading this report, it seems like the author explains only one error
which is when the user inputs mathematical operations in the font size input
field, it inputs the incorrect value. An example is 5*10 inputs 105.
I did some follow up tests and found out when the user inputs some floating
point numbers such as 28.9 the field automatically changes it to 28.8. This
only happens with some floating point numbers and not all of them.
The impact that this bug produces for the users is very low in my opinion. As
not many users will try to input 5*2 instead of just 10.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126689] Bizarre font size input filter behavior
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126689
Keith N. McKenna <kn...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Latest|--- |4.1.5
Confirmation in| |
--- Comment #8 from Keith N. McKenna <kn...@apache.org> ---
(In reply to Peter from comment #7)
> I would accept this as a bug.
> The decimal number change is at least suspicious. I will try and look into
> this.
Peter were you ever able to follow up on this?
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126689] Bizarre font size input filter behavior
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126689
Cem Kaner <ka...@kaner.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kaner@kaner.com
--- Comment #6 from Cem Kaner <ka...@kaner.com> ---
I think this is the normal behavior of OpenOffice. I prefer the Microsoft
approach (you get a message box, "this is not a valid number") but this class
of issue has appeared in OOo bug reports for years and years and has been
rejected routinely.
The OOo team has to decide what its design rules are (or, actually, I think
they have decided) and deal with this report in a manner consistent with that
decision.
--
You are receiving this mail because:
You are the assignee for the issue.