Sinhala: Above base Matra positioning not proper

[Amritasingh0512]

Font used: Iskool Pota
Unicode value: ර්‍ය්‍ය
Text: ර්‍ය්‍ය

[ebraminio]

The difference existence is confirmed,

$ build/util/hb-shape iskpota.ttf -u U+0DBB,U+0DCA,U+200D,U+0DBA,U+0DCA,U+200D,U+0DBA --shaper=ot

[gid596=0+1343|gid597=0+1130]
(similar to right)

$ build/util/hb-shape iskpota.ttf -u U+0DBB,U+0DCA,U+200D,U+0DBA,U+0DCA,U+200D,U+0DBA --shaper=coretext

[gid736=3+1343|gid600=3+1130]
(similar to left)

$ WINEDLLOVERRIDES="usp10=n" wine winbuild/util/hb-shape.exe iskpota.ttf -u U+0DBB,U+0DCA,U+200D,U+0DBA,U+0DCA,U+200D,U+0DBA --shaper=uniscribe

[gid596=0+1343|gid768=4+1217|gid597=4+1130]

(hmm, diacritic circle, I should see why but probably it is similar to coretext, or maybe not)

Update: Something like this fixes the issue but broke some more tests which show isn't a fix anyway but the place related to this,

index 32ad86a..e397d24 100644
--- a/src/hb-ot-shape-complex-indic.cc
+++ b/src/hb-ot-shape-complex-indic.cc
@@ -740,7 +740,8 @@ initial_reordering_consonant_syllable (const hb_ot_shape_plan_t *plan,
       if (is_consonant (info[i]))
       {
        for (unsigned int j = last + 1; j < i; j++)
-         if (info[j].indic_position() < POS_SMVD)
+         if (info[j].indic_position() < POS_SMVD &&
+             (info[j].indic_position() != POS_BASE_C))
            info[j].indic_position() = info[i].indic_position();
        last = i;
       } else if (info[I].indic_category() == OT_M)

[cjchapman]

The characters \u0DBB\u0DCA\u200D (i.e. the first three characters of the source text of this issue) are used to form the Sinhala repaya, which is similar to a Devanagari reph. Unlike the Devanagari reph, the Sinhala repaya is no longer used in Standard Sinhala.

An Introduction to UNICODE for Sinhala Characters by Samaranayake, et al. notes that:

The “REPAYA” (ර්‍) while no longer used in standard Sinhala (and thus not included in the chart table, can be coded as the sequence “ර + ් + ZWJ” when
required.

(The newer text linked above has some missing glyph images. There is an older, scanned version in which the repaya is represented more clearly here).

This topic of how repaya should be rendered is explored further in Noto Fonts issue notofonts/sinhala#4, in which Pathum Egodawatta (pathumego) from Sri Lanka notes that:

Unlike Rakaransaya and Yansaya, Repaya is not in common use anymore, you wouldn't see it in literature and common use.

[behdad]

Our behavior matches Windows 7. Looks like Windows 10 changed behavior, probably as part of routing Sinhala through USE. Investigating.

[behdad]

FWIW, this is the easy fix in the Indic shaper:

diff --git a/src/hb-ot-shape-complex-indic.cc b/src/hb-ot-shape-complex-indic.cc
index f08876b8..447e36cc 100644
--- a/src/hb-ot-shape-complex-indic.cc
+++ b/src/hb-ot-shape-complex-indic.cc
@@ -86,7 +86,7 @@ static const indic_config_t indic_configs[] =
   {HB_SCRIPT_KANNADA,  true, 0x0CCDu,BASE_POS_LAST, REPH_POS_AFTER_POST, REPH_MODE_IMPLICIT, BLWF_MODE_POST_ONLY},
   {HB_SCRIPT_MALAYALAM,        true, 0x0D4Du,BASE_POS_LAST, REPH_POS_AFTER_MAIN, REPH_MODE_LOG_REPHA,BLWF_MODE_PRE_AND_POST},
   {HB_SCRIPT_SINHALA,  false,0x0DCAu,BASE_POS_LAST_SINHALA,
-                                                    REPH_POS_AFTER_MAIN, REPH_MODE_EXPLICIT, BLWF_MODE_PRE_AND_POST},
+                                                    REPH_POS_AFTER_POST, REPH_MODE_EXPLICIT, BLWF_MODE_PRE_AND_POST},
 };
 
 

[JelleBosmaMT]

Stumbled across this issue checking if there are new issues for Noto Sinhala. Although this is closed, permit me a comment:

The sequence Ra Virama ZWJ Ra is ambiguous, because Ra Virama ZWJ leads to reph form and Virama ZWJ Ra is for the below base form of Ra. But in this particular sequence, we want neither.
I did have a pres lookup which changes Ra Reph into Ra Virama Ra, with a multiple substitution. This solved it in the past and still solves it when testing with Safari and Edge browsers. But not in the latest Chrome. Here the Reph will be re-positioned after vowels, if present. Rephs are not supposed to be used with vowel signs, but here we should not have a reph anyway.
I managed a work around to add a context rule to the akhn feature.

The easiest solution was a ligature lookup to replace ZWJ Ra by Ra. But in Edge the Ra disappeared altogether.
Of course I can also make a ligature Rahalant from Ra Virama ZWJ. But that gets reordered by Harfbuzz as if it is the reph. To prevent that a multiple lookup to split up the Rahalant.

Unfortunately this doesn't fix the case with split-vowels. In these cases the re-ordered vowel must be in front of the second Ra, when the akhn feature is applied. I am not trying to fix that. At least the reph is in a position where it is not obscured by an ascender and it is very unlike not a real world case.

[behdad]

Jelle, please file a new issue for any behavior difference you observe between HarfBuzz and Edge / Windows 10+. Thanks.