Thai rendering regression after harfbuzz-ng

[Theppitak Karoonboonyanan]

Hi,

As described in Bug #595539, there is a serious regression in
rendering Thai with OT font using Pango master. The bug is
very obvious to users, as it changes meanings of words.
And it should not be exposed to users at all in stable release.

I need some help in tracking down the problem.

The GSUB rule input holds input[1..count-1] in the array,
with input[0] skipped. And match_input() matches only
count-1 items. So, where is input[0] matched?

Is there any other hint?

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

[Behdad Esfahbod-3]

On 09/19/2009 10:31 AM, Theppitak Karoonboonyanan wrote:
> Hi,
>
> As described in Bug #595539, there is a serious regression in
> rendering Thai with OT font using Pango master. The bug is
> very obvious to users, as it changes meanings of words.
> And it should not be exposed to users at all in stable release.
>
> I need some help in tracking down the problem.

Interesting.  In general the new code is much more robust, so I'm surprised.

> The GSUB rule input holds input[1..count-1] in the array,
> with input[0] skipped. And match_input() matches only
> count-1 items. So, where is input[0] matched?

input[0] is matched by callers of match_input.

> Is there any other hint?

I'm off to a cycling trip to Niagara Falls in a couple hours.  Will debug this
tomorrow or Monday before the release.  Just give me the font.

In the mean time, you can compile pango with CPPFLAGS=-DHB_DEBUG=100 and check
the log to see what's going on.

behdad

> Regards,
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

[Theppitak Karoonboonyanan]

On Sat, Sep 19, 2009 at 9:33 PM, Behdad Esfahbod <behdad@...> wrote:

> input[0] is matched by callers of match_input.

Well, I didn't find this. But I'll try it again.

> I'm off to a cycling trip to Niagara Falls in a couple hours.  Will debug
> this tomorrow or Monday before the release.  Just give me the font.

Please find the font in the bug attachment:

  https://bugzilla.gnome.org/attachment.cgi?id=143418

Sample text is also provided there:

  https://bugzilla.gnome.org/attachment.cgi?id=143417

> In the mean time, you can compile pango with CPPFLAGS=-DHB_DEBUG=100 and
> check the log to see what's going on.

OK. Thanks.

--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

[Theppitak Karoonboonyanan]

On Sat, Sep 19, 2009 at 9:44 PM, Theppitak Karoonboonyanan
<thep@...> wrote:
> On Sat, Sep 19, 2009 at 9:33 PM, Behdad Esfahbod <behdad@...> wrote:
>
>> In the mean time, you can compile pango with CPPFLAGS=-DHB_DEBUG=100 and
>> check the log to see what's going on.
>
> OK. Thanks.

I can't find what the problem really is yet. But please see
the last clue I got in comment #9 in the bug:

  https://bugzilla.gnome.org/show_bug.cgi?id=595539#c9

I've tried debugging further by inserting fprintf() here and there,
but I can't really grab HB mechanism yet.

The code points passed to match_{backtrack,input,lookahead}()
are not Unicode, but some 8-bit codes, but the glyph classes
can be evaluated from that.

And in a rule that should match input glyph with class 2 as
the final item appears to match with class 0 instead. If I prevent
class 0 from being matched at all, it works! But this is too
hacky, though.

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

[Theppitak Karoonboonyanan]

On Mon, Sep 21, 2009 at 10:19 AM, Theppitak Karoonboonyanan
<thep@...> wrote:

> The code points passed to match_{backtrack,input,lookahead}()
> are not Unicode, but some 8-bit codes, but the glyph classes
> can be evaluated from that.
>
> And in a rule that should match input glyph with class 2 as
> the final item appears to match with class 0 instead. If I prevent
> class 0 from being matched at all, it works! But this is too
> hacky, though.

Update: I've found the causes and have completed the patch
to fix the regressions. Please review it from the bug:

  https://bugzilla.gnome.org/show_bug.cgi?id=595539

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

[Behdad Esfahbod-3]

On 09/21/2009 08:00 AM, Theppitak Karoonboonyanan wrote:

> On Mon, Sep 21, 2009 at 10:19 AM, Theppitak Karoonboonyanan
> <thep@...>  wrote:
>
>> The code points passed to match_{backtrack,input,lookahead}()
>> are not Unicode, but some 8-bit codes, but the glyph classes
>> can be evaluated from that.
>>
>> And in a rule that should match input glyph with class 2 as
>> the final item appears to match with class 0 instead. If I prevent
>> class 0 from being matched at all, it works! But this is too
>> hacky, though.
>
> Update: I've found the causes and have completed the patch
> to fix the regressions. Please review it from the bug:

Thanks, looks good.  I'll request freeze break and apply it before releasing
1.26.0 today.

behdad

>    https://bugzilla.gnome.org/show_bug.cgi?id=595539
>
> Regards,
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list