Created attachment 64769 [details] Test material to reproduce and test the bug Please find attached a ZIP file with requisite test material. I've adapted the Lohit Tamil font (https://fedorahosted.org/lohit/) to Graphite under the name Krishna Tamil. (Note: I removed all OT tables.) I've included the plain TTF without Graphite tables, the GDL and the compiled Gr-Enabled TTF. Please install the Gr-Enabled font and open the ODT. The sample text is very simple. When transliterating other Indic scripts into Tamil, since Tamil does not have the full series of class consonants KA KHA GA GHA NGA etc but only has the first and last members, KA and NGA, one uses 1 2 3 and 4 in either superscript or subscript form for the missing letters. (Actually 1 is rarely seen but is an optional choice sometimes required.) The Unicode Standard recommends the usage of (00B9 and) 00B2 00B3 2074 (and 2081-2084) for the same. The traditional placement of the numerical diacritic is as close to the consonant as possible, but in logical order it has to follow the full CONSONANT + VOWEL_SIGN combination. This means reordering in the cases where there is a vowel sign (or part thereof) to the right of the consonant. I find that in the case of 00B9 00B2 and 00B3, after reordering, the right hand side vowel sign has been gobbled up. This problem is not seen for the 20xx characters. For comparison I've included the output of XeTeX (which uses Gr1) which shows the correct rendering. It is also not a Gr2 bug, since gr2fonttest from graphite 1.1.3 outputs: <quote> $ gr2fonttest -codes font-grenabled.ttf 0b95 0bbe 00b9 Text codes b95 bbe b9 pos gid attach x y ins bw chars Unicode 00 65 -1@0,0 0.0 0.0 1 30 0 0 b95 b95 01 230 -1@0,0 7.7 0.0 1 30 2 2 b9 b9 02 88 -1@0,0 11.3 0.0 1 30 1 1 bbe bbe Advance width = 17.6 Char Unicode Before After 0 0B95 0 0 1 0BBE 2 2 2 00B9 1 1 </quote> showing that the reordering has been done and the second glyph should display. Bug reproducible on LibO 3.5.3 release version on Kubuntu Precise, 3.5.4 on Win XP, and yesterday's daily* of 3.7.0 on Win XP. * = http://dev-builds.libreoffice.org/daily/Win-x86@6/master/2012-07-26_02.09.47/master~2012-07-26_02.09.47_LibO-Dev_3.7.0.0.alpha0_Win_x86_install_en-US.msi
Confirmed, text below identical to what I put on fdo#52575 Changing: Version - 3.6.3.2, I have confirmed that the problem exists at least to this point, probably indefinitely into the past New (Confirmed) Major (prevents entire languages from being used correctly in LibO) High (default for major) This bug really makes it so entire populations cannot use LibreOffice efficiently or effectively. Hopefully someone tackles this one Related: https://bugs.freedesktop.org/show_bug.cgi?id=48303 I closed that one but maybe it should be reopened - need independent confirmation
Bug persists as of LibO 4.1.1.2 installed from DEBs on Kubuntu Precise.
Created attachment 93257 [details] Results of testing on LibO 4.2 release I tested this bug with the same material on the recent LibO 4.2 release. Previously the right-hand vowel sign was disappearing. Now the reordering is simply not happening in the case of sup-1, 2 and 3 whereas it is happening in the case of the other diacritics. Also in the case of sup-1, 2 and 3 there is some additional spacing seen when there is no additional vowel sign. Since the behaviour has changed, should I change the bug summary?
** 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.4.2 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) 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
** 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 (5.1.5 or 5.2.1 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) 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
This is still present Version: 6.4.0.0.alpha1+ Build ID: 80109586e6cb6d3e2e0a53a9079c3125ec9b8368 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Dear Shriramana Sharma, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 176087 [details] current rendering in 7.2.2.2
No change in 7.2.2.2 bug is still there.
The remaining issue is now how we classify the superscript/subscript digits. The superscript 1, 2, and 3 gets classified as Western text, so the Tamil text is split, while the others gets classified as CTL and no splitting happen. This is most likely because they are in different Unicode blocks and for certain Unicode blocks we force them to be classified as Western text.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f348425e0b9187f56370d9b76594872f935b4d8e tdf#52577: Classify superscript numbers in Latin-1 block as ScriptType::WEAK It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/f62355a601e5f67b87e1061a10a4a612a9cdc839 tdf#52577: Classify superscript numbers in Latin-1 block as ScriptType::WEAK It will be available in 7.6.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.