Does VOLT Help in Developing Arabic Fonts?!

AzizMostafa's picture

Peace be on All Friends,
In VOLT, Marks Positioning is carried out Independently for each letter and for each component of every ligature?!
So, to avoid the Collision of Marks with Marks and/or Letters in Arabic Fonts:
1 The thinest letter or ligature should be at least a bit wider than the widest mark. Just like asking 3 cowboys to stand side by side without allowing their Hats to collide. And this can be done at the expense of Beauty.
2 Marks should be horizontally centered on top of or below each letter and each component of every ligature. And this is not always possible even if Beauty is sacrificed.
Samples speak louder than words?!
Daringly

sergeym's picture

You can always do mark positioning in context of neighbor glyphs. So you can move marks higer if there are marks over other letters that can cause collision.

Dealing with ligatures is essentially the same, but may be tricky, though. OpenType model can not distinguish between mark over one or another component, except for mark-to-liga attachments. For example, for sequence of ligature and mark, lookup can say that something should happen only if mark is logically attached to the first component. There could be workaround for that, for example having separate glyphs for mark over first second etc. component.

Thanks,
Sergey

John Hudson's picture

You can always do mark positioning in context of neighbor glyphs. So you can move marks higer if there are marks over other letters that can cause collision.

In addition to this, I have also contextually inserted a very narrow joining stroke between two letters when I need to accomodate a mark that might otherwise collide with an adjoining letter. This is appropriate in more linear designs, rather than in the kind of calligraphic design shown in the illustration. Calligraphy has its own rules for mark size and positioning.

AzizMostafa's picture

Sergey says:
You can always do mark positioning in context of neighbor glyphs.So you can move marks higher if there are marks over other letters that can cause collision.

Say:
.. Higher and higher till I get all Marks on the same level (Mac it).
For the best mark positioning you can ever get with a ligature-free font, see this:
http://www.nonosoft.jifisa.net/download.php
Try Volting it!

Sergey continues:
Dealing with ligatures is essentially the same, but may be tricky, though. OpenType model can not distinguish between mark over one or another component, except for mark-to-liga attachments.
For example, for sequence of ligature and mark, lookup can say that something should happen only if mark is logically attached to the first component. There could be work around for that, for example having separate glyphs for mark over first, second etc. component.

Say:
Easier said than done!
Just tell me please where to position what out of hundreds — not to say thousands — of marks:
http://qurankareem.info/a/OthmanyFonts.zip
http://qurankareem.info/a/othmanyQuran.zip
This will make the brain of an octopus-minded to work overtime to work around Independently up and down, across and back, diagonally in 4 direction so that Marks wont collide.
________________________________
Happy Exploring

sergeym's picture

Easier said than done!

Who said this will be easy?! Of course Arabic typography requires very complex font logic, but it is definitely doable with OpenType layout.

Thanks,
Sergey

Si_Daniels's picture

>but it is definitely doable with OpenType layout.

reminds me of the old saying "fonts are hard... lets go shopping" ;-)

AzizMostafa's picture

John Hudson says:
... I have also contextually inserted a very narrow joining stroke between two letters when I need to accommodate a mark that might otherwise collide with an adjoining letter. This is appropriate in more linear designs, rather than in the kind of calligraphic design shown in the illustration.

Say:
After All the Automation and Volting, I have to do a manual Adjustment?! That what I did in Windows 3.11. In addition to this, I had also contextually inserted a very narrow joining Space when I needed to accommodate a mark that might otherwise collide with a final letter.

This was appropriate in more linear designs and in the kind of calligraphic design shown in the illustration, too.

AzizMostafa's picture

Sergey says:
Who said this will be easy?! Of course Arabic typography requires very complex font logic, but it is definitely doable with OpenType layout.

Say:
Easier done with Fontgraph 3.5 on windows 3.11.
Go back and re-explore!

david h's picture

I don't understand - are you asking for help? do you like to work with VOLT? or you can do it without VOLT, and even better? If yes - great, but why the 'negative'* ? You don't have to use it.

[* a lot of negative here lately; negative season?]

AzizMostafa's picture

Thanks for your Positive Feedback David
My "Uncompromisng Arabic Font" was done without VOLT.
http://typophile.com/node/19348
However, I am looking forward to transforming my (5+1) fonts into a single OTF.
But it seems that Volt does not help?! Is there a better Alternative?
Thank you once again.

david h's picture

You're welcome Aziz.

I need a lifeguard to go through that thread (typophile.com/node/19348)
So, if we keep it simple (but no simpler): you want a single OpenType? You can't do it with VOLT (+ hard work) ? Why not?

Si_Daniels's picture

I get the impression that this is really just an excuse to vent on VOLT, and there's nothing wrong with that. However, Sergey & John took the question seriously and shouldn't be harshed for trying to offer some advice. Falling into the same trap I might suggest that the power users of VOLT do a lot of the number crunching outside of VOLT (eg in Excel and perl based tools), and import the source tables into VOLT for compilation - that's apparently the best approach on complex jobs.

Katia Dali's picture

hello there!!

I am a new VOLT user and Im facing a problem that might seem silly to you. but i wish u can help me with this: "im working on an Arabic open type font designed by font lab, when Im opening the font from VOLT toolbar or File/open menu, im not being able to view the glyphs, what I see i empty boxes with ID numbers. while when i open a font like "times new romans" lets say, i can see the letters in the edit glyphs window. so please can you help me figure out how to import a new font and be able to see the font in the edit glyph window.

i wish what i said makes sense to you.

Miguel Sousa's picture

> when Im opening the font from VOLT toolbar or File/open menu, im not being able to view the glyphs

Is the font TrueType ?

Si_Daniels's picture

I think Miguel is correct - the font is likely an OpenType CFF font, needs to be TrueType. Reason for this is that VOLT uses its own inbuilt rasterizer (TTF) rather than the system rasterizers.

John Hudson's picture

After All the Automation and Volting, I have to do a manual Adjustment?!

No no no, I mean I have automatic contextual insertion of a narrow connecting stroke within the VOLT lookups.

John Hudson's picture

Here is an example, using the Adobe Arabic font created with VOLT. The insertion of the narrow connecting stroke is done automatically, as a GSUB type 2 lookup, based on the context of the mark following the alif.

John Hudson's picture

By the way, I don't think that OpenType is the best way to handle Arabic text. There are, for instance, good arguments for layout systems that treat diacritic marks as a separate layer applied after word formation. Contextual mark positioning and spacing adjustment is the most difficult and cumbersome aspect of Arabic OpenType, especially if one wants refinement. The benefit of OpenType is in its wide support and adaptability. If you have a different solution that works for your needs -- even if it only works in one application and requires macros --, is there a need to make an OpenType version?

AzizMostafa's picture

Thanks John for your input.
Though the example given does not occur in Arabic, I do understand what you mean. Any how, if it is applied to the last word in the first sample (on the left), it will be spoilt?
How if a word ends with R+TaMarbota and the Tanween of TaMarbota collides with R?

david h's picture

> There are, for instance, good arguments for layout systems that treat diacritic marks as a separate layer applied after word formation.

Such as?

AzizMostafa's picture

John Hudson says:
By the way, I don’t think that OpenType is the best way to handle Arabic text.

Say:
OpenType is the best way to handle marks-free Arabic text?
So, let us concentrate on Ligatures.
In ArabicTypesetting, a number of 2&3-component ligatures were built.
In Nafees Naskh of http://www.crulp.org, instead, all the possible shapes of characters to form ligatures were built — save LamAlif of course.
Which approach do you see better and Why?

AzizMostafa's picture

Back at the service of Friends,
Here are 2 lines of the same Arabic Text using ArabicTypesetting OTF:
the lower is marked and the upper is marks-free.

By comparison, one can easily see:
The left significant word in the lower line is a bit longer than the above due to the narrow stroke between its first and second letters, as mentioned by John Hudson .
The 2 Middle words in each line have the same shape irrespective of Marks.
The 3 words on the right of the lower line are not ligatured as above. In other words. Marks spoilt the ligatures.

Why this Inconsistent Behaviour?!

AzizMostafa's picture

John Hudson says:
There are, for instance, good arguments for layout systems that treat diacritic marks as a separate layer applied after word formation.
...
If you have a different solution that works for your needs — even if it only works in one application and requires macros —, is there a need to make an OpenType version?

Say:
Yes. There is a need to make an OpenType version to benefit from the OpenType wide support and adaptability to long documents not a couple of lines that can be fantastically handled in a number of applications by creating 2 layers: one for letters and the other for marks!

John Hudson's picture

How if a word ends with R+TaMarbota and the Tanween of TaMarbota collides with R

There are two ways to deal with this kind of collision. I believe the more traditional technique is to contextually lower the Tanween so that it no longer collides with the R. Another technique is to introduce a contextually sensitive kerning adjustment between the R and the TaMarbota when the latter is followed by a below mark. I think the decision which method to use depends very much on the type design. In a very modern, linear design one might want to make the heights of marks quite regular and not raise or lower them contextually, so in that case the kerning option might be best. In a traditional naskh design, though, one might want to preserve the letter relationships and allow the marks to move as necessary; this better emulates the scribal approach.

John Hudson's picture

So, let us concentrate on Ligatures.
In ArabicTypesetting, a number of 2&3-component ligatures were built.
In Nafees Naskh of http://www.crulp.org, instead, all the possible shapes of characters to form ligatures were built — save LamAlif of course.
Which approach do you see better and Why?

Although every Arabic font I have worked on to date has involved ligature glyphs for one reason or another, I actually think that the better approach is not to use ligatures, but instead to have component stroke shapes which are contextually substituted to produce the correct forms. This technique is much more adaptable and efficient. Consider, for example, Monotype Nastaliq, which had up to 22,000 ligature glyphs -- some for entire words -- in its late metal and final phototype versions, but which has recently been remade in OpenType using only a small fraction of that number of glyphs.

I'm aware of some fonts that even use component strokes to create the lam_alif sequence, i.e. that do not contain any ligatures at all.

John Hudson's picture

David,

