Burmese Text Rendering Issue with Noto Sans Myanmar

[codebit127]

Description:

I'm encountering an issue where certain Burmese strings don't render correctly in go-text/typesetting with Noto Sans Myanmar, though they display perfectly in other programs and with hb-shape. It seems related to glyph reordering or positioning, especially for sequences with pre-base vowels.

Affected Strings:

ရော့ (U+101B U+1031 U+102C U+1037) ရော့စ် (U+101B U+1031 U+102C U+1037 U+1005) ရော့ဘ် (U+101B U+1031 U+102C U+1037 U+1018) ရောင်း (U+101B U+1031 U+102C U+1004 U+103A)

Commonality: All begin with U+101B U+1031 U+102C

Steps to Reproduce:

1. Use go-text/typesetting (v0.2.0) with Noto Sans Myanmar.
2. Shape text with HarfBuzzShaper:

func main() {
   fontFace, faceError := harffont.ParseTTF({path_to_NotoSans-Myanmar_font})
   if faceErr != nil {...}

    hb := harfbuzz.NewBuffer()
    script, parseError := language.ParseScript("Mymr")
    if parseError != nil {...}

    hb.Props.Script = script
    hb.Props.Language = language.Language("MY")
    hb.GuessSegmentProperties()


    hb.AddRunes([]rune("ရော့"), 0, -1)

    hb.Shape(fontFace, []harfbuzz.Feature{})


     for i, g := range hb.Info {
        glyphPos := hb.Pos[i]
        fmt.Printf("Glyph %d, XOffset=%d, YOffset=%d, XAdvance=%d, YAdvance=%d\n",
           g.Glyph, glyphPos.XOffset, glyphPos.YOffset, glyphPos.XAdvance, glyphPos.YAdvance)
    }
}

3. Compare with hb-shape:

using first example text from above

echo "ရော့" | hb-shape --font-file=fonts/Burmese/NotoSansMyanmar-Regular.ttf --script=mymr --language=my --features="+ccmp,+locl,+mark,+mkmk,+abvf,+blwf" --no-glyph-names

output: [372=0+618|31=0+689|368=0+455|378=0@14,0+0]

compared to what I'm gertting from go-text/typesetting shaper:

Glyph 31, XOffset=0, YOffset=0, XAdvance=689, YAdvance=0
Glyph 372, XOffset=0, YOffset=0, XAdvance=618, YAdvance=0
Glyph 368, XOffset=0, YOffset=0, XAdvance=455, YAdvance=0
Glyph 378, XOffset=14, YOffset=0, XAdvance=0, YAdvance=0

The ordering is different and results in the incorrect rendering you can see in the screenshots below

TextEdit using the same font (looks the same in other programs) Using go-text/typesetting

I verified what glyphs we're being used by uploading the font to https://opentype.js.org/glyph-inspector.html

Request

Could you please help investigate this Burmese rendering issue? Any insights, or suggestions to achieve correct glyph reordering and positioning would be greatly appreciated! Thank you!

[whereswaldon]

This line doesn't make sense to me:

shaper := shaping.HarfBuzzShaper{Fonts: []*sfnt.Font{fnt}}

Our shaper does not accept fonts like this. We have never to my knowledge been compatible with fonts opened by the sfnt font parser, but instead we have our own opentype parser. Could you try loading the font data using our font parser?

Also please note that shaping.Input is where you provide a face to use, not the HarfbuzzShaper struct.

Did you, by chance, ask AI to write your reproducer program? It doesn't and cannot compile under any API version we have ever published.

[codebit127]

Apologies, I've updated the issue to be more clear and accurate

[whereswaldon]

I'm afraid that the new code sample is somewhat broken and doesn't compile (even if I substitute the font path). Your issue includes apparent output data from our library (plus some unspecified rendering library), so you must have been able to run the code locally to produce those images. Could you share the exact code that you used to produce the images your bug report includes?

I am doing my best to interpret this issue in good faith, but it is sending up some warning flags about AI generated content. The code sample has not compiled in either revision you have shared. The first revision did not use the real API, while the second uses the real API of our Harfbuzz package (though with some mistakes and impossibilities), but not of HarfbuzzShaper which is what this issue was originally reporting a problem with.

Please update the reproducer code to be a complete, compiling program that includes all of the relevant import statements, and I'll be happy to dig further.

[andydotxyz]

I have used the example string as test and the suggested font and can confirm, thought the render package testing, that the output is still shaped/drawn incorrectly as reported in the original post

[whereswaldon]

Ah, thanks very much @andydotxyz for doing that. It's good to know it reproduces in our render package.

[benoitkugler]

Probably a bug / outdated code in the Harfbuzz port. I'll investigate when I find some free time.

[benoitkugler]

@codebit127 Could you confirm the last commit properly fixes this issue ? Thanks !

[benoitkugler]

I'll close this issue as fixed, feel free to re-open if needed.