Description: Triple click selects the sentence. Consider a sentence included in guillemets (French angle quotes), a closing guillemet after the full stop (and a non breaking space). Example : « This is a quotation, supposedly in French. » The selection ends at the non breaking space, dropping the guillemet. Steps to Reproduce: 1. Write a sentence ending with full stop. 2. Enclose the sentence (with its full stop) in guillemets (with non breaking spaces between sentence and guillemets). (This obtains in French with default preferences by typing an ordinary double quote.) 3. Triple click in the sentence. Actual Results: The selection includes the first guillemet but stops at the non breaking space after the full stop, leaving the closing guillemet out of the selection. Expected Results: Select the full sentence with its quotations marks, in all languages and varieties of quotations marks and rules and positions relative to the full stop. (Allowing an easy correct copy-paste.) Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info:
Confirmed on Windows 10 Ent 64-bit en-US with recent master/6.3.0 Version: 6.3.0.0.alpha0+ (x64) Build ID: db39336550ff547bcb7ca15793b12291c913ab42 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-29_23:46:36 Locale: en-US (en_US); UI-Language: en-US Calc: CL Behavior as to what ends a sentence is not correct. Two sentences with localize quotations, English with .", French with .»; the sentence in English will select through the " but in French it stops at the . But, easy work around of a <shift>+<Right cursor> to extend the selection after a triple click sentence selection. I don't beleive we use ICU lib for this, so probably need Writer shell/edit engine tweak to accommodate the localizations that close a sentence run.
So, positioned by Writer ViewShell, and then Writer cursor definition for END_SENT [1], with Lang and Locale considered. So guess the break iterator [2] for fr_FR script just does not recognize the guillemet quotation as a valid sentence closing--stopping at the period. These parts of the Writer shell and cursor are ancient, don't know if they can be corrected without major rework. =-refs-= [1] https://opengrok.libreoffice.org/xref/core/sw/source/core/crsr/swcrsr.cxx#1550 [2] https://opengrok.libreoffice.org/xref/core/sw/inc/breakit.hxx#60
Created attachment 151256 [details] sample Writer document sample document, one sentence in en-US, duplicated fr-FR. Selection via "tripple click", or using the newly provided "Select Sentence" UNO command (bug 124552) as menu/button/context menu customized action. Selection of the first sentence in en-US with a closing '"' does include the quotation. But selection of the first sentence in fr-FR with closing '»' will not include the quotation in the selection. Selecting the second sentence will start that sentence selection with the '»' The guillemet -- U+00BB RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK is not recognized as valid punctuation bounding a sentence.
Dear Dominique Meeùs, 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 MassPing-UntouchedBug
I did download the latest proposed and followed the installation instructions, which gives : Version: 7.1.3.2 / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: fr-BE (fr_BE.UTF-8); UI: en-US Calc: threaded There is no change of behavior with this version. The bug I mentioned 2019-05-08 14:53:50 UTC is still unchanged. Using my example from 2019, with no break spaces inside the quotation marks ˘Example : « This is a quotation, supposedly in French. » The selection ends at the non breaking space, dropping the guillemet.” The triple click selection on the quotation ends with the last no break space leaving out the last quotation mark. Using ordinary spaces, the selection ends with the endpoint leaving out the space and the last quotation mark. As V Stuart Foote observed 2019-05-08 23:03:14 UTC (comment 3), the triple click selection of the next sentence includes the closing quotation mark of the preceding sentence. (Same result with no break space or ordinary space.) The bug is linked to the spaces. There is no bug if one does write: «This is a quotation, supposedly in French, but incorrect by the French typographical rules.»