Tom Milo's DecoType Arabic layout system uses a layering approach which follows the way in which calligraphers construct a word. First the 'archigraphemes' of the letters are written; these are the letters, correctly formed, but without any marks at all, not even the distinguishing dots. Then the dots are written relative to the letterforms and taking into account context of nearby strokes. Then vowels are written relative to both letterforms and dots. If I remember correctly, Tom breaks the system down into about seven different layers, based on classification of marks. Also, marks in the system are not of fixed size, but may be longer or shorter depending on context, as found in calligraphy.

Although all my own Arabic work has been in OpenType, I'm pretty convinced that only an approach like Tom's can result in optimal mark positioning. The downside of such a system is that it tends to be very slow: not something you would want to use for, e.g. e-mail. But in the context of book production, it is the best thing available.

John Hudson's picture

The left significant word in the lower line is a bit longer than the above due to the narrow stroke between its first and second letters, as mentioned by John Hudson.

In this case, I believe the method is not an inserted narrow stroke but a variant form of the K, but yes the result is the same.

The 3 words on the right of the lower line are not ligatured as above. In other words. Marks spoilt the ligatures.

This font contains two different kinds of ligature lookups. Some ligatures are allowed to form even when marks are involved in the sequence (in VOLT, they are set to process NONE of the mark glyphs), and some ligatures are inhibited from forming when marks are involved (in VOLT, they are set to process ALL mark glyphs). This is a design decision. In the Arabic Typsetting font, Mamoun Sakkal decided to prevent ligatures involving vertical stacking from forming when marks are applied, because in these situations it is sometimes confusing, even for the reader, to know to which letter in the ligature a mark is applied.

I use the same method when dealing with the initial lam_mim sequence, in which the mim portion of the ligature ends up to the right of the lam, which phonetically precedes it. So if the lam takes a mark, I prevent this ligature from forming because it is too easy to be confused about which letter is taking the mark.

Of course, if one is seeking to emulate the traditional naskh style including its mark positioning, then one probably doesn't want to inhibit ligation in these circumstances. But then one is also presuming a level of readership that is quite high.

david h's picture

Thanks John. Just read his paper (20th International Unicode conference)

AzizMostafa's picture

Thanks John,
...... Monotype Nastaliq has recently been remade in OpenType using only a small fraction of that number of glyphs.
How Lucky! No Bites (Marks)

Tom Milo’s DecoType Arabic layout system..... it is the best thing available.
Kelk2000 has no match:
http://www.kelk.ws
Appreciatively,

John Hudson's picture

I wasn't familiar with the Kelk2000 stuff. Thank you fr the link.

It isn't clear, though, from the limited English information available on the website whether the results of this system are live text. There is talk about creating 'artwork', which looks very impressive (reminds me of Tom's 'Make Calligraphy' plug-in for MS Office 2000), but does it remain live (Unicode?) searchable and editable text? That is really key in the context of crossmedia publishing, which is obviously becoming more and more important.

John Hudson's picture

By the way, at the Unicode conference in California in March Tom showed a demo of the stuff he has been working on with Winsoft as a plug-in for the Middle East version of InDesign CS3. It works a little like a CJK input method: you type a word in Unicode and are presented with all the valid options for writing that word according to the rules of the script style you are using, and you select the one you want. Very impressive.

AzizMostafa's picture

John On behalf of Tom & WinSoft:
You type a word in Unicode and are presented with all the valid options for writing that word according to the rules of the script style you are using, and you select the one you want. Very impressive.

Say: That is exactly what Kelk2000 does.

AzizMostafa's picture

John Hudson says:
In the Arabic Typesetting font, Mamoun Sakkal decided to prevent ligatures involving vertical stacking from forming when marks are applied, because in these situations it is sometimes confusing, even for the reader, to know to which letter in the ligature a mark is applied.
I use the same method when dealing with the initial lam_mim sequence, in which the mim portion of the ligature ends up to the right of the lam, which phonetically precedes it. So if the lam takes a mark, I prevent this ligature from forming because it is too easy to be confused about which letter is taking the mark.

Sorry to say: Unsuccessful Decision!
Save in the Lam_mim sequence, sacrificing ligatures elsewhere was not justifiable!
Arab eyes do snap Marks on ligatures to their corresponding components:
The right and left significant marks are respectively snapped to the right and left components and the middles to the middles.
And this is intuitive to the non-Arab eyes too.

Worse is the shifting up of the beginning of words like the marked one here. The arm of the second letter appears higher than Alif?!
Wish the unmarked shape were maintained.

AzizMostafa's picture

How if a word ends with R+TaMarbota and the Tanween of TaMarbota collides with R? (Right)

John says:
... I believe the more traditional technique is to contextually lower the Tanween so that it no longer collides with the R. (Middle)
Say: This wont Only look odd but will transgress the lower line (Win-Descent) also.

John says:
.. Another technique is to introduce a contextually sensitive kerning adjustment between the R and the TaMarbota when the latter is followed by a below mark. (Left)
Say: This is the Only possible solution unfortunately not applied in the said OTF.

John says:
... In a very modern, linear design one might want to make the heights of marks quite regular and not raise or lower them contextually...
Say: No way!

AzizMostafa's picture

My last posting has changed alot.
Please check it before replying.
Thanking you and Apologizing for the inconvenience.
Happy Postings

John Hudson's picture

Sorry to say: Unsuccessful Decision!
Save in the Lam_mim sequence, sacrificing ligatures elsewhere was not justifiable!
Arab eyes do snap Marks on ligatures to their corresponding components:
The right and left significant marks are respectively snapped to the right and left components and the middles to the middles.
And this is intuitive to the non-Arab eyes too.

Since I wasn't responsible for the font in question (at least, not for the Arabic part of it), I don't want to second guess the reasons for the ligature decisions. I'll just note that, obviously, Mamoun Sakkal has 'Arab eyes', and he made these decisions.

Worse is the shifting up of the beginning of words like the marked one here. The arm of the second letter appears higher than Alif?!
Wish the unmarked shape were maintained.

I agree that this looks quite unhappy.

AzizMostafa's picture

Thanks John for your understanding and tolerance.
In the said font, no mid-word ligatures were included. Obviously, there was no difficulty in that and words like the alif-lamed here would look as happy as their sisters.
Was that up to the Decision-Maker also?

John Hudson's picture

Yes. Decisions about what glyphs are font contains and how they work are the decisions of the designer.

In most Arabic fonts I have worked with, ligatures tend to be limited to a few isolated sequences, a few initial sequences, and generally more final sequences. But there is no reason why a font could not contain medial ligatures.

The issue that one runs into, though, is deciding which ligatures take preference. This is another reason why I favour a non-ligature approach, which is more flexible and is not constrained by choices about what ligatures to include and which take precedence.

AzizMostafa's picture

> But there is no reason why a font could not contain medial ligatures.
How wonderful the font will look like then!
Medial ligatures make words shorter (less horizontal) and more comfortable to the eyes ( for Arabs and non-Arabs):

> The issue that one runs into, though, is deciding which ligatures take preference.
This should not be an issue as the priority is given to 2 middle shapes: Meem then to the sea-horse (Jeem and likewise).

> ... This is another reason why I favour a non-ligature approach ....
A better approach is a combination of the 2: 3&4-component ligatures and stroke shapes to produce 2-component ligatures.

Yours for Beautiful Arabic Faces, John

John Hudson's picture

Medial ligatures make words shorter (less horizontal) and more comfortable to the eyes ( for Arabs and non-Arabs)

Less horizontal, of course, usually means more vertical, and this may have been a factor in the decision not to employ medial ligatures in the Arabic Typesetting font. This font is mainly going to be used in an application like MS Word, by users who are used to employing fonts using the default linespacing. In such a situation, having word forms growing tall through use of medial ligatures could cause problems with parts of letters being clipped as they extend beyond the font's WinAscent setting. Obviously in fonts designed primarily for use by experienced typographers such as yourself, or in professional page layout applications, this would be less of a concern.

AzizMostafa's picture

> Less horizontal, of course, usually means more vertical
What makes you jump to this wrong conclusion?
Simply avoid Ligatures with the tall Ta&Za and Kaf and you are done!
Yours with Flowers

AzizMostafa's picture

> ... and this may have been a factor in the decision not to employ medial ligatures in the Arabic Typesetting font... In such a situation, having word forms growing tall through use of medial ligatures could cause problems with parts of letters being clipped as they extend beyond the font’s WinAscent setting.

Another Guess?
The raised letter forms in the said font speak louder than ligatures?!

John Hudson's picture

I was looking at your earlier example of the dad_jeem ligature, and thinking that if you maintained that if the lam were raised to connect to the dad in its ligated form, the overall height would be very tall: taller even than the raised letter example you show here.

AzizMostafa's picture

In the case of Lam+Dad+jeem, the lam should be a little bit lowered and its lower end curved to shoulder Dad...
More importantly, the Dad+jeem should not be in that height and thickness...
Accurate Calculation counts?!

AzizMostafa's picture

So far, Marks and Ligatures have been covered, but kerning was out of discussion.
Sampling 3 words in the ArabicTypesetting font created by John Hudson with VOLT, see how the kerning between (Z+Alif) and (R+3ain) has shortened and beautified the middle word. But no kerning took place between (R+Alif) in the left word nor between (R+3ain) in the right one...
Why does kerning work in some places and does not work for the very couple(s) elsewhere? Was the fault in VOLT? Or elsewhere?

John Hudson's picture

Aziz, I did not create the Arabic Typesetting font: I only designed the Latin portion of the typeface. Mamoun Sakkal designed the Arabic, beginning with an initial idea from Paul Nelson, and Mamoun also did the VOLT work for the font.

I think the kerning problem you are seeing must be due to the Arabic Typesetting kerning being implemented as a width adjustment on the first glyph, which is how GPOS kerning is properly implemented for left-to-right scripts. When this font was made, no one had figured out that right-to-left kerning needs to be implemented differently -- as equivalent width and positioning adjustments to the second glyph --; I presume this will be fixed in the next version of this font. [Microsoft may be concerned about backwards compatibility and text reflow in existing documents, but this kerning problem is so bad that I think such concerns should be ignored.]

