HELP Needed for Arabic Font in Ijam (Dots) Placement

Zuhair Albazi's picture

Hello Typophyles!

I Am currently working on an Arabic Font. I want to know is it possible in Microsoft Volt (preferably) or in FontLab to use the same glyph for alternate Ijam (Dots) placement? I have attached an Image explaining my query.

For example I made a ligature in the font as the one on the right side of the image "hahhahisolated". Then I have to make eight more glyphs with the same shape but only Ijam (Dots) difference as shown in the Image. So In the font I have to assign the same shape to nine glyphs instead of one. As a result the number of glyphs increases too much in the font while I want to keep them less. How can I use only one glyph with Ijam variation on the same glyph in Microsoft Volt? If it is not possible in Volt than how can I do it in FontLab?

Please Help me.............

Khaled Hosny's picture

In my Amiri font I used to have dots separated from base of the glyph, the idea is simple:

* first you have a ccmp feature that decomposes the glyphs, something like (using feature file syntax):

feature ccmp {
  sub haa  by haa.base;
  sub khaa by haa.base dot.above;
  sub jeem by haa.base dot.below;
  ...
} ccmp;

Where haa.base is the dotless glyph, and dot.above and dot.below are zerowidth glyphs with mark glyph class.

* from now on all glyph substitution is done on base glyphs, e.g.:

feature init {
 lookupflag IgnoreMarks;
  sub haa.base by haa.base.init;
  ...
} init;

feature liga {
 lookupflag IgnoreMarks;
  sub haa.base.init haa.base.fina by haahaa.isol.liga;
  ...
} liga;

The IgnoreMarks flag is very important, else the dots will interfere with the substitution.

* lastly, you use anchor marks for placing dots just like tashkil marks.

* some characters have different dot placement depending on their form, e.g. farsi yeh have dots only in final/isolated forms, for these characters you are better doing decomposition in init, medi etc. features, e.g.:

feature init {
  sub farsiyeh by yeh.base.init twodots.below;
  ...
} init;

feature fina {
  sub farsiyeh by yeh.base.fina;
  ...
} fina;

However, this has some side effects, e.g. sometimes you need different kerning for glyphs with dots below than glyphs with dots above, sometimes certain dotted combinations don't go well together and you need to avoid ligatures in these combinations and this becomes tricky because the dots are treated as combining marks so you can't use them as context until you remove the IgnoreMarks flag and I ended up abandoning the idea.

* A different strategy to decrease the number of glyphs is to avoid ligatures at all and use contextual forms instead. e.g. instead of the haahaa ligature above you "cut" the ligature into two parts:

@clsHaaInit = [haa.init khaa.init jeem.init ...];
@clsHaaFina = [haa.fina khaa.fina jeem.fina ...];
@clsHaaInit.HaaHaa = [haa.init.haahaa khaa.init.haahaa jeem.init.haahaa ...];
@clsHaaFina.HaaHaa = [haa.fina.haahaa khaa.fina.haahaa jeem.fina.haahaa ...];

lookup haahaa.isol {
  sub @clsHaaInit by @clsHaaInit.HaaHaa;
  sub @clsHaaFina by @clsHaaFina.HaaHaa;
} hhaahaa.isol;

feature calt {
  sub @clsHaaInit' lookup haahaa.isol @clsHaaFina' lookup haahaa.isol;
} calt;

Since we have 15 haa-like characters in Unicode, this cuts the number of glyph needed for this ligature from 15×15=225 (number of all possible combinations) to 15+15=30 (number of components).

(PS. the names used above are arbitrary, you can use whatever glyph names you like).

John Hudson's picture

Yes, this is possible, as Khaled describes. One thing to consider, though, is that this will break with Microsoft Office's options to display marks in different colours or not to display marks, since it has no way to distinguish dots treated in this way from other marks. This shouldn't necessarily stop you from doing this approach -- and for some styles of Arabic such as nastaliq it is the only sensible approach --, but it is something to be aware of and may result in some support contact from confused users.

Zuhair Albazi's picture

Thanks.

It solved the problem. I am grateful to Khaled Hosny for such detail and taking time to explain the solution with an image. I also appreciate John Hudson for providing valuable piece of information.

Once again Thanks.

Syndicate content Syndicate content