Thursday, April 25, 2013

Resolved Lohit Oriya rendering issues with Harfbuzz NG

Couple of weeks back got to know there are some combination of Oriya breaking with Harfbuzz. Bug [1] was earlier reported against Zanata but later on with further review understood it is actually font problem.

Cross checking with Windows found those are breaking with Uniscribe as well.

One of that combination was 123 Gsub listed at UTTRS[1]

 ର୍ତ୍ତ  (U+0B30 U+0B4D U+0B24 U+0B4D U+0B24)

Reph was not allowing to form expected ligature

Same way there are some other combination like 52 ( ଞ୍ଜ)

If someone type ି or ୈ,  It was not allowing to form expected ligature.

Fixed these combinations in upstream now.  [2]
Build lohit-oriya-fonts-2.5.3-3.fc18 will be available in tomorrow update-testing repo. [3]


Fedora language testing day is planned on 2013-05-02 [4]


If none more issues get reported during this test day, i will do next release of lohit-oriya that is 2.5.4.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=923215
[2] http://utrrs-testing.rhcloud.com/language/or/gsub            
[3] https://git.fedorahosted.org/cgit/lohit.git/commit/?id=28986ab3956df5cb96c3ec383641f1cb0fa4c04a   
[4] https://admin.fedoraproject.org/updates/lohit-oriya-fonts-2.5.3-3.fc18
[5] https://fedoraproject.org/wiki/Test_Day:2013-05-02_Localization_%28i18n%29




Tuesday, April 23, 2013

My view on Automated_Rendering_Testing idea for GSoc from SMC

Just couple of days someone ask my view on this project. Today got some time to go through it, below are my comments.

Project idea is written her http://wiki.smc.org.in/SoC/2013/Project_ideas#Automated_Rendering_Testing

1. I really like that someone picked this idea for GSoC. This is something we are looking from long time in UTRRS.
    UTRRS has one basic drawback that manual intervention is needed to get actual rendering problem.
    So if some intelligent algorithm program can automatically verify standard images and on the fly generated image from font to be tested and provide comparison that will be simply great.

    When i gone through project title i thought this is going to be happen in this project.

    I am not sure what is exact plan for implementation.

2. It is written in project idea "One method to do this might be to check the order of glyphs/glyph index output by the rendering engine - this depends on the font too."

   Actually in Harfbuzz we are already doing this thing with scripting.  Behdad has implemented best testing suite for testing rendering of complex script. It happnes following way.

  Script first passes particular word and font to be tested to Uniscribe. It returns some glyphs id's/hex values in fonts.

  Then script passes same word and font to Harfbuzz. It also returns some glyphs id/hex values in fonts.

   Assuming fonts works 100% perfect in Uniscribe and considering it as a standard output. If harfbuzz output (hex values) matches with uniscribe (hex values) it means it is rendering perfect else test fails.

  With this method in harfbuzz we already automatically testing millions of words.

3. In my humble opinion this project should be plan with my first point. I do agree it is tough and might be bit research kind but i think that is the right way. Harfbuzz is already doing automates rendering testing by passing values to unscribe and other open type layout engines.