Bug 71974 - EDITING: AutoCorrection changes fraction input in Calc
Summary: EDITING: AutoCorrection changes fraction input in Calc
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
: 91363 98431 (view as bug list)
Depends on:
Blocks: AutoCorrect-Complete
  Show dependency treegraph
Reported: 2013-11-25 00:48 UTC by fcannon
Modified: 2021-02-17 04:14 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description fcannon 2013-11-25 00:48:33 UTC
Formatted  a series of cells in A column for fraction.

Entered fraction in cell A1 as 1 1/8, decimal equivalent was displayed.

Entered fraction in cell A2 as 1 1/4, entered fraction was left justified as 1 1/4. Fraction was not recognized.

Please advise ASAP.

Operating System: Windows 7
Version: release
Comment 1 Ady 2013-11-25 02:35:33 UTC
Testing in LO Calc under Windows.

Current behavior:
1_ Select column A.
2_ Format as fraction, "# ?/?" (without quotation marks).
3_ A1: 1 1/8  -> right aligned, displayed as typed in.
4_ A2: 1 1/4  -> left aligned, displayed as fraction.
5_ A3: 1 1/3  -> right aligned, displayed as typed in.

So, there is indeed some inconsistency. Setting as NEW.

6_ B1: =CELL(FORMAT,A1)  -> #NAME?

So LO Calc is not recognizing the CELL() function (this is an additional bug).
Comment 2 Ady 2013-11-25 03:06:27 UTC
> 6_ B1: =CELL(FORMAT,A1)  -> #NAME?
> So LO Calc is not recognizing the CELL() function (this is an additional
> bug).

Sorry, that part is not a bug, as the correct syntax is CELL("FORMAT",A1).

Yet, in the fraction format part, there is indeed a bug as I wrote before.

The cell
A2: 1 1/4
is already formatted as fraction, so it shouldn't be treated as text.

But, the behavior of the rest of the cells seems correct: fractions are displayed as fractions, not with decimals.


May I suggest updating LO and testing again? Please report back your results.
Comment 3 Eike Rathke 2013-11-29 14:19:33 UTC
It's not related to the format, it is AutoCorrection that interferes during input, see also related bug 33899. Contrary to that bug there is no real pattern in this case where it could be distinguished whether correction is wanted or not. Currently the only workaround is to disable the replacement under Tools -> AutoCorrect Options.
Comment 4 tommy27 2014-08-18 13:21:32 UTC
I copy here the same comment I wrote in Bug 33899

the other, maybe more elegant, solution is to modify the autocorrect replacement for fractions like has been done in the french localization.

in the french locale I see 1//2 --> ½ 

rather than 1/2 --> ½ like in other locales (like italian, english, german etc.)

the advantage of an autocorrect replacement such as 1//2 --> ½  
is that you will never have autocorrect collision while writing dates (see also Bug 71974) and you will not need the wildcard workaround I described before.

I think that we should probably make all those special characters autocorrection uniform among the various languages.
Comment 5 tommy27 2014-08-18 13:23:46 UTC
obviously in the current scenario, typing 1/2, 1/8 etc. etc. in a spreadsheet cell would not trigger any unwanted autocorrections and those numbers would be converted as decimal equivalent and not as fractions special characters.
Comment 6 QA Administrators 2015-09-04 02:49:49 UTC Comment hidden (obsolete)
Comment 7 tommy27 2015-09-04 05:29:18 UTC
correct workaround to solve the unwanted autocorrect in Calc is described in comment 4. 

as far as I see in current LibO releases there is still no uniformity in the autocorrect replacements among different languages.

some still use the 1/2 and other 1//2 which causes the collision
Comment 8 tommy27 2015-09-06 08:39:27 UTC
actually the 1/2, 1/4 etc. replacements are available as emojis too in LibO 5.x

i.e.  :1/2:  -->  ½ 

but the non-emoji replacement like  1/2  -->  ½   which are still present in some languagaes will cause this Calc bug

so as said before, it would be better to change the non emoji fraction replacement from the current 1/2 to ½ to the french solution which is 1//2 to ½ 

I'll ping the localization list about this.
Comment 9 Peter Davis 2016-02-03 19:09:46 UTC
LibreOffice Calc on Win 10 Pro 64bit

Cell with format cleared
Entering info into cell mixed text number 1/2 fraction and more text

The last entered text gets forced between the "/" and the "2" 

Specific example:      Year 70 1/2 adder          was to be entered in a cell as a user title for cell next to it. It looks like that in formula bar but is live entered into cell as   Year 70 1/adder2           
No quotes used. It is not used as a Label just text for the user's eye.

While reaffirming this bug before while sending it in, noticed more specifically that if you backspace in the middle of the expression, there is a one to two character difference in the two fields:    Year 70 adder   in formula bar
 is Year 70/adder2    in cell. Notice the blank in one vs /  and 2  in the other.
Seems like some kind of string expression miscalculation.
Comment 10 tommy27 2016-03-05 14:40:28 UTC
*** Bug 98431 has been marked as a duplicate of this bug. ***
Comment 11 tommy27 2016-03-05 14:41:51 UTC
*** Bug 91363 has been marked as a duplicate of this bug. ***
Comment 12 QA Administrators 2017-03-06 16:08:54 UTC Comment hidden (obsolete)
Comment 13 Paolo Benvenuto 2017-03-08 09:43:51 UTC
still present in
Comment 14 QA Administrators 2018-03-09 03:46:22 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2021-02-17 04:14:31 UTC
Dear fcannon,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team