If right-to-left kerning is implemented in the same way as left-to-right, only every second pair of glyphs gets kerned, and this is what you are seeing in your test. If you were to add another character before the sequence زرع then you would see the kerning suddently applied between رع. You see this in the graphic below. The second line shows the Adobe Arabic font, in which the kerning has been applied to the second glyph in the lookups, and the spacing is consistent regardless of the number of glyphs in the run.

[Note that if one uses the kern2volt tool to convert a FontLab generated kern table to GPOS kerning in VOLT, the tool has an -RTL option that will correctly define the lookups for right-to-left scripts. You will need separate kern table sources for RTL and LTR kerning though.]

AzizMostafa's picture

Thanks John for your elaborated answer.
> If you were to add another character before the sequence زرع then you would see the kerning suddently applied between رع.

Say: True only if R is added. Or a zero-width non-joiner!
The 2nd word from the left in my very first sample says otherwise...

And from your samples, It seems that both Adobe and Mircosoft confused Arabic with English Kerning!

Hope you will find my previous postings useful:
http://typophile.com/node/19609
http://typophile.com/node/19348

> .. Mamoun Sakkal designed the Arabic.. and Mamoun also did the VOLT work..
Say: I’ll just note that, obviously, Mamoun Sakkal has ‘Arab eyes..

Katia Dali's picture

I want to ask you all, how did you learn VOLT? Does anyone of you has a manual for it?

John Hudson's picture

I learned VOLT by using it and by pestering Paul Nelson and Sergey Malkin at Microsoft. I had the advantage that I was developing fonts for them so they were obliged to answer my questions. :)

There isn't a really good VOLT manual or tutorial out there, although what is available is still quite helpful if mixed with experiment and trawling in the archives of the VOLT user community on MSN. I'd be interested in writing a proper VOLT manual if I had time and someone were to pay me.

In the meantime, I suggest looking at these links:

http://www.microsoft.com/typography/developers/volt/default.htm
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=VOLT_Tu...

then go to the MSN VOLT community site:

http://groups.msn.com/MicrosoftVOLTuserscommunity

and look through the message archives for the release notes for individual updates or search for specific topics.

Katia Dali's picture

thank you john, it was nice of you to reply to my questions. but i still need to know how much time (approximtely) it took you to learn volt? and did you face lots of difficulties? Actually the font that im working on is Arabic and it is a very specialized language with lots of glyphs..

John Hudson's picture

VOLT for Arabic is not very complicated -- not compared to, say, Devanagari, which I'm working on at the moment. The basic GSUB shaping features -- init, medi, fina (isol is optional, basically only necessary if you want to perform contextual heh shaping) -- are very straight forward, as are the ligature substitutions. Things are trickier if you start getting into contextual substitutions, e.g. if you have different glyph forms that you want to employ in different situations, but even then you just need to keep track of your contexts.

GPOS mark positioning is probably the most difficult thing you'll need to learn for Arabic, and is mainly tricky because the interface might not be intuitive at first. Read the tutorials carefully.

VOLT isn't a massive program -- it does some specific tasks for OpenType Layout development -- so there isn't very much to learn in terms of interface. The thing that takes time is figuring out the best way to do things for different scripts, and also learning what expectations shaping engines have for those scripts.

alviamjad's picture

I am new to this Forum, thanks to Aziz for providing this link.

I have also developed a Quranic Naskh Font, where i faced almost similar problems just like faced by Mr. Aziz.

I want to share my ligature part of font. I organized the shapes to change with the proceeding or before character to work like a ligature. i.e the fist image shows three shapes where meem_mid, ta_ini and ya_before_noon changes its shape accordingly with the proceeding characters. So, I belieive we don't need to have ligature in our font just to focus on perfect shapes. If we do so, we can easily handle the positioning of marks on ligatures.

AzizMostafa's picture

Welcome Alviamjad with Flowers
Please Alviamjad, do me a favor:
1. replace your first inserted image with a smaller one.
2. replace your second inserted image with an attached file instead.
Many Thanks for your understanding.

AzizMostafa's picture

Alviamjad says:
So, I believe we don’t need to have ligature in our font just to focus on perfect shapes. If we do so, we can easily handle the positioning of marks on ligatures.

Am I right to say:
VOLT is so passive that it trades off Marks with Ligatures?!
______________________
John Hudson says:
VOLT isn’t a massive program — it does some specific tasks for OpenType Layout development — so there isn’t very much to learn in terms of interface. The thing that takes time is figuring out the best way to do things for different scripts, and also learning what expectations shaping engines have for those scripts.

Just a question:
Is it possible to make 2 marks go with a single letter as shown here?

AzizMostafa's picture

This is just to notice that the previous posting has been modified.
With Compliments and Apologies

John Hudson's picture

Is it possible to make 2 marks go with a single letter as shown here?

Yes,* although what your image shows would normally be two different kinds of lookups.

In the first word, with the damma above the fatha on the initial mim, this would be handled as an above mark-to-mark positioning. So the fatha would be positioned relative to the mim, and the damma would be positioned relative to the fatha.

In the second word, both the shadda and the kasra are positioned relative to the letter, the medial qaf, using two separate anchor attachments, one above and one below.

To render the second word, it is also possible to write the kasra directly below the shadda, with both marks above the letter. In this case, one would perform a mark ligation using the ccmp feature. This is a decision of the font developer.

Note that above mark-to-mark and below mark-to-mark positioning should be defined in separate lookups, with the above mark-to-mark lookup set to ignore below marks and vice versa. This ensures that mark-to-mark positioning occurs even when, e.g. two above marks are separated in the character sequence by an interverning below mark.

* Note: although OpenType allows you to apply mark-to-mark positioning for any sequence of marks, some applications or shaping engines may restrict certain sequences if they consider them to be grammatically invalid. So, for instance, the sequence of fatha with damma shown in your example is not recognised by the Uniscribe Arabic engine as a valid sequence, so the damma displays on a dotted circle. Personally, I think this is a really bad idea, and I suspect MS are beginning to think so too: a script shaping engine should not be acting as a spellchecker! The same sequence displays without the dotted circle in InDesign ME, with the damma above the fatha according to the OpenType mark-to-mark positioning.

alviamjad's picture

Appology, Pl. find the images. I'am unable to figure out how to attach file a PDF file with this message, so I uploaded it with "insert image" may be I am wrong, if so pl. tell me.

Aziz says:
VOLT is so passive that it trades off Marks with Ligatures?!

I think, Yes, positioning of marks on ligatures is very difficult to handle in Volt, That is why, i used different shapes instead of ligatures to correctly place marks. The page you see in PDF format contains only one ligature i.e. "Lilla" the last word in first row.

Pl. also see the last word in the fourth row, where middle shape of "ta" changed accordingly to help placing of marks.

alviamjad's picture

-deleted-

alviamjad's picture

I think this is better to view.

Only one ligature used in the whole page i.e. "Lillah" the last word in first row.

AzizMostafa's picture

Take it easy Dear John,
Here are 2x2 words written on the same line in the very Wordpad of windows:
The left wing reads ArabicTypesetting and the right wing reads Tahoma.
Emphasizing: Same Engine, Same words, and Same line.
How nice Tahoma is that it does not force:
• marry the classmates (Kasra to Shadda).
• separate the spouses (?).
Why ArabicTypesetting is not so democratic?

John Hudson's picture

'Marrying the classmates' is a stylistic decision. There is either a lookup in the font that does this or there is not. So Tahoma doesn't do it and Arabic Typesetting does.

The second issue is more surprising. I've tested this with a lot of different fonts, and the only ones in which the damma does not appear on a dotted circle are fonts that do not contain any OpenType GPOS mark positioning. In Tahoma, the marks are not positioned using anchors, they just fall wherever their offsets on their zero-widths put them, and they are not classified as marks in the GDEF table. So I think Uniscribe is dealing with these fonts in different ways. Uniscribe is not one shaping engine, but several, including different engines for different scripts, some for backwards compatibility. What Uniscribe does with a particular string depends on both the characters in that string and what tables exist in the font.

sergeym's picture

The second issue is more surprising. I’ve tested this with a lot of different fonts, and the only ones in which the damma does not appear on a dotted circle are fonts that do not contain any OpenType GPOS mark positioning.

Arabic fonts without 'arab' script in GPOS are considered by Uniscribe as legacy fonts and processed by old shaping engine, which does not support lots of things like contextual substitutions or mark positioning. Marks can be processed using 'mset' feature. New fonts, recognized by presence of GPOS, are processed by new engine that supports all OpenType layout lookups.

In Avalon, there is only one engine, which has the same rules as a new one in Uniscribe.

I do not know exactly why limitation of a single mark of each type over the base was introduced for Arabic script. I can imagine some security (spoofing) or backward compatibility reasons. I will try to find out more.

Thanks,
Sergey

John Hudson's picture

Handling mark positioning on ligatures is more complicated than on single-component glyphs, but it certainly isn't impossible. One needs to define the ligature glyphs as ligatures in the GDEF table (using VOLT's glyph edit window) and correctly record the number of components in the ligature, e.g. 2 components for the lam_alif ligatures. Then you create a mark-to-ligature lookup associated with the mark feature, and define anchor attachments for the individual components. Here are some examples of mark-to-ligature positioning in two fonts I have worked on, Adobe Arabic and Karim LT, showing marks applied to several two-component ligatures.

My own dissatisfaction with ligatures is not with the relative difficulty of mark positioning, but with the awkwardness of the transition between two ligatures, e.g. between the theh_mim and the dad_yeh in the last word. Ligatures create elegant flowing forms for the invidiual pairs of letters, but the connection between them is not elegant and looks awkward compared to the ligatures. A ligature-free approach such as our Pakistani colleague can resolve this.

The Arabic fonts I have worked on to date have all been based on a ligature model, because that was the nature of the designs as provided. When I design my own Arabic typeface, I intend to avoid ligatures.

John Hudson's picture

Sergey, a short while ago on one of the Unicode lists, Paul Nelson expressed the view that script shaping engines should not be performing what are, in effect, spellchecking functions. I took this as a hopeful sign that we might see a lot fewer dotted circles in future!

In my Biblical Hebrew font, I actually include a lookup that removes dotted circles from glyph strings, so that any combination of marks can be applied to any base, because scholars working with ancient manuscripts may need to represent non-standard spellings. Looking at what Uniscribe is doing with Arabic, I'd be inclined to do the same sort of thing in Arabic fonts. But the problem then is that users who actually want to display a dotted circle, e.g. to show a mark in isolation, are unable to. It would be much preferable if Uniscribe simply gave up on trying to enforce 'valid' mark sequences. As far as I'm concerned, a valid mark sequence is any mark sequence that a user deliberately creates, and it is up to the font to succeed or fail in rendering the sequence in an acceptable way. So far as I know, there are no invalid mark sequences for Latin GPOS: marks can stack endlessly. It should be so for all scripts employing the mkmk feature.

alviamjad's picture

John said!
The Arabic fonts I have worked on to date have all been based on a ligature model.

I don't agree with. Arabic Calligraphy is basically combination of curves & stroks. As nicer your curves, the font looks elegant. Almost all the computer fonts which I have seen, have sufficent number of ligatures. That is due to difficulty of curves and joining points which decreases the fluency of strokes. But I think, it is not so difficult to handle. If we manage to perfect our curves and shapes, we don't need to have any ligature at all. Marks are so easy to place on seprated shapes. Also if we insert any "Kashida", it will not cause any broken ligatures nor collision of marks etc:

John Hudson's picture

If we manage to perfect our curves and shapes, we don’t need to have any ligature at all.

Yes, I agree. As I explained, the only reason the fonts I have worked on in the past have ligatures is that this is how they were designed: I was not the designer, only the person manufacturing the fonts. If I design my own Arabic typeface, I will avoid ligatures.

Regarding the curves and connecting strokes, OpenType has a cursive attachment GPOS lookup, which can be used to create smooth non-horizontal connections. With this, one can even produce nastaliq style with minimum ligatures.

alviamjad's picture

I have a suggestion for designing of any future Arabic Font that is to follow the technique of 'Nataliq', Computer aided Arabic scripts are traditionaly lying on base-line where base of almost all characters is on a straght line, this creates problem of accuratly placement of marks, in contrast Nastaliq is based on cuved type of writing which flows from top to bottom. It would be a good idea, if we adopt Nastaleeq policy where variation of character helps placement of Marks and Nuqtaas (dots).

Top part is Traditional Arabic Font and the Second one is Nafees Nastaleeq, Notice the flow of strokes of second line, this will helps in placement of marks. In South East Asia (Indo-Pak) the calligraphist adopted this policy and changed the Arabic Naskh into Naskh-cum-Nastaliq, which is easy to read and different from the Naskh of Arabic World.

AzizMostafa's picture

John Hudson says:
My own dissatisfaction with ligatures is not with the relative difficulty of mark positioning, but with the awkwardness of the transition between two ligatures, e.g. between the theh_mim and the dad_yeh in the last word. Ligatures create elegant flowing forms for the individual pairs of letters, but the connection between them is not elegant and looks awkward compared to the ligatures.
A ligature-free approach such as our Pakistani colleague can resolve this.
... When I design my own Arabic typeface, I intend to avoid ligatures.

Say:
Learning ligatures from the Experienced is better than avoiding them or inventing handicapped ones:


Legs between legs and hands grasping shoulders (from below) is healthier than the 69 and X ways?!
_____________________________________________
Alviamjad says:
Also if we insert any “Kashida”, it will not cause any broken ligatures nor collision of marks etc..

Hate Kashida as I hate condom?! Make it Or not:
http://typophile.com/node/19348.

John Hudson's picture

Aziz, a ligature is a particular technical solution to a written form, i.e. the representation of two or more character by a single glyph. The point which I am trying to make is that the richness of the Arabic script does not rely on this particular technical solution and there are other methods to capture that richness in typography. The examples you give of elegant letter combinations can all be broken down into constituent strokes, i.e. the elegance is not dependent on these being ligatures: they could be constructed from contextually appropriate strokes. The advantage of such an approach is that it is far more flexible than even the most extensive ligatured font.

AzizMostafa's picture

> The examples you give of elegant letter combinations can all be broken down into constituent strokes..

Say: Not including the Last Examples?!

> ... i.e. the elegance is not dependent on these being ligatures: they could be constructed from contextually appropriate strokes. The advantage of such an approach is that it is far more flexible than even the most extensive ligatured font.

Say: Precisely! This is the right way.

John Hudson's picture

Not including the Last Examples?!

Why not? Any form that can be constructed as a ligature can also be constructed as strokes that, if arranged correctly, would be visually identical to the ligature. The question is whether the arrangement can be achieved in a reasonable (and efficient) way in a particular font format. When I wrote that I would avoid ligatures, I didn't mean that I might not end up using some ligatures, but only that I would first try to resolve the forms using individual glphs and contextual substitution and positioning. I was looking at some thuluth calligraphy today, and figuring out how I would handle it using a font; there were only a couple of forms for which I might use a ligature.

Precisely! This is the right way.

What is the right way? I'm confused: are we agreeing or disagreeing?

AzizMostafa's picture

Since, Not All combinations are breakable, then Combining the 2 approaches (Ligatures and strokes) will result in more flexible and more elegant Fonts. Where to break what? There lies the creativity of the Designer.

For thuluth calligraphy, Consult:
http://www.splart.net/forum/index.php?showtopic=63
All the Best

alviamjad's picture

Certainly we cannot deny the importance of ligatures but in some cases, it cause lot of difficulty of placing marks etc: for example

the first word is taken from 'Tulth' and the second from 'Traditional Arabic' fonts. I tried my level best to put marks on first two 'meems' but result is quite annoying. This kind of ligatures can't be handled with appropriate marks.

Let take another example:

the first word is better ligtaure form of 'Saad' & 'Ra' combination then from the second one. Why not we break apart them as appeared in shapes below. I used lot of these forms in my Font. Actually when I start designing my font, I was more of the view of including ligatures, but when I practically faced problems, I totally divert my focus on to include shapes in place of ligatures.

AzizMostafa's picture

Believe it or not:
It took me 3 Full-Time years to find and work out what to break and where to break what. For that, I went on consulting more than 5 Iraqis and Iranians and 3 Books by outstanding Egyptians and Turkish Calligraphists..
But...where to find the understanding and fair sponsor?

Here is one more example in my font just to entertain your eyes:

alviamjad's picture

Aziz Said:

>Hate Kashida as I hate condom?!

I think it is not fair, may be you are thinking this because in 99% of the fonts 'kashida' is a straight line which destroy the beauty of curves.

Actually true 'kashida' is a curved type of stroke which makes Arabic writing more elegant and easier to read. Also in some cases where marks are difficult to place 'kashida' is a better option to adopt.
see this example:

AzizMostafa's picture

Woooow! 2 Kashids?! This means 2x2=4 (2 different ends)
Can you define where — between which letter pairs— they must and must not go?!
A Single and Short straight Kashid goes out of control and behaves so randomly and indiscriminately that it beautifies some words and spoils others. How if 4?
Ask those who take care of 4 wives in a single home?!

Then, where has the Kashida been deployed in your example?

Yours for the Workarounds

AzizMostafa's picture

Though we drop Marks in most of our writings, we do make use of them to differentiate or emphasize certain words. But ArabicTypesetting assumes that Marks would be either fully used or not used at all?!
If you interested in Hide and Seek games, then you are invited to find the hidden Fatha in the left word.


Any explanation?

alviamjad's picture

If you see the traditional calligraphy from all over the world, you will see lot of 'kashida'. Why they are using it?. You can't exempt Computer based calligraphy from its importance.

I never found 'kashida' to spoils any of my word nor behave indiscriminately. I always found this charachter very helpful in placing marks or reducing the complexity of shapes. May be my font is an extended type of behaviour with thick base, that is why 'kashida' helps to make more white space, which looks nicer. Also I could say that the font on which you are working is so condensed that there is no room for 'kashida'. That is why you are against this character.

alviamjad's picture

Aziz said:
If you interested in Hide and Seek games, then you are invited to find the hidden Fatha in the left word

Dear Brother!
I don't know what you want to ask, there is ligature invovled in your example to whome I was mentioning in almost all of my earlier posting that use of ligatures is not a solution in Arabic. We have to make certain shapes to avoid ligatures. Ligatures does make difficult to place marks.

I used a short lam_initial shape to avoid marks positioning in following 'kaf'.
pl. see this.

I used two shapes of lam_initial in my font.

John Hudson's picture

Aziz, the problem in the example you show is not because of the number of marks, but because the Arabic Typesetting font lacks a form of the lam_mim ligature with a short lam. It does have a short lam, which is automatically substituted before medial kaf, but it does not have a corresponding short form of the lam_mim combination. It is a design flaw, not a technology flaw.

There is what I consider another design flaw: a fatha above the short lam is too high, I think, and still too close to the kaf. I would probably lower it, under the arm of the kaf, to make it more clearly associated with the lam.

AzizMostafa's picture

1. Thanks John for the Clarification
2. What is the Alternative to Kashida?
Perfection of Arabic Calligraphy is achieved not by adding Kashida within words nor by changing Kaf — as in Adobe Indesign— but by controlling word spacings as in Adobe PageMaker—narrowing spaces between words ending with clockwise and others beginning with counterclockwise letters.
In other words: Space width Modulation.
Copyrighted by AzizMostafa (?)
http://typophile.com/node/19348

AzizMostafa's picture

John says:
Aziz, the problem in the example you show is not because of the number of marks, but because the Arabic Typesetting font lacks a form of the lam_mim ligature with a short lam.

Say:
The problem is not Only with Lam-mim but with her classmates also.


Another design flaw?
John Hudson and Mamoun Sakkal should think sreiously of reconstructing ArabicTypesetting and sending me a complimentary copy?

alviamjad's picture

Why not we change the shapes of some certain ligaures, like in this case

may be No. 4 in row 1 OR No. 2 in row 2 is better option.

OR

extend the arm of 'lam' as appeared in below 15 words.

John Hudson's picture

I'm sure Mamoun has a whole list of things he would like to fix or change in the Arabic Typesetting font. Whether this happens depends on Microsoft's development cycles, the MST budget, and what their spending priorities are.

AzizMostafa's picture

... and on the possibility of fixing the flaws without generating others?!

AzizMostafa's picture

Here is One word written in 2 different styles: The right is ligature-free and the left has been cranked by the seen-kha ligature. My question is how to handle this in VOLT — forming Kha and Seen and lifting All letters on the right of Seen there and then — Save Alif of course?

titus n.'s picture

John, in an earlier post you said that inserting very narrow joining strokes is an opportunity to avoid clashes. Wouldn't it be possible to make a contextual GPOS lookup in addition to the regular vocalization placement?

John Hudson's picture

Aziz, this is achieved using the OpenType Layout 'curs' (Cursive Positioning) feature. The lookup type for this feature is a cursive attachment GPOS, defining entry and exit points for a pair of glyphs. In your second example, the cursive attachment point on the right side of the seen_kah ligature is raised from the baseline, so any glyph that attaches to the right of this glyph will be raised. This feature accounts not only for the dramatic rise in this example, but also for the gradual incline of the first example.

In VOLT, create a new GPOS lookup, and select 'Cursive Attachment' from the drop down menu of lookup types. You will be presented with input fields for first and second glyphs, and an anchor name, which is always 'exit' in this kind of lookup.

John Hudson's picture

Titus, yes, one can certainly do contextual adjustments to mark positioning. In the Adobe Arabic font, we use both techniques: sometimes we raise or lower a mark to avoid a collision, other times we insert a narrow connecting stroke to move two letters further apart. Where we have an isolated or final form, e.g. waw, occuring mid-word, we might also employ a contextual kerning adjustment if the following glyph takes a mark that might collide with that letter. So there are three techniques for avoiding problems with mark collisions.

titus n.'s picture

Thanks for confirmation John.

AzizMostafa's picture

On 29th June, 2006 , katia N. Dali asked:
I want to ask you all, how did you learn VOLT?
Does anyone of you has a manual for it?

Admittedly Say: By pretending to be a Know-it-All?!
In this way I have been thankfully learning from John Hudson while still waiting for my application to be approved (or denied) by the manager of:
http://groups.msn.com/MicrosoftVOLTuserscommunity
I was there but my hotmail has been stolen, so I have applied with a new one. Unfortunately, I did not download VOLT then...
Till re-gaining access to that High VOLTage Area, All the Best for All.

AzizMostafa's picture

Dear John, in your last reply, the highlighted "cursive attachment GPOS" in the 2nd line was mistakenly linked to http://typophile.com
Thanking you for the elaboration and awaiting for the correction.

Katia Dali's picture

hello Aziz,Im still waiting too for my application to be approved (or denied) by the manager of:
http://groups.msn.com/MicrosoftVOLTuserscommunity
I wish they accept us. actually my position in my company depends on learning VOLT.

Katia Dali's picture

Aziz, I want to ask you if it is possible to view a font that has been developed through VOLT? I want to see how it was volted?I knew that John Hudson is the developer of Arabic Typesetting font, so i was wondering if he can guide us to how to download it outside the VOLT user community site

sergeym's picture

There were few people complaining here that their application to join VOLT community was pending for a long time. So, I just went through long list of pending requests, and everybody who waited for their approval should be able to access community site now.

Thanks,
Sergey

AzizMostafa's picture

On behalf of All, I say: Many Thanks Sergeym
Warmest Regards with Flowers

John Hudson's picture

n your last reply, the highlighted “cursive attachment GPOS” in the 2nd line was mistakenly linked to http://typophile.com
Thanking you for the elaboration and awaiting for the correction.

Sorry about that. I think I left an empty href in the text, and that automatically gets linked to Typophile. I was trying to find a link directly to the part of the OpenType specification that deals with cursive attachment GPOS, but although I found the section I couldn't find a way to link to it. So you have to go to this link:

http://www.microsoft.com/typography/otspec/gpos.htm

and then do a search for 'cursive attachment' to find the relevant section.

Katia Dali's picture

Hello john, I have 2 questions for you please:
When I’m compiling my font, this compilation error pops up:”Some second glyphs are not marks in Anchor attachment lookup mark”. What does that mean?

Another question regarding the Feature “cswh”. It is said that it is applied to substitute any swash characters based on context. How is that?

John Hudson's picture

In an anchor attachment lookup, all second glyphs must be defined as marks in the font GDEF table. You set the category of glyphs in the VOLT glyph edit window. [Note that you can also define glyphs as ligatures, but you should only do so if you are planning to do mark-to-ligature lookups.]

The 'cswh' feature works like any other contextual feature. You define contextual lookups to implement context-specific swash letters, as distinct from the 'swsh' feature which is used for non-contextual swash substitutions. This is an example of redundant features based on lookup type, which Adobe registered early on to limit the expected lookup types for each feature. Practically, the 'cswh' feature isn't needed, because you can put the contextual lookups in the 'swsh' feature alongside the non-contextual lookups.

Naji's picture

Dear All,
I've designed a customised type face in arabic and latin with Fontlab, then I've passed it through microsoft volt. End result, I have a truetype font that works perfectly on PC but not on mac. Does anyone have an idea how to make it work on mac please? I've read that arabic opentype fonts work perfectly with Adobe MEA, is it only text edit who is unable to combine the arabic letters? I really need help and I'll be most greatful. Naji

Katia Dali's picture

thanks john, that was very helpful

Katia Dali's picture

hello naji,
actually that's a common problem. but you said you "passed it through Volt" do you mean you volted it? Im working on an Arabic Font developed through font lab and trying to Volt it in order to avoid having different results on different computers (PC. & Mac) that's why im very intereseted in what you are talking about. Anyways i wish that John Hudson have the solution for this problem.
by the way are you lebanese Naji?

John Hudson's picture

As discussed in the other thread Naji started on this subject, Mac Arabic support is currently stuck between two different implementations. They have started supporting OpenType Layout, and (strangely) give preference to OTL tables over AAT tables if both occur in the same font, but their OTL support is not advanced enough to handle Arabic. AAT Arabic works very well, but it is relatively difficult to develop AAT fonts. For the time being, you have to ship separate OTL and AAT fonts, and there are some things that are possible in OTL that are not possible in AAT and vice versa, so if you want cross-platform compatibility you have to limit yourself to the things that both formats can handle.

Naji's picture

Thank you John for your help. And K.D. what John said is the only solution. My volted font works perfectly with adobe applications on mac but not on pc, on mac it seemed much more stable. On the other hande I kept a version (not volted) of the font on PC that works with all applications (office and adobe). The ideal solution to have a font that is functional in all applications that support arabic on mac is to have it in AAT, for that you'll need a developer and not a designer!

P.S.: Yes I am lebanese

John Hudson's picture

In Adobe apps, you should not see a difference betweeen support on Windows and Mac, because Adobe use their own text and layout engines, not the system engines. The Middle East versions of Adobe apps should treat OpenType fonts identically on both platforms.

Katia Dali's picture

Hello john
I have 2 questions for you please:
1-I have this compilation error: “glyph can not be bound to a glyph set. Please check the expression and all the glyph groups it references".
2-I have this glyph صلى الله عليه وسلم written in a certain format, shall I put it under ligature the same as الله and if so how to create a substitution for it?

I dont know hot to attach the words صلى الله عليه وسلم for u to see how it is being designed.

sergeym's picture

1. This message means that you spelled one of the glyph names incorrectly and VOLT can not map it to particular glyph index. Check all the names in your lookup (both in substitution and context).

2. Yes, you can put this into normal ligature substitution. Do not forget to include space glyphs and put it in front of shorter ligatures.

Thanks,
Sergey

John Hudson's picture

Katia, I do not normally treat ﷺ sallallahou alayhe wasallam glyph as an OT ligature, since it is a specialised representation, very distinct from how the words would appear in normal text. If I were to use a ligature lookup for this, I would certainly use the Discretionary Ligatures 'dlig' feature, not the standard or required ligatures features, since users may or may not want this form in specific situations.

Unicode separately encodes ﷺ -- along with several other Arabic 'word ligatures' -- and I would generally recommend that users directly encode this form as a single character, as I have done in this message (U+FDFA).

[Sergey, I thought there was a limit to VOLT ligature input length? Are you sure it is possible to create a ligature lookup that will handle input of 18 glyphs?

John Hudson's picture

Regarding the VOLT error message, 'glyph can not be bound to a glyph set': if you have imported a lookup or project from another font source, this message indicates either different glyph name conventions/spellings or that your present font lacks one or more glyphs that exist in the source font.

sergeym's picture

[Sergey, I thought there was a limit to VOLT ligature input length? Are you sure it is possible to create a ligature lookup that will handle input of 18 glyphs?]

When you define how many components your ligature consists of you are limited to 16 components (pretty much aritfical limitation, just to keep number of elements in the combobox reasonable). So, if you have very long sequence, you wont be able to correctly place marks on individual components - which you would not do anyway in this particular case.

But ligature lookup itself does not have any limitation on length of glyph sequence being substituted. To be sure, I just succesfully tried replacing 60 glyphs into single ligature :).

Katia Dali's picture

thanks john and sergey, yes i guess you was right regarding missing a glyph. and regarding the ligature صلى الله عليه وسلم, i will try to treat it as a single character and see what I get.
thanks guys.

Katia Dali's picture

for mark-to-base positioning is it better to use Anchor or cursive attachment operation?
also please for ئ ؤ shall I treat them as simple glyphs or is it better to consider them as ligatures?

sergeym's picture

for mark-to-base positioning is it better to use Anchor or cursive attachment operation?

mark-to-base, mark-to-ligature, and cursive attachment are all based on aligning anchors of two glyphs. Difference between them is that mark attachment will change offset of the mark and cursive attachment can change advance width of the first glyph and vertical offset of the second. So, for mark attachment, mark-to-base is the right lookup type.

also please for ئ ؤ shall I treat them as simple glyphs or is it better to consider them as ligatures?

There is no clear definition in OpenType specification of what is ligature and what is component. But clasifying glyphs as ligatures with several components is only useful when you plan to attach marks to each component separately. So, number of components is usually a number of base glyphs in the ligature.

Your case is similar to Latin letters with accents, you do not need several components and you can define these glyphs as simple.

Thanks,
Sergey

Katia Dali's picture

it is known that fontlab makes a redundancy for isolated characters, I mean isolated glyphs appear twice in the Volt glyph editor window. now the question is: do i have to enter both glyphs in the same lookup? in other words how to deal with this when adding a certain lookup. lets say i want to create a substitution lookup for medial characters, the ba character for example, but since UNI0101 AND UNI1002 both stand for isolated ba, im adding them both:

UNI0101 -> bamedi
UNI1002 -> bamedi

Katia Dali's picture

by the way thanks sergey for replying instantly, and thanks for john too.

alviamjad's picture

You can use Glype Groups in this case, for example make a glyph group with a name say 'BayReplacement' and add all the glyphs you wish to change UNI0101, UNI1002 etc:

Then in Lookup window whenever you needs call the whole group by writing;

BayReplacement -> bamedi

You don't need to type them again and again.

Katia Dali's picture

any answer for the above question?? pleeaaase

Katia Dali's picture

hello alviamjad,
sorry but you didnt get my point. I know that i can create glyph groups, however what i meant is that isolated glyphs always occur twice in the glyph editor window, so how to deal with this when creating substitution lookups?
i.e. I have two isolated Alefs and i want to substitute the isolated Alef with final Alef, shall i substitute both isolated Alefs or it is enough to substitue only one and the second will be substitued automatically?

Katia Dali's picture

with respect to mark positioning, sometimes after I'm done with positioning the marks, some are misplaced and i have to re-position them again, though im locking second anchor, or do i have to lock both?

John Hudson's picture

Katia, in answer to your first question:

What you have, I presume, is the isolated character from the Unicode Arabic block (e.g. uni0628, beh) and a corresponding, redundant isolated character from the Arabic Presentation Forms (e.g. uniFE8F). The latter isn't necessary at all in an OpenType font (you only need character mappings for the Arabic block characters; everything else can be handled by glyph processing), but such redundant mappings might be used if the font encounters older software that uses presentation form mappings for Arabic shaping. If the redundant isolated characters are supported in the font using distinct glyphs, I would say that it doesn't really matter whether both are mapped in shaping features like init, medi and fina. OpenType Layout presumes a Unicode text handler which processes Arabic text using Arabic block codepoints. It is quite likely that such a handler will apply compatability mappings to Presentation Form characters encountered in text before glyph processing even begins, so the likelihood of e.g. the init feature needing to know what to do with uniFE8F is remote. That said, I don't think there is any harm in providing a double lookup.

John Hudson's picture

Katia, in response to your second question:

The GPOS window can be a little finicky, but you shouldn't be getting the problem you describe. Are you being careful to specify unique anchor names, and not to reuse anchor names. One of the easiest ways to mess up previous work is to reuse an anchor name and change its position, which will affect any existing anchor positioning lookups using that anchor name.

You should only need to lock the second glyph.

Katia Dali's picture

first thanks for the first question john "you are saving my life :-)"
I will make sure to thank you face to face when I visit my sister in Calgary/Alberta.
but with respect to the second question, do you mean by the anchor names, the glyphs unicodes under "position first"? if this is what you mean then sure they have unique names. and if it isnt what you mean then please tell me.
thanks again

Katia Dali's picture

by the way John, i received the Unicode Guide provided by linotype, so now i understand what you meant.I think i have to do more research on how fontlab works. Actually Im a database programer and i have nothing to do with fonts and grphic design, but I got a good offer to work as a font developer so here I am.

John Hudson's picture

Katia, here is an example of what I am referring to in VOLT's GPOS window. The red underlined anchor names must be unique for any different mark positioning. So, for example, if I have a second lookup that adjusts the position of marks contextually, e.g. raising or lowering them when preceded by certain letters, then the anchor names in that lookup could not be 'above' and 'below' as they are in this lookup, because any changes to positioning for the anchors named 'above' and 'below' will propagate to lookups using those anchor names, including work that I have already done.

When you first create a GPOS anchor attachment lookup, the anchor(s) in it will be named 'default'. The first thing you should do is change this name to something specific to the lookup.

John Hudson's picture

PS. Calgary is a long way from where I am (about 720 kilometres), but if you do come as far as Vancouver, let me know. I'm on an island nearby.

AzizMostafa's picture

29 June, 2006, John Hudson said:
... I’d be interested in writing a proper VOLT manual if I had time and someone were to pay me.

First, I have come across a font utility inside Sinasoft.com package that combines the functions of Fontlab and VOLT. This 150U$ Utility is intuitive, but unfortunately not compatible with M$ and Adobe Products.

2 John, please consider this proposal:
Soon after supplying my (5+1) True Type Fonts, John starts transforming them into a single OTF and Aziz does the timely feedback.
Meanwhile John goes on writing the steps involved in the Font Generation and Aziz does the translation — concurrently step-by-step form start to finish.
In this way, we will have 2 comprehensive VOLT manuals—English and Arabic— and Uncompromising Arabic OTF?!
Terms and Condition— including time and cost— are subject to discussion and will be published here when finalized in the hope that they— Font and Manual— will find the Right Publisher they deserve.
Make it Together?! The earlier, the better?!
Sincerely

John Hudson's picture

Aziz, it is a nice idea in some ways. Unfortunately, I really don't think I have time, and am unlikely to find time given how busy I am with other projects. Also, this isn't really how I would like to do the manual. Writing and font production involve such different ways of thinking that I find it very difficult to do both at the same time. I've tried in the past, and it just makes me grumpy.

AzizMostafa's picture

Nothing makes me grumpy save making John grumpy.
Hope John will consider working out the same proposal in 2 steps:
Building then Documenting...
Yours for Good Projects

Katia Dali's picture

OH now I understand what you mean, sure I replaced the dafault anchor names (mark above ligature, mark below base etc...), but you are right I put the same anchor name in 2 lookups, I thought it wasnt a problem.
thanks john.

Ps. I know that Vancouver is way far from Calgary, actually I visited BC but i couldnt continue to vancouver because I didnt have much time.you are really lucky to live near Vancouver its like heaven.

Katia Dali's picture

in Mark to ligature Anchor attachment we have the shaded and the bold mark, which one should be located on the desired letter of the ligature? And how to adjust both marks as desired, what is happening is that when I move one the other is misplaced (they are proportional?).

Also please John: The designer forgot to include two glyphs in her font, now she designed them but how shall I import them? I went to the import glyph window but it didn’t work with me.

Ps. Is it one of your duties to help us John? Or are we interrupting you every now and then.

John Hudson's picture

In the mark-to-ligature lookup, the black mark indicates the mark to be positioned on the current component letter; the grey mark indicates the position of the mark relative to the other component(s). So consider the example of a lam_alif ligature: in the Glyph Edit window you have classified the lam_alif as a ligature with 2 components. In the mark positioning window, you can select the individual components using the drop down list in the top right corner of the window. In this case, the lam is component 1 and the alif is component 2. The first thing you want to do is to lock the position of the second glyph (the mark) so that it only moves relative to the first glyph (the ligature) not relative to itself (i.e. not relative to its zero-width). This is probably what you have failed to do if you are seeing the grey mark moving when you move the black one. Once you have positioned the mark on the lam, go to the component drop down list, and select 2. The mark you have positioned on the lam will become grey, and the one you are about to position on the alif will become black. There will always be a number of marks equal to the number of components.

For your other question:

1. Export a VOLT project file (see export menu). This is a text file that contains all your glyph, lookup, feature, glyph group and option settings for the font.

2. Add the new glyphs in FontLab (I recommend adding them at the end of the glyph set to avoid having to reorder within the VOLT project).

3. Generate a new font from FontLab with the additional glyphs.

4. Open the new font in VOLT, and go to the import menu to import the project file you exported earlier.

5. Go to the Glyph Edit window and ensure that the glyph order is consistent with the imported names, classes, etc. Go to the new glyphs and give them appropriate names.

6. You are now ready to continue working in VOLT.

PS. No it isn't one of my duties.

Katia Dali's picture

if it is not one of your duties, then i would like to thank you for your kindness and patience. I owe it to u. and sorry for the interruption.
I just have one last question that can be answered by yes or no:
You told me before that: “If the redundant isolated characters are supported in the font using distinct glyphs, I would say that it doesn’t really matter whether both are mapped in shaping features like init, medi and fina. OpenType Layout presumes a Unicode text handler which processes Arabic text using Arabic block codepoints. It is quite likely that such a handler will apply compatibility mappings to Presentation Form characters encountered in text before glyph processing even begins, so the likelihood of e.g. the init feature needing to know what to do with uniFE8F is remote. That said, I don’t think there is any harm in providing a double lookup”.
Is this applicable to mark positioning too? I mean do I have to position marks over redundant isolated characters? Or is it remote?

John Hudson's picture

To be on the safe side, yes, I would apply mark positioning to the redundant isolated characters. There is the chance that someone hard encodes one of these characters in a document, and so the glyph may occur in combination with a mark.

John Hudson's picture

Aziz, the key phrase in my comment regarding a VOLT manual was 'if I had time'. The fact is that I don't have time, neither to help you with your fonts nor to write up the process. I have the knowledge I need now to write the manual -- I've been using VOLT for years, in some very complicated projects, and there isn't a lot I don't know about the program --, but I simply do not have time.

AzizMostafa's picture

In appreciation to John's time and knowledge, I present these few lines:
He volunteers information whenever asked, but
When I needed him, he apologized for being a single-handed,
Then when I asked for the single hand, Shortage of time, he replied.
Is it my fault to be a single dimensional in my sight?

John Hudson's picture

Not single-handed, and indeed
How could I juggle unimanual?
I understand your pressing need,
but must these balls keep aerial.
So please be not with me annoyed:
I have two hands, but both employed.

Katia Dali's picture

dont say this Aziz, I went through lots of Typophile nodes and noticed that John helped you all, WHILE HE DOESNT HAVE TO, and you ,personally, said before:” Admittedly Say: By pretending to be a Know-it-All?!In this way I have been thankfully learning from John Hudson”. so there is no need for what you said above. I dont know John personally but Im grateful that he helped me and frankly speaking "he is such a kind person".

AzizMostafa's picture

I think K.D misunderstood me and/or John.
John is John. I like him and I like you too.
By the way, Katia, how many characters does your font have?
Have your read my last posting here?
http://typophile.com/node/19348
Keep posting your Questions, Feedback and Comments.

Katia Dali's picture

hello Aziz,
sorry if i misunderstood you.
my font is made up of 539 characters.
yes i read the posting and I like the qoranic font you made and I wish you find a sponsor soon.
Actually I work in a graphic design company (Almohtaraf Assaudi), we won the First and second prize of linotype's Arabic Type Design competition 2005.

Katia Dali's picture

I dont know why compilation is failing without receiving any compilation error msg. if somebody knows please tell me.

John Hudson's picture

If VOLT compilation fails with no specific error message, it is most likely a problem that requires you to use extension lookups, format 2 lookups for pair positioning, or both. Go to Options under the Tools menu. There are two 'Compilation' options:

[ ] Use extension lookups
[ ] Use PairPosFormat2 for pair positioning

Turn on the first of these options, and try to compile the font. If it still will not compile, turn off the first option and turn on the second option. If the font will not compile with the second option set, turn on both options, and try again. If it still won't compile, let me know.

Katia Dali's picture

it seems that i will not be able to survive without you john.
unfortunately i have bad news: I did what you told me but still "Compilation Failed" and im going crazy over here. I went through the whole project, I checked everything, and everything is perfect. I dont know what the problem is.

Katia Dali's picture

but john, i put the smcp feature, for english caps, with the rest. I mean in the Arabic language feature tree. is that a problem or the compilation failure has nothing to do with that?

John Hudson's picture

That should not affect compilation. I'm going to put you in touch with Sergey Malkin to see if he can help you debug the problem. Please contact me by email at john[at]tiro[dot]ca

sergeym's picture

You can always find me here, I am just not as fast as John answering your questions. You can send me email to sergeym_at_microsoft_com.

First you may check that VOLT installation is not broken, by taking some small font and trying to compile it.

VOLT may be exceeding maximum table size for individual lookup, most frequently kerning and sometimes mark attachment. In this case, using flags that John suggested in his responce may or may not help. Breaking into multiple lokups can help. You can find offending lookup by deleting them, starting from most suspicious.

Thanks,
Sergey

John Hudson's picture

Sergey, Katia sent me her font and I figured out the problem: it wouldn't compile because anchor names had spaces in them. Perhaps you can add an error message for this?

Katia Dali's picture

Ok Sergey I will make sure to contact you next time.

Katia Dali's picture

I opened a font and some marks have 3 unicodes:
i.e the shedda has this Unicode:U+00AF,U+00F8,U+O651 (which is very strange)
Also when I import additional glyphs, they appear on the glyph editor without any Unicode, even though in fontlab they have their Unicodes. Anyone knows why?

sergeym's picture

When new font is opened in VOLT, it is importing cmap table. During that it is looking at all cmap subtables to collect as much mappings as possible. Usually, all subtables are consistent. You may have got one with incorrect encoding in it, but I do not remember anybody experienced ths problem with their real fonts.

What are all subtables in your font? You can go to Tools\Options menu to get the list. Was this font generated by FontLab?

Thanks,
Sergey

Katia Dali's picture

in the CMAP table I have:
Platform 0 1 3
Encoding 3 0 1
Format 4 6 4

yes my font was generated by fontlab

AzizMostafa's picture

First, I hope the Duck has gone paddling progressively?!
Thanks to the Teachers and Good luck to the Paddling Duck.

Just one question:

In both M$ and Adobe Arabic Applications,
1 Tanweens (// and 69)) do not change letters to their final forms.
2 Full Justification is carried out by adding Kashida at the middle of words.

Is any of these 2 alternatives VOLTable:
1 Making Tanweens as non-joiner Marks, and/or
2 Swashing (prolonging) the final forms of letters instead of Kashida?

Any hint is highly appreciated.

sergeym's picture

1. I can not comment on this as I do not know enough about Arabic. We did not hear any requests/complaints about current behavior of these marks. Do you have any evidence that shaping should be enforced in this case? If tatween appears at the end of the word anyway, won't last letter be in the final form anyway? If it is a choice of the user, it should be implemented on the character level, possibly using zero width non-joiner. Especially if it changes meaning of the text.

If you think it really should be done uncondtionally, my guess is that this would be part of Uniscribe rules. But font can also be tweaked if it is needed. Contextual lookups can adjust the forms of surrounding letters.

2. Justification is higher level feature than shaping individual character runs. OpenType layout rules do not have any information about actual width of the line and what other content (from different scripts) is present. There is no standard protocol defined between font and text layout engine to achive what you want. Is it would exist, then VOLT will be able to implement it but so far it can't because of lack of the rules that should be followed.

Thanks,
Sergey

sergeym's picture

Ok, I now found more information about tanween and I think I understand what you are asking for. Tanween is possible to do on font level without changing Uniscribe, using contextual substitution based on first letter of following word. One thing that will not work is context not working across the lines, because each line is shaped independently.

Working across the line is on higher level than a font, beyond OpenType layout. As with justification, there should be a protocol defined between higher level engine and the font (e.g. through applying particular feature) to communicate intended shaping.

Thanks,
Sergey

AzizMostafa's picture

May God bless your Clicking Finger, Sergey.
> We did not hear any requests/complaints about current behavior of these marks. Do you have any evidence that shaping should be enforced in this case?

No complaints but enforcing Tanween Shaping will not only prevent connection with the following word in case a space goes missing but will also lessen the importance of preceding the following word with a space as well.

> Tanween is possible to do on font level without changing Uniscribe,
using contextual substitution based on first letter of following word

Contextual substitution based on first letter of following word?!
Since the following word is preceded by a space, then am I right to conclude that:
1 Justification is not possible by swashing though (Overlapped) Swashing is VOLTable.
2 en and em spaces (narrower or wider), are VOLT-Controlled also?

Hope Uniscribe Rules will be modified to make life easier for VOL(un)Teers.

AzizMostafa's picture

Just rewarding the last posting: If Contextual substitution based on first letter of following word is possible, is it possible then to:

1 VOLT (Overlapped) Swashing based on first letter of following word, and
2 Adjust the spacing between the last letter in a word and the first letter in the following word in increments of en space for example.

Many Thanks in anticipation

Katia Dali's picture

>I hope the Duck has gone paddling progressively?!
Thanks to the Teachers and Good luck to the Paddling Duck.

First,Im proud to be a paddling duck Mr. Aziz.
second, Im a holder of a Masters degree in Information system Technologies, and there is no harm if someone learns new programs and emerging technologies.
3rd, many thanks for my teachers Sergey and John.

ps. I can be your teacher in Information systems if you want dear Aziz!

AzizMostafa's picture

Sorry, I think you misunderstood me again, Ms Duck! Or Duckling?!
K.D. starts with K and ends with D, but Duck starts with D and ends with K?!
So the difference is quite clear.

Proud to know the definition of "Information" from the holder of a Masters degree in Information system Technologies.

Apologizing again and Thanking you in advance as many times as ...

AzizMostafa's picture

Dear Friend,
Do you find any difficulty in walking through this getting-very-long topic?
Just look here
Happy Navigating with Flowers

Katia Dali's picture

hello Aziz,
>Sorry, I think you misunderstood me again, Ms Duck! Or Duckling?!
maybe the misunderstanding goes to our Arab nature. but this doesnt excuse your offensive personality.
>Proud to know the definition of “Information” from the holder of a Masters degree in Information system Technologies.
Informaton in our dictionary is simply the data that we collect, store and process for future use.

AzizMostafa's picture

Deleted due to repetition

AzizMostafa's picture

1. Typophile Friends have indirectly answered the last 2 questions here
___________________________________________________
2. Katia, we — Communication Engineers— define Information as the logarithm of the inverse of the likelihood (p)robability) of the news (data). Mathematically, Information (in Bits)= 10 log 1/p

So, a likely event carries no information, like the sun will rise tomorrow.
Similarly, the less likely the event, the more informative!
Accusing me of being Offensive is highly informative (to me at least)?!
Though I lived in Iraq for 27 years, I have no Arab Origin.
My Father was from Turkey, Mother Persian, I am a father of One Malaysian Son and 2 Iranian Daughters. Can communicate in English, Malay, Arabic and Persian, but unfortunately not in Turkish!
All the Best with Flowers

Katia Dali's picture

Wow, I’m so impressed Aziz. You have such a weird combination, but it’s nice though.
Excuse my curiosity but how can a communication engineer be interested in designing and developing fonts?
I’m still 25 years old and as u know I hold a Masters degree in Information systems. I live in lebanon while my family work and live in the ivory coast. after university all I wanted was to work in my major, I worked as a freelancer, I worked with the UN, etc. finally i ended up working with fonts, which I found not interesting.

ps. the offensive personality is what you showed on this node, if you have a different personality then accept my sincere appologies.

AzizMostafa's picture

> ... I ended up working with fonts, which I found not interesting

Well Katia, Font Making is like Baby Making in the womb of a lady.
It starts with pains and ends up with birth pangs to deliver a well-made one?!
Some ladies hate it. Others love it. Still others pay thousands of U$ to experience it.
But for sure, it is the companion that makes the journey sweet or bitter?!

University degree just helps you step to the bottom of the ladder and you have to climb up to the top. There, you learned nothing but problem-solving techniques applicable to Info Systems and Fonts as well. So, it is you who translates that into workable ideas wherever and whenever needed from you. Only there and then, you will discover yourself...
But keep in mind that " A creative ABC Teacher is better than a useless Ph.Doctor."

Apologies and Thanks with Flowers.

P.S. Katia, please take note that I wont answer any more off-topic matters.
Feel free to email me.

Katia Dali's picture

thank you Aziz, dont worry I know lots of PHD loosers.
I know we are not here to chatt, I was just surprised to see a communication engineer designing fonts.
best wishes.

marsad's picture

Hello every one.
your posted comments were very useful. thanks a lot.
I have a problem with the 'mset' feature:
After opening an existing font, editing it and compiling it (in Fontlab Studio), I dont know why the 'mset' feature dosnt work in the resultant font. Can anyone help me??
Thanks a lot again.

AzizMostafa's picture

RahmaT, your font handled by Thomas Milo?!
Still discussing it with Thomas Milo, please keep watching:
http://29letters.wordpress.com/2007/01/15/arabic-calligraphy-written-by-...

AzizMostafa's picture

Double Post exploited for Quick Navigatiion + Flowers
http://typophile.com/node/20638?from=0&comments_per_page=5000

Thomas Milo's picture

John Hudson wrote:

"Although all my own Arabic work has been in OpenType, I’m pretty convinced that only an approach like Tom’s can result in optimal mark positioning. The downside of such a system is that it tends to be very slow: not something you would want to use for, e.g. e-mail. But in the context of book production, it is the best thing available."

This was not based on actual observation. The core code for ACE was written in 1984 for 4Mhz processors :-)
See: http://laits.utexas.edu/rfpit/texts/Mimesis.html

Today it runs on 1Ghz, 2Ghz or even faster computers. ACE has never been slow, and it's certainly faster than OpenType.

Moreover, what's wrong with elegant email. Ruqah, one of our projects, is perfect for (e)mail. Anyway, ACE is technology, not a specific font.

Thomas Milo
DecoType
www.decotype.com

saleem Ali's picture

Dear John Hudson,

Please tell me ligature bari yeh before init, medi form join the ligature, joint point, what you know any rule in volt please provide detail, i thankful to you whole life. My imge show above the problem.

Best regards,

Saleem Ali Ghalib

saleem Ali's picture

Dear John Husson,

Diacritic mark is not apply on ligature plz describe solve the problem.
I am marking glyph definition ligature 2 component and use anchor attachment but it is not working on MS word. Happening situation is fig: 2, fig:3

My previous post i learned lot of works in volt and succeed init, medi and fina change the baselineshift and word rising the desired ligature as fig; 1 i thank ful to you but the diacritic mark is not working on it. What happened.

I need to know if there is a way to de-ligate the Lam-Meem ligature when I put a mark on the Meem so that, when I put the mark for the Meem, the ligature is back seperated to Lam (initial) and Meem (medial), so the mark doesn't like it's the Lam's.

Plz describe the detail with screen shot if you don't mind i understand that is not your job it is merly your kindness yours suggestion is very helpful for me, font is very flat that has a great impact for urdu audience, designer support layout font.

Thanks,

Saleem Ali Ghalib

John Hudson's picture

I believe the problem is that your cursive connection GPOS feature has the marks flag set to something other than NONE, probably all. Every OpenType Layout lookup has a flag that indicates whether all marks, no mark or a class of marks should be processed as part of the lookup. For features that involve interaction between adjacent letter shapes, such as ligature GSUB features and cursive attachment GPOS features, you want to set the marks flag to NONE. This means that marks in the glyph sequence will be ignored by this lookup. [Note that, obviously, this means that mark glyphs need to be classified as Marks in the VOLT glyph data.]

John Hudson's picture

Re. the lam_mim ligature:

I'm guessing that there are a couple of different situations in which you want this ligature not to form; when any mark follows the mim but perhaps also when a mark occurs below the lam?

What you need to do in this case is create some separate lookups for this ligature, and a class for lower marks called e.g. 'marks_below', and another class for 'all_marks'.

Your first lookup will form the ligature only if no below mark follows the lam. This is done by putting the 'marks_below' class name in the Process Marks field:


___

The second lookup decomposes the ligature when the mim is followed by a mark. This requires the Process Marks field to be set to ALL, so that the 'all_marks' class will be recognised in the context string:

saleem Ali's picture

Dear John Hudson,

Thank you very much for your immediate response and your kindness will make me a better font designer in future. Again thank you, good men spread the knowledge. I will get more information about volt feature time to time whenever trouble shoot.

Best Regards,

Saleem Ali Ghalib

mjins2's picture

since its initial idea - which interestingly grew from the sanctum of founder stefan siegel's shoreditch kitchen walls into a working databa -se of over 6,000 designers spread across 88 countries - the dedicated designer platform has certainly done what it says on the tin. a global howroom where trend scouts, fashion insiders and stylists are able to source talent, it isn't just an online shop, it's a veritable fashion spring- board, saturater with the ideas of tomorrow's designers, and eagerly digested in the process too. ladiva attractive layering of colorless enjoy! cody colorless casual style is so attractive. seemed to rock seemed unvarnished. we'll tiresome colorless chic the field is variegat with all kinds of flowering plants. and she worked a skirt and blouse since its initial idea which interestingly grew from the sanctum of ounder stefan siegel's shoreditch kitchen walls into a working database of over 6,000 designers spread across 88 countries - the dedicated designer platform has certainly done what it says on the tin. a global showroom where trend scouts, fashion insiders and stylists are able to source talent,
it isn't just an online shop, it's a veritable fashion spring-board, saturated with the ideas of tomorrow's designers, and eagerly digested in the process too. ladiva attractive layering of colorless enjoy! cody colorless casual style is so attractive. seemed to rock seemed unvar-nished. we'll tiresome colorless chic the field is variegated with all kinds of flowering plants. and she worked a skirt and blouse

saleem Ali's picture

John Hudson,

i am waiting for your response. last day mail for your given ID.

saleem Ali's picture

i work on Urdu Nastaleeq font but on working lot of problems any one help me.
My font contextual recognized shape is not working on Ms office.
adobe illustrator working very fine some time unexpectedly quite what happened.
i am very upset lot of work on it. thanks lot.

Karl Stange's picture

It may help if you start a new thread specific to the problems you are encountering.

saleem Ali's picture

I am working on Nastaleeq urdu font it is not contextual alternate are not get what happened MS work .doc file attached the problems highlighted in circle. insert image error if you want see my problem give your email.

AzizMostafa's picture

Karl & saleem, this thread is specific to Nastaleeq :
http://typophile.com/node/82934
Stay tuned with developments?!

saleem Ali's picture

Thank you

Aziz Mostafa

saleem Ali's picture

Are otf font with arabic feature work on adobe in design and illustrator Mac and PC computer?

Karl Stange's picture

Are otf font with arabic feature work on adobe in design and illustrator Mac and PC computer?

Based on Adam Twardoch's recent thread: Adobe InDesign/Illustrator CS6: get Arabic/Hebrew support and extra languages for free I would think that the answer is yes, but not out of the box, so to speak. Prior to CS6 I think you would need to explicitly purchase the ME version.

oldnick's picture

Karl? A link to INDD1? What a total disaster that was: it totally screwed up font-handling with every other Adobe program, and I had to uninstall it, then rebuild Illustrator and Photoshop to undo the damage.

No wonder I can't get any help with my spacer problem…although, IF I ever get the problem solved, I probably ought to look into a cloud-based subscription model. Why sell each set outright for $3, when I could charge users $1 each time they use a set? A perpetual money machine! SWEEEEEET!

Karl Stange's picture

Karl? A link to INDD1?

Oops! Looking at fixing that now...

Karl Stange's picture

I think it should be fixed now, I am hit and miss with the internal linking to posts, which could have something to do with an intake of red wine. As for InDesign 1, I only used it briefly and was transitioning from Quark 4.11, so there was a whole world of hurt involved.

AzizMostafa's picture

Oldnick + Karl Stange

Tracking the Old(nick) sounds St(r)ange?!

Karl Stange's picture

Oldnick + Karl Stange

Tracking the Old(nick) sounds St(r)ange?!

I am not at all familiar with other forums but I like the way that relationships develop on this one, it feels like a local (pub) where everyone knows your name, or at least your handle. I have yet to decide whether that is a good or a bad thing, it generally feels good though.

Pushing this back to the topic (at least a little bit), are there any clearly established guides to using VOLT, independent of this and Microsoft's site?

John Hudson's picture

Not a full VOLT guide, but perhaps a useful: my step-by-step FontLab-to-VOLT workflow documentation.

Karl Stange's picture

Thank you, John. There are several very good ristrettos with your name on them the next time you are in London. A good bottle of red if you like too.

John Hudson's picture

Sounds good, Karl. I should be in London 13-15 November.

Karl Stange's picture

That works for me, I will email you off site to arrange something.

ME Q's picture

1

saleem Ali's picture

How i use single Adjustment in Arabic font Plz describe in detail. prompt response i will be appreciate you.

saleem Ali's picture

Dear John,
Plz above post consider.

saleem Ali's picture

I have very difficulty in this situation word is overlaping each other. My problems is to see below how i calculate width in volt Single adjustment menu plz answer this problems: first is" kay inital and bari yeh fina, lam init, middle hamza and yeh fina Meem init, jeem meddle dochashmi hay and bari yeh fina" same as other words so you can see. How i solved and how calculate single adjustment menu table width define. I will be appreciate for your prompt action.
pic

John Hudson's picture

Yeh barree is very difficult in OpenType, because there is no way to kern the yeh barree against the letter with which it is colliding on the right, because of all the intervening letters. OpenType GPOS simply isn't a good format for handling this kind of problem (which is one that I will be discussing in my presentation at TypeCon next week). You can only kern adjacent glyphs, so in order to handle these situations you would need to have a contextual kern between the final letter in the previous word and the following space glyph, in which the context is everything up to and including the yeh barree. It's a nightmare. Also note that some browsers treat each word as a separate glyph run, so context lookups across word spaces might not work even if you made them. As I said, a nightmare. Oh, and if you were to build all of the separate contextual lookups necessary to handle all the variable spacing contexts, chances are that you would overflow the GPOS subtable boundaries and the font wouldn't compile. Did I mention that this is a nightmare?

Bahman Eslami's picture

With the john's comment I think you have to come up with a design solution. That would be designing a shorter Yeh baree when the context behind it is short. So when you have a short word, the yeh should be substituted with a shorter yeh. @john is it possible or it's a nightmare too?

John Hudson's picture

That's certainly an easier solution technically, Bahman. We've done this sort of thing in non-traditional typefaces to avoid having the yeh barree collide with dots or marks below preceding letters. But in the traditional styles, how much do you want to corrupt their norms in order to accommodate technological difficulties?

Syndicate content Syndicate content