Issue 120368 - font size with decimal values don't have a consistent approximation
Summary: font size with decimal values don't have a consistent approximation
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: formatting (show other issues)
Version: 3.4.0
Hardware: Mac Mac OS X 10.7
: P3 Normal (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact: caselli.translations
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-25 20:00 UTC by Mohammed Kuranga
Modified: 2016-10-26 18:21 UTC (History)
5 users (show)

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


Attachments
bug replication (646.47 KB, text/plain)
2014-10-08 03:09 UTC, Heli Desai
no flags Details
follow-up tests (866.91 KB, application/pdf)
2016-10-26 17:17 UTC, camelia.chisalita
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Mohammed Kuranga 2012-07-25 20:00:59 UTC
some more information about my computer.
Mac OSX 10.7.4
Processor 2.3 GHz Intel Core i5
Memory $GB 1333 MHz DDR3
Open Office 3.4.0
AOO340ml(Build: 9590) - Rev. 1327774
2012-04-19 03:33:29 (Thu, 19 Apr 2012)
Test: Enter the following numbers 3000, 1,000,000, 1,000, 999.99, 999.9, 999.1. Result: Entering all the numbers listed in the test above, all the numbers bigger 999.9 were automatically changed to 999.9. As for the number 999.1 it was approximated to 999. I decided to play around with the decimal numbers, I entered 999.2 and it was accepted, 999.3 was changed to 999.2, 999.4 was accepted, 999.5 was accepted, 999.6 was changed to 999.5, 999.7 was accepted, 999.8 was changed to 999.7, and finally 999.9 was accepted. The trend seems to be that even numbers after decimal point was accepted if less than 5 and then odd numbers after decimal point were accepted if greater than 5.  Reverse was the case when I used a smaller font size of 10. I can’t understand why that’s the case. This fails the consistency with in product heuristics.
Comment 1 Andrew Dupuis 2012-10-01 01:11:15 UTC
I was able to replicate this bug on my Windows 7 machine, Intel core i7 processor. But I also found that this problem extends to other values beyond the mentioned decimals of 999.

When I was testing this I started by entering 1000 as the font size and it was reduced to 999.9, then I tested each single decimal value of 999.
999.3 was reduced to 999.2
999.6 to 999.5
999.8 to 999.7

After testing these values I decided to test another set of values so I chose 500 as the starting value.
500.3 was reduced to 500.2
500.4 to 500.3
500.8 to 500.7
500.9 to 500.8

Similar results were found with base font sizes as low as 10. 

This shows that setting the font size to a floating point value is imprecise regardless of the base font size. Also certain font sizes that are recognized by the program are not able to be directly entered in the font size field. (500.3)
Comment 2 rcotrina2010 2012-10-03 01:13:01 UTC
I was able to successfully replicate the reported bug. 

My configuration is:
Early-2011 Macbook Pro 13-inch, Mac OS X Mountain Lion 10.8.2, 2.3 GHz Intel Core i5, 8GB DDR3 RAM.
The Apache Open Office version is 3.4.1 Build 9593 Rev. 1372282

The testing procedures were:

1) Started AOO 3.4.1 Writer
2) Opened a new document
3) Started changing values in the font size box using the keyboard.
a) First, I entered the values that the original reporter suggested and noted their outcome alongside (‘=’  meaning it was the same as the entered value)
•	3000 -> 999.9
•	1000000 -> 999.9
•	1000 -> 999.9
•	999.99 -> 999.9
•	999.1 -> 999
•	999.2  =
•	999.3 -> 999.2
•	999.4 =
•	999.5 =
•	999.6 -> 999.5
•	999.7 =
•	999.8 -> 999.7
•	999.9 =
b) Second, I followed the suggestion of the reporter and tried the same procedure with font values smaller than 10
•	Anything smaller than 2 -> 2
•	2 =
•	2.1 -> 2
•	2.2 =
•	2.3 -> 2.2
•	2.4 =
•	2.5 =
•	2.6 -> 2.5
•	2.7 =
•	2.8 -> 2.7
•	2.9 =
c) Third, I decided to do a follow-up test with my own values and followed the same procedure as with the two previous cases
•	100.1 -> 100
•	100.2 -> 100.1
•	100.3 =
•	100.4 =
•	100.5 =
•	100.6 -> 100.5
•	100.7 -> 100.6
•	100.8 =
•	100.9 =

As the results show, some floating-point numbers round differently than others. I initially believed in the mentioned trend for the numbers rounding depending if the number after the decimal point were odd or even. However, my last set of tests showed that a trend between even numbers after the decimal point and less than 5 do not get changed is not consistent. For example 100.2 was changed to 100.1. The same applies to the trend between odd numbers after the decimal point and greater than 5 do not get changed. For example, 100.7 was changed to 100.6.

In addition, I agree with the statement in the initial report that this is a bug because it fails the consistency within product heuristics.
Comment 3 rcotrina2010 2012-10-03 01:29:54 UTC
Another follow-up test I tried was changing the font sizes by selecting text via other way than the font size box in the menu bar. I used the same mentioned steps with the difference that I changed the font sizes with some text selected through:

a)Format -> Character...
b)Right click in the selected text -> Character...

Same results were the outcome of this follow-up test.
Comment 4 Heli Desai 2014-10-08 03:09:47 UTC
Created attachment 84039 [details]
bug replication
Comment 5 camelia.chisalita 2016-10-26 17:15:59 UTC
Follow-up testing was performed for this failure in order to assess its severity, generality and context impact.

The replication report was attached to this comment.
Comment 6 camelia.chisalita 2016-10-26 17:17:29 UTC
Created attachment 85770 [details]
follow-up tests
Comment 7 Keith N. McKenna 2016-10-26 18:21:09 UTC
Marking as confirmed due to multiple conformations on different OS's