For information in relation to bug 40292: The following individual characters are considered independent grapheme clusters in Tamil and hence should allow cursor placement immediately before and after them: INDEPENDENT_VOWEL CONSONANT TAMIL AYTAM (VISARGA) The following character sequences are considered independent grapheme clusters in Tamil and hence should allow cursor placement immediately before and after them but not in between: CONSONANT + VOWEL_SIGN CONSONANT + VIRAMA If a font provides the K.SSA ligature for KA + VIRAMA + SSA, then CONSONANT + VIRAMA here, i.e. KA + VIRAMA on its own is *not* a grapheme cluster. In such a case, the following character sequences are considered independent grapheme clusters and hence should allow cursor placement immediately before and after them but not in between, *despite* the above rule about CONSONANT + VIRAMA: KA + VIRAMA + SSA KA + VIRAMA + SSA + VOWEL_SIGN KA + VIRAMA + SSA + VIRAMA If a font *does not provide* a K.SSA ligature, and KA + VIRAMA + SSA is displayed as KA with an overt virama followed by SSA, then the previous rule should apply. (I'm not sure whether you will be able to alter the cursor placement rule based on whether the font provides a ligature or not, but I am giving the native users' perception. Cater to it as best as you can.) The so called TAMIL ANUSVARA is a wrongly encoded character as it is never used and never will be used in Tamil Unicode. Anyhow, as it is a combining mark, one does not expect to place a cursor between it and its base. The general rule is that no cursor placement is allowed in between a combining mark and its base. Please ask if you wish to have more feedback or clarification.
In addition to what has been specified previously, SH.RII is also normally presented as a ligature in Tamil. Note that unlike K.SSA, where all the vowel combinations such as K.SS, K.SSA, K.SSAA, K.SSI, K.SSII, K.SSU etc are presented using the ligature for K.SSA, in the case of SH.R, the ligature is only used for SH.RII and not for SH.R, SH.RA, SH.RAA, SH.RI, SH.RU etc. Again, if a font does not provide the ligature for SH.RII, then the vowelless SH with an explicit virama should be treated as a separate cluster from the RII (as was said in the absence of a ligature for K.SSA in the font). If such font-dependent clustering is not possible, then it should be assumed that K.SS* and SH.RII are rendered as ligatures as most fonts do provide for this and the provision for their absence is largely for academic completeness.
Marking as NEEDINFO, please provide a document with the test cases that you mention. Once you do this we can determine if it is our bug or not. Thanks!
Sorry can you please clarify? This is only an informatory bug report which I filed this bug because Martin Hosken asked me to. The actual bug report is bug #40292. I'll be shortly following up on that.
Created attachment 63151 [details] ODT containing test case FWIW i've attached an ODT containing real words with all the Tamil consonants and the cluster K.SSA in vowelless form. I've however reported on https://bugs.freedesktop.org/show_bug.cgi?id=40292#c7 that this behaviour is now as expected and hence fixed in trunk.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) Thank you for your help! -- The LibreOffice QA Team
Changing to FIXED per comment 4.