Bug 40319 - Tamil grapheme clusters
Summary: Tamil grapheme clusters
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-23 11:31 UTC by Shriramana Sharma
Modified: 2015-01-29 11:12 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
ODT containing test case (13.06 KB, application/vnd.oasis.opendocument.text)
2012-06-17 20:42 UTC, Shriramana Sharma
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shriramana Sharma 2011-08-23 11:31:12 UTC
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.
Comment 1 Shriramana Sharma 2011-08-25 19:13:07 UTC
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.
Comment 2 Joel Madero 2012-06-15 15:41:01 UTC
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!
Comment 3 Shriramana Sharma 2012-06-17 17:03:28 UTC
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.
Comment 4 Shriramana Sharma 2012-06-17 20:42:26 UTC
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.
Comment 5 QA Administrators 2015-01-05 17:52:39 UTC
** 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
Comment 6 Buovjaga 2015-01-29 11:12:04 UTC
Changing to FIXED per comment 4.