what are the advanteges of FDK over VOLT and VOLT over FDK????
VOLT has a GUI (to throw in another abbrv), AFDKO -- which I assume you mean -- doesn't have one. On the other hand, I can't really work with VOLT, GUI or not. It assumes quite a lot of background knowledge or something. There are just a few reasonable tutorials, and from the barrage of questions with 'VOLT' in the subject line in this forum you can derive how clearly written they are ...
AFDKO, on the other hand, has been advertised as the bee's knees if you're into scripting and command lines. Well, I'm into that, so with a little help from the accompanying documentation I'm pretty much able to make it sit up, beg, and occasionally roll over and play dead. MakeOTF has a few peculiarities (such as insisting on a 'registered family name'??), but the latest version also comes with an updated TTX, and that gives more control over a font than a mere mortal could ask for, including even larger ASCII documents to wade through. I've just successfully compiled a font with MakeOTF, despite a large wad of warnings, and was able to put remaining finishing touches into a TTX dump.
Since both are free, just install both of them and see what works for you.
FontLab is built upon the ADFKO (not yet the very latest version, but I'm sure they will announce clearly and loudly when they do) but all the interesting OTF stuff is still done by typing in commands. DTLs OT Master (full version) allows you to just type in the required values -- although you still need a good background in Opentype to know what goes in which edit field.
On the subject of GUIs, I'd be sorry not to mention [[http://fontforge.sourceforge.net/|FontForge]] -- it's also free, and from what I have seen, you can do vast amounts of 'coding' in a GUI environs. A minor drawback is that it's Linux based (I think it should work just fine on a modern Mac OSX).
[Edit] Almost forgot: traditionally, VOLT works best with TrueType fonts, and ADFKO with CFF (Postscript) fonts, although both created valid OTFs. However, there are tricks to use CFFs in VOLT; and its major feature, being able to add cursive, mark-to-base and mark-to-mark features to fonts (needed for accent positioning and scripts such as Arabic) has finally been integrated into the last ADFKO.
Ok, let me clearify my self alittle more.
I use volt for my projects for hebrew font.
now, hebrew fonts are the most complex scripts to develop.
Currenly i am using over 45 OFF features and over 200 lookups and 1000ns of context conditions
As the hebrew font fully supports diacritics and candilation marks.
grammer distinguish of sheva na nach - dagesh kal hazaq ect' ect'
+ it supports grammaticly removing the diacritics and inserting letters replacing these diacritics
so as you can C my project is hug.
lately i am having difficulties compilng the font for the project is super large and it seems that volt has a code block limitation and cannot handle this complexity.
for now i am still managing to optimize my project in verious ways, so for the mean while a can still compile my projects but i fear for the near future.
until now Adobe FDK was not an option because i use mark to base and mark to mark.
but i am wondering if this is a VOLT limitation that could be solved with FDK or is it an open type limitation.
mark to base, mark to ligature and mark to mark are now supported AFDKO 2.5
and thats why untill now FDK was not an option
and now after supporting these features it is an option.
so now that it does support these features
i am asking does FDK also hav a code block limit???
Did you activate the option to make use of extension type lookups?
Not sure if this is the problem but it looks like you need two split some subtables into multiple ones. There is a subtable size limitation of about 65k which is a limitation of the OT layout tables.
I do not see a reason why not to use AFDKO. Since the problem -- if this is your problem -- is related to OT layout tables rather than VOLT/AFDKO, you'd face it with both of them.
There is a subtable size limitation of about 65k
When I read the GPOS Opentype spec, I understand that the limit is 65536 records, not 65536 bytes (uint16 as well as offset are 16 bit integers).
I dont think I ever reached 65,536 Records
The font after compilation is almost 300KB the clean TTF is around 130KB
a difference of 170KB between clean TTF and compiled TTF.
Here is a question for John Hudson or the MSVOLT devlopers (if they write in typophile)
are there any code limitations in OTF?
What exactly are the OTF limitations?????
limitations of context block
limitations of composing\decomposing Glyphes
Limitations of amount of Anchers
Since you refer to it, take a PairPosFormat2 subtable as an example:
Coverage table and ClassDef1/2 table offsets are, as you say, 16 bit integers so the maximum value can be 65536 (meaning bytes, from the beginning of the subtable). This means that there's a little less space than that left for the actual kerning data -- which is Class1Count*Class2Count*ValueRecord(s) -- plus Coverage and ClassDef1 table lengths to make sure that Coverage, ClassDef1 and ClassDef2 tables are in reach.
It is not too hard to reach this limit.
 For kerning to work, there must be a value only for the first glyph of the pair, i.e. one Record. Yet do not forget the ValueRecordFormat as another factor. Since with right-to-left scripts both positioning and advance width need to be adjusted, this means another *2.
offsets are, as you say, 16 bit integers so the maximum value can be 65536
Offset are indeed in bytes and you are right with PairPosFormat2. On the other hand, if I type
spot -t GPOS AdobeHebrew-Regular.otf |grep -i offset | cut -d\= -f3 | sort | uniq -c
the largest value of offset that is output is 4400. Are there offsets that spot is not outputing?
PS The output looks better withspot -t GPOS AdobeHebrew-Regular.otf |grep -i offset | cut -d\= -f3 | sort | tail -1
spot -t GPOS AdobeHebrew-Regular.otf |grep -i offset | cut -d\= -f3 | sort | tail -1
I missed offsets on lines for which there is just one = sign. The largest is 42a8. Any other that I missed?
Hmm, With AdobeArabic-Regular.otf, I see an offset of f18a. Feels tight indeed.
I now took the time to have a closer look at that offset in AdobeArabic-Regular.otf Version 1.016. What I see in the file given by spot -t GPOS AdobeArabic-Regular.otf is
--- Lookup  (0ab6)
--- Subtable  (0008)
PosFormat = 1
LookupType = 2
Offset = 0000f18a
and I should have realized right away that the offset is 32 bits, not 16 bits with a lookup type 9 (Extension positioning). In fact, there seems to be no offset that requires 32 bits in that font. Am I missing something?
spot -t GPOS AdobeArabic-Regular.otf
--- Lookup  (0ab6)
--- Subtable  (0008)
PosFormat = 1
LookupType = 2
Offset = 0000f18a
Michel, I don't know whether you're missing anything or not. The Adobe Arabic font was made using VOLT -- the only option at the time, and still the only tool I use for OTL table work -- and I set the extension lookups option to whatever will enable the font to compile in VOLT. I always start with the option turned off, but turn it on if the font won't compile. What VOLT does in the background is a mystery to me.
Michael Boyer -- and I should have realized right away that the offset is 32 bits, not 16 bits with a lookup type 9 (Extension positioning). In fact, there seems to be no offset that requires 32 bits in that font. Am I missing something?
That's what the extension lookup type (type 9 in GPOS, type 7 in GSUB) is for, allowing for larger offset values. ;-) Such a lookup is not a "real" lookup but only serves as a relay to a "real" lookup (which then contains lookup metadata and refers to subtables defining glyph positioning or substitution). One might call it a nice hack to overcome at least part of a serious limitation.
So back to Mr Fried's question, the best thing is to try activating the use extension option and see if it helps.
Activating extention options is somthing i hav done long ago
but still expiriancing dificukties.
Hm, then you may need to split up VOLT lookup definitions into multiple ones.
As a correction, I said that an extension type lookup "only serves as a relay to a real lookup" which should read "relay to a subtable".
Theunis de Jong wrote
>there are tricks to use CFFs in VOLT
Please tell me how! Where can I learn these tricks?
Where can I learn these tricks?
Why, where else than on [[http://typophile.com/node/1161|Typophile]]? Scroll down to John Hudson's 2nd post.
I am surprised by the date of it: just one day after my birthday! :-)
I've put more detailed FontLab-to-Volt workflow, including CFF-in-VOLT, documentation online here:http://www.tiro.com/John/FontLab-to-VOLTworkflow.pdf