When entering a date in a new cell, autocorrection kicks in and replaces the date with a fraction. For example type "1/2/2011" will replace the "1/2" portion with "½". This was initially reported at the French LibO forum then reproduced on both Windows and Ubuntu by French discuss list members. As a workaround, to go back to the default behavior, go to Tools > Autocorrect options > "Replace" tab and delete the fractions lines (¼, ½, ¾) ( in French it's under Outils > Options d'autocorrection > onglet Remplacer).
Another workaround is to always enter month numbers with two digits.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
*** Bug 37353 has been marked as a duplicate of this bug. ***
*** Bug 44952 has been marked as a duplicate of this bug. ***
Also present in 3.5.4.2 build 350m1(Build:2) - fresh install, first time I used Calc.
confirming the "1/2/2011" --> "½/2011" autocorrection in Calc using LibO 3.6.0.4 on Win Vista 64bit
Check out bug 53858 . It is related to this one
This is NOT a bug. It is a weird collision between Autocorrect and Data Entry. Excel shows the same behavior but has by default not the 1/2, 1/4, 3/4 in its auto correct table (may thats why). What happens is: The parser checks first its replacement table if it can correct something and finds it and does it job fine. Second the parser tries to fit the entered string into the number format but has trouble with the symbols and returns a text string. A few possible workarounds: 1) Disable autocorrect. 2) remove 1/4, 1/2 3/4 from the replacement table 3) enter date digits with leading 0
Can we mark this as RESOLVED? It is not a bug just a colliding between Auto Correction and parser.
+1 to mark this as RESOLVED NOTABUG autocorrections gets triggered after hitting "space" or some particular punctation marks like "." "," and "/" that's why "1/2/2011" gets auto-corrected into "½/2011" after the second "/" if you have a "1/2 -> ½" autocorrect entry. so, again, easiest ways to avoid this is to get rid of those autocorrect fractions entries or to always use 2 digits for day and months in dates. moreover, I don't understand why the summary notes say "regression" did it work differently in any LibO version?
*** Bug 46969 has been marked as a duplicate of this bug. ***
I don't agree to close this as a "not a bug". It is a bug -- or if you'd prefer to call it a feature request. A feature request to make auto-correct more aware of its environment. This specific "collision" is not aware of the scenario in which it's being called. It's only natural that auto-correct should wait for a period, comma, colon, semi-colon or space to be typed after a possible fraction and ONLY THEN auto-convert to fraction. But when you type another slash, why convert it? I don't know of any such case when you would type: "I have 1/2/30 kilograms of apples" -- and properly expect Libre to auto-correct the 1/2 with a fraction. Thank you for your time. -Lee (In reply to comment #10) > +1 to mark this as RESOLVED NOTABUG > > autocorrections gets triggered after hitting "space" or some particular > punctation marks like "." "," and "/" > > that's why "1/2/2011" gets auto-corrected into "½/2011" after the second "/" > if you have a "1/2 -> ½" autocorrect entry. > > so, again, easiest ways to avoid this is to get rid of those autocorrect > fractions entries or to always use 2 digits for day and months in dates. > > moreover, I don't understand why the summary notes say "regression" > did it work differently in any LibO version?
(In reply to comment #12) > I don't agree to close this as a "not a bug". It is a bug -- or if you'd > prefer to call it a feature request. A feature request to make auto-correct > more aware of its environment. > > This specific "collision" is not aware of the scenario in which it's being > called. mmmhhh.... probably you are right. Clearly this is a corner case for autocorrection. We should keep the "/" key as an autocorrect trigger when dealing with letters (i.e. nale/female --> male/female) but probably that trigger should be disabled when dealing with numbers and keep other triggers enabled. i.e. 1/2/ --> 1/2/ (no change) 1/2, --> ½, 1/2. --> ½. 1/2; --> ½; 1/2: --> ½: 1/2[space] --> ½[space] 1/2[enter] --> ½[enter] This the only way I can think to avoid the autocorrect/date collision. I do not know if this is technically feasible. Developer help needed. I cannot tell if this could be an easy hack or an impossible hack.
I checked this out after finding that the problem has not gone away in LO4. ITYF find that most users, when entering a string such as 1/2/2011 will be intending it to be a date. If such a user finds it converted into ½/2011 they would not consider this to have been corrected - just the opposite. This is not autocorrection, it's autocorruption. Sure, there's a workaround - to kill the autocorrection even in those cases where the correction would have been reasonable. But a workaround is all it is, it doesn't mean that the behaviour being worked around isn't a bug. If a program exhibits behaviour which a reasonable user wouldn't expect to be the norm in a common situation then I think it has to be considered to be a bug, albeit, as Tommy says, an awkward corner case. Suggested mitigations: 1. if LO is setting out to be bug-for-bug compatible with Excel do the same as Excel & default the autocorrect table to exclude fractions. 2. if autocorrect has been invoked add a review phase after the next character to see if the autocorrect still looks reasonable and back it out. However, there are clearly 2 parse and reformat operations at work here, one which applies the autocorrect/autocorrupt & one which applies the normal date format check, e.g. expand 1/2/11 to 01/02/2011 and they're invoked in that order. Can this order be reversed?
*** Bug 61903 has been marked as a duplicate of this bug. ***
*** Bug 53098 has been marked as a duplicate of this bug. ***
Adding to MAB 3.6 and marking it an enhancement... To quote Lionel from bug 61903 "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)" Good enough for an enhancement description?
@ V Stuart Foote - It was decided some time ago that enhancement request should not go on MAB
OK, off the MAB. But setting to Highest - Enhancement and poking the Dev list to see if there is any interest in adjusting this feature enhancement or possibly taking it further.
*** Bug 60151 has been marked as a duplicate of this bug. ***
This affects more than dates. Format a column as fraction. Enter 1/2 in one cell. Enter 3/4 in the next row. Sum them in the next row. Expected result is 1 1/4. Actual result is 0. There's also a further date anomoly. One date format is quarters, e.g. 2nd quarter 2012. If you attempt to enter this autocorrupt leaps in after the "d" and converts the "nd" to a single superscript character and the string goes unrecognised as a date. The root of the problem is that there are at least 3 possible data types number, date and text (I don't know the internals - possibly there are more) but data is being treated as one of these, text, before the user has entered sufficient information for the intended data type to be deduced. Premature and irreversible assignment of data type seems to me to be a serious design issue.
So there is a definite bug in cells with Fraction formatting. <CTL>-Z clears the cell rather than reverting the autocorrect. Cell displaying with "Fraction" formatting are entered with a decimal value, or a interger / integer number which is calculated to a decimal value. Either input method is displayed as a fraction. Autocorrect changes integer/integer inputs: 1/4, 1/2, and 3/4 to fractional character--annoying but not incorrect as implemented. The incorrect action is that a <CTL>-Z to revert the autocorrect actually deletes the fractional character. Expected action would be for <CTL>-Z to revert autocorrect to the typed integer/integer, and allow function to calculate decimal needed for display in the fraction formatting.
(In reply to comment #22) > So there is a definite bug in cells with Fraction formatting. <CTL>-Z clears > the cell rather than reverting the autocorrect. IMHO that is a *different* bug. This bug is that autocorrect should not get in the way of data entry by default, that is not be "autocorrupt". It is not a good default expectation that "autocorrect will corrupt your data entry, but you can press CTRl-Z to undo that".
Hmm, possibly. But I think since this is an enhancement, the errant <CTL>-Z action to revert autocorrect in calc ought to be addressed as the whole issue of "intelligent" autocorrection is reviewed. This is what I believe happens with calc: the auto correct occurs in the text input box, the "corrected" text is written to the cell, the revert occurs against write to the cell and deletes it. Since this autocorrect enhancement will require adjustment of the text input logic, function of the <CTL>-Z revert should be adjusted to match at the same time. Eike R. suggests that is probably to be found in EditEngine (see bug 60151#c3).
When you get so many reports describing it as a bug because it did not meet user expectations you should start considering that maybe it really is a bug. The users' view is that the correct key presses to enter a date of 1/2/2012 are 1 / 2 / 2 0 1 2 and not 1 / 2 <Ctrl-Z> / 2 0 1 2 which will (a) slow the user down and (b) result in errors of omission where the user fails to press <Ctrl-Z> and or, when the user becomes thoroughly hapituated, commission where it's pressed for dates such as 1/3/2012. I think it's time to step back, do some proper requirements analysis on this, and then evaluate whether the existing setup meets them and if not replace it with something that does.
I'm removing the word "regression" from the title. as fas as I know this autocorrect/date/fraction collision affects any LibO release from day 1.
In response to comment #8, the workaround (2) suggested is not effective under GNU/Linux TDF/LOv4.0.3.3. If I change the AutoCorrection Replacement Table entry "1/2" with "1|2" in order to allow fractions but via a different key combination, it has no effect on typing "1/2". This value is *still* changed to a fraction. The new combination is changed as well, but the fact that the old combination is also changed points to a deeper issue with this facility (which I believe you indicate - it sounds like it is hardcoded somewhere).
*** Bug 68048 has been marked as a duplicate of this bug. ***
I reproduce the bug on OOo 3.3.0 so issue is inherited from OOo. changed version field.
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
I put Lazlo Nemeth on CC-list since he did some nice job with autocorrection recently and knows the code about that feature. @Lazlo would you please take a look at my idea in Comment 13 ? is it technically feasible or not?
Maybe we should consider test cases & what would be considered acceptable ways of handling. Here's a starter: A spreadsheet describing stock in a warehouse. The columns are (1)product description, (2)put-away date and (3)bin number. Autocorrection is allowed. In column 1 entering '1/2" copper tube' and 'Tube, copper, 1/2"' should be rendered '½" copper tube' and 'Tube, copper, ½"' if autocorrection is turned on or left as is if it's turned off. In column 2 entering '1/2/14' and '1/2/2014' are interpreted as dates according to the rules of the current locale (remember that for some of us this would be the first of February, not the second of January) and date formatting rules set for the column. Column 3 is more problematic '1/2', '1/2/14', '1/2/14/1234' and '1234/1/2/14' could all be valid bin numbers and entered as is. This implies that all interpretation should be able to be turned off on a column (and, by extension, row) basis.
*** Bug 78029 has been marked as a duplicate of this bug. ***
*** Bug 78954 has been marked as a duplicate of this bug. ***
I think there's an elegant workaround to avoid autocorrect interferences while dealing with dates without removing the existent autocorrect entries for fractions. just open the autocorrect replacement table and enter this: replace: ½/.* with: 1/2/ replace: ¼/.* with: 1/4/ replace: ¾/.* with: 3/4/ thanks to the autocorrect wildcard .* (feature available since 4.2.4) if a fraction symbol is followed by a slash it will revert the fraction symbols to numbers preserving the date format (i.e. 1/2/2014 instead of ½/2014) whereas if you digit 1/2 or 1/4 or 3/4 followed by a space the autocorrect will convert simple numbers to fraction (½ , ¼ , ¾) I propose to add those ½/.* autocorrect entries as default entries in next releases in order to avoid the annoying autocorrect replacement that happens while digiting some date in single digit mode. once this has been done we could mark the issue as FIXED. @Lazlo Nemeth I think I've found another useful application of your great wildcard autocorrect feature. what do you think about it? I'd love to hear feedback to other interested users and developers as well.
(In reply to comment #35) > I think there's an elegant workaround to avoid autocorrect interferences > while dealing with dates without removing the existent autocorrect entries > for fractions. > > just open the autocorrect replacement table and enter this: > > replace: ½/.* with: 1/2/ > replace: ¼/.* with: 1/4/ > replace: ¾/.* with: 3/4/ It works but I'm not sure I'd call it elegant. The cell contents first autocorrect to the fraction which is a bit disconcerting & then autocorrect back. As you say, it's a workaround. The real problem is that the autocorrect kicks in too early. I'm trying to understand just what the process is. By comparison with the substitution on dates I'd expect to be able to enter ½inch by typing 1/2inch and likewise ½" but I get exactly what I type. It looks as if it takes more than entering any character after the 2 to throw the autocorrect mechanism into play. There must be a list of terminator characters and only after one of these is entered does autocorrect inspect the string but either a space or a / can act as a terminator. In that case is the / were removed from that list dates could be entered more easily. That leaves the question of whether there are any use cases where / is a valid terminator as those would then be broken.
@Ian yes, the "/" acts as a terminator and triggers autocorrect as already explained in comment 10 it should be kept because if you type words like "balck/white" and you have a "balck -> black" autocorrect entry it will correct the first error, otherwise you should always set an entry with the entire word. the only way to obtain a compromise would be to tweak the code and make the "/" be an autocorrect separator/trigger only for letters and not for numbers but I don't know if it's technically feasible. regarding the 1/2inch example, if you wanna obtain ½inch you have to play with wildcards and add a 1/2* --> ½ replacement as said before my proposal is a workaround which is easy to implement for all those who are experiencing issues with the date/fraction collision. at the moment there's no better solution
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.
(In reply to comment #38) > 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. I agree. Terrific idea. Avoiding AutoCorrect collisions via unlikely entry combinations is the best approach IMO.
Laszlo Nemeth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=10176b1b6f4801d78695451a1eccabf32701e175 fdo#33899 autocorrect: don't replace date parts with fractions The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
According to the several bug reports/suggestions, this bug solved with an exception: autocorrect entries with '/' aren't replaced before /. Thanks for your comments!
nice fix Lazlo, however I still suggest users to adopt 1//2, 1//4, 1//8 autocorrect syntax (see comment 38) to avoid other autocorrect fractions collisions such as those in Bug 71974