Problem description: I have a calc spreadsheet with the first col formatted as a date (MM/DD/YY). When I enter 3/4/13, just as I press the second / the cell autocorrects to the fraction 3/4 and stays that way when I type in the /13. Steps to reproduce: see above Current behavior: see above Expected behavior: in a date formatted cell it should stay as 3/4/13 and not autocorrect. Operating System: Windows XP Version: 3.6.5.2 release
Can confirm using LibO 4.0.0.3 on Windows XP.
Not a bug, it is long established autocorrect function that replaces characters with their font fraction. Simply enter a Ctl-Z and it will revert to 3/4/ and allow completion of date. Or to remove the feature, open Tools > Autocorrect Options and delete the 1/2, 1/4, 3/4 entries from the replace tab. But this does it for the whole GUI all components. Removing from MAB 3.6 (bug 44446), resolving NOT A BUG
(In reply to comment #2) > Not a bug, it is long established autocorrect function that replaces > characters with their font fraction. In this case it is highly unwelcome, annoying and counterproductive. Note that if one types "= 3/4+2", this autocorrect does not happen, so there clearly is a mechanism to block unwelcome autocorrect. IMHO, autocorrect should just be more "intelligent" and replace by font fractions only if the next character is not a date separator (or a division sign or ...), not only in date-formatted cells, but also e.g. in Writer (one also types dates in Writer). After all, it does not replace "3/4aaaa" bu "¾aaaa" either.
Alternatively, do autocorrect only in string-formatted cells (not default/automatic/standard format)?
(In reply to comment #3) > (In reply to comment #2) > > Not a bug, it is long established autocorrect function that replaces > > characters with their font fraction. > > In this case it is highly unwelcome, annoying and counterproductive. > > Note that if one types "= 3/4+2", this autocorrect does not happen, so there > clearly is a mechanism to block unwelcome autocorrect. > > IMHO, autocorrect should just be more "intelligent" and replace by font > fractions only if the next character is not a date separator (or a division > sign or ...), not only in date-formatted cells, but also e.g. in Writer (one > also types dates in Writer). After all, it does not replace "3/4aaaa" bu > "¾aaaa" either. OK, but it functions and behaves as designed and documented. Agree that autocorrect could be more intelligent, but that it is an enhancment against master--and does not belong as a MAB on the 3.6 branch. It helps no one to pile on enhancements against a branch that is nearing EOL. Again suggest that you now RESOLVE NOT A BUG to close it, and open a new enhancement issue for intelligent fractional text against master.
adjusting version to 3.6.5.2 to match OP
Eike - as our date-format / detection & entry expert - do you have a view ? :-)
(In reply to comment #5) > that is an enhancment against master-- > and does not belong as a MAB on the 3.6 branch. Your position on that is not without merit, although I don't agree with it. > Again suggest that you now RESOLVE NOT A BUG to close it, and open a new > enhancement issue for intelligent fractional text against master. Procedurally, there is no reason to close this just to open an identical issue. If we decide to treat this as an enhancement rather than a bug, we can change the severity of *this* bug/issue to "enhancement".
Hmmm, it was not difficult to find that this bug report is a duplicate of bug 53098, which has been marked as RESOLVED NOTABUG. I think that this bug report should be changed to enhancement with the proposition to avoid autocorrection if something else than space or punctuation is typed just after replaceable fractions (1/2, 3/4, etc.). Best regards. JBF
It seems that the oldest bug report is this one : bug 33899. Best regards. JBF
OK, marking as DUP. Given the amount of duplicates this has, I'd say it is confirmed as "not what people want" by popular vote... *** This bug has been marked as a duplicate of bug 33899 ***
(In reply to comment #7) > Eike - as our date-format / detection & entry expert - do you have a view ? > :-) Yes, see https://bugs.freedesktop.org/show_bug.cgi?id=60151#c3 ;-)