Monday 16 December 2013

The Way We Proceed With Malayalam ..

Well, with the successful releases for Lohit Gujarati & Lohit Devanagari, we have planned to move towards Malayalam . Since the news has been already announced regarding the development plan for Malayalam language, this post is specifically about the minute details that we had considered while starting & developing towards the way.

As we have achieved the basic goals for both Lohit Gujarati & Lohit-Devangari, which were set at the start of project,now we had set the improvement plan for malyalam as well, which involves the following things :
  • Following AGL. [1]
  • Supporting points provided in Unicode chapter 9 for Malayalam script.
  • Feature file separate for flexibility and reusability.
  • Complete cleanup of existing Open type tables
  • Supporting both "mlym" and "mlm2" open type specifications.
  • Thorough testing with Harfbuzz and Uniscribe (WinXp, W7 and W8).  
Present status of Project : 
Inspite of this basic goals ,I would like to depict the exact steps that we followed .

>>  The first task that we have started with Malayalam is to create test-file. This file is specifically for glyph-testing purpose & proper contextualization of glyph as well .
 
>>  The next thing We have moved to, is GSUB Cleanup so that we can start Malayalam development from very initial step while keeping an eye towards the basic moto.
 
>>  The Third task we have completed is about Glyph renaming. This step really helps for writing the GSUB rules, text rendering & glyph positioning sequence as well.
                 For this task i would like to elaborate, as we had previously discussed & concluded , its better to follow AGL. yet fontforge restricts us for lengthy glyph namings , for such glyphs , we had excluded the AGL specification rules.

>>  After the Glyph-renaming task, We had gone through Malayalam Typography specification, & started For OT rule writing task. Presently We are done with basic shaping forms (except for cjct feature)[2].

Upcoming Schedule :
  •  To finish up with the remaining Features in regards to OT rule writing. 
  •  Testing Activity

  you can have the updated project status & activities on Github [3] .so this the agenda that we had planned & following , thereby raising a step towards making the font more efficient, less redundant, & stable. Thanks.

1. https://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification/
2. http://www.microsoft.com/typography/OpenTypeDev/malayalam/intro.htm#features
3. https://github.com/pravins/lohit2/tree/master/malayalam

8 comments:

  1. I’m interested about the lengthy glyphnames issue in FontForge, can you elaborate?

    ReplyDelete
  2. Hi Khaled,
    Thankx for the feedback. For Glyph-naming style presently we have followed :

    >> glyph_components + LANG_tag

    e.g. unicode value U+0D15 --> kamlm

    for conjuncts, the glyph components has been seperated by "_".

    >> component1_component2_component3

    e.g (U+0D15) ka +(U+0D4D) virama + (0D37) ssa i.e. { ക്ഷ } --> renamed as kamlm_viramamlm_ssamlm

    But the next thing that we came across was, there were some glyphs which were exceeding the length above 31 characters. so that was limited by fontforge application as it has 31 character exceeding limit.

    say for e.g. sa_virama_ta_virama_ra {സ്ത്ര } (0D38+0D4D+0D24+0D4D+0D30)

    for this case, if we followed the above syntax, it is exceeding 31 character limit. so for such cases we have removed "mlm" tag. If you can come out with solution for this issue, that is always appreciated .

    ReplyDelete
  3. This seems to be an OpenType/Adobe limitation that FontForge enforces http://partners.adobe.com/public/developer/opentype/index_glyph2.html#4. But I’m confused since you said you are following the AGL, but those names in your example do not follow AGL.

    ReplyDelete
  4. khaled do you means to follow ALG glyphlist.txt (http://kaz.dl.sourceforge.net/project/aglfn.adobe/glyphlist.txt)? little bit elaboration will help on AGL voilation part :)

    ReplyDelete
    Replies
    1. Yes, I mean that.

      First, you should be using aglfn.txt (AGLFN; Adobe Adobe Glyph List For New Fonts) as glyphlist.txt is the legacy glyph list that should not be used for new fonts.

      The algorithm used to reverse map glyph names to Unicode characters is described here http://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification/, and since it is the sole purpose of using AGL, glyph names should follow it. From the spec the glyph name “kamlm_viramamlm_ssamlm” is wrong since neither AGLFN nor AGL has glyphs with the names “kamlm”, “viramamlm” or “ssamlm”, so here names should be constructed from the Unicode values, namely “uni0D15”, “uni0D4D” and “uni0D37”, and the ligature can be named “uni0D15_uni0D4D_uni0D37” or the shorter (but a bit less readable) “uni0D150D4D0D37”.

      Delete
    2. Thanks Khaled for clirifications.

      We had some good discussion about AGL on http://sourceforge.net/adobe/aglfn/discussion/discussion/thread/f212153e/

      1. One of the goal of Lohit2 is to have readable rules in .fea file. uXXXX is not that readable.
      2. while using aglfn.txt we found it is not updated from long time.
      3. Right now we are following AGL syntax i.e.
      A. "_" in glyph name left part and "." in right side "alt"
      B. Ligatures are named with its componants name
      fi is name as "f_i"

      i think Idea proposed by Dave in http://sourceforge.net/adobe/aglfn/discussion/discussion/thread/f212153e/#577e will help to not only Lohit but all fonts following AGL syntax but not names uXXXX.

      Delete
    3. FontForge has an option to rename glyphs at font generation time using a name list, so you can have whatever readable names you like during development and generate AGL-compatible names at build time. I never used that option, though, so no idea how reliable is it, but it is worth considering. In my feature files I always use classes and name them to my liking, so I rarely interact with “raw” glyph names.

      Delete
    4. Thats nice feature of fontforge considering random glyph naming behaviors of font developers. We need to work and improve it in longterm. I will try and give feedback on same.

      Delete