Created attachment 159056 [details] Three image captures demonstrating the ellipsis "strangeness". Adding 3 stops (...) followed by a closing quote (single or double) doesn't convert the ... to an ellipsis character as it requires a subsequent space to be typed for the conversion to take place. This requires the user to go through the document manually in order to convert them by adding a space between the ... and quote and then deleting the space afterwards. Also, adding three dots into already existing text doesn't convert them either unless the space is entered. As, in prose, it is common to show a conversation trails off by using ellipsis before a closing quote, it would seem beneficial to me for the conversion to take place when the third . is entered and not wait for the space following, which wouldn't normally be entered in the example I give. Trying to do a search and replace brings up a real problem in that entering ... as the search term and … (the ellipsis) as the replacement results in ...… instead of just … - it adds instead of replacing! Another problem: a lot of the time, when entering the space, Writer will repeat the preceding word along with the ellipsis. Deleting the space removes the unwanted original word with the 3 dots, leaving the text as we want it, e.g. one copy of the word with the ellipsis following. But this extra stage where the preceding word is repeated probably needs investigating as it doesn't feel natural. I have attached an image showing three small screen captures demonstrating the three stages of this happening. The first image capture shows the original state of the text with the text: “Sorry... You The second image capture shows where the space as been entered after the three dots, which results in: “Sorry... “Sorry… You In the image the cursor can be seen after the space following the ellipsis. The third image shows the result of deleting the space, which is: “Sorry… You which is what we are after. However, the presence of the intermediate stage feels far from natural. Note that the "Ellipsis" setting on Tools >> Options >> Language Settings >> English Sentence Checking doesn't appear to affect the above. I hope that all makes sense. Thank you David Viner
There are already two autocorrect entry strings defined to insert the Unicode U+2026 HORIZONTAL ELIPSIS (drawn from the current paragraph's font or fallback). Either of these strings will convert. "..." (this is the .*... AC table entry), ":.:" (this is the "new" emoji entry).
V Stuart Foote I don't understand why you marked this as "Resolved" when your answer has absolutely nothing to do with the problems I reported. Did you even read what I wrote? I am reopening this - please do NOT mark it as resolved again.
No I read exactly what you wrote. Entering either "Some text..." or "Some text:.:" they will both convert by autocorrection to the U+2026 glyph and result in the desired '…"' string. No space, no extract actions--just the default Replacements as defined in the autocorrection tables: .*... :.: You might retest with a default user profile, but the autocorrection entries are already provided.
Hmm, and if your issue actually is the find and replace of three periods that have made it into text (e.g. the autocorrect is disabled) that is done using the Find & Replace <Ctrl>+H dialog with 'Regular expressions' and 'Diacritic' checkboxes enabled. The find pattern to use is: '\.\.\.' and the replacement is the U+2026 glyph '…' You'll have to be more specific as to your issue--I am simply not seeing one with any facet of handling the horizontal ellipsis.
Dear David Viner, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear David Viner, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp