Posted by:
Adam Twardoch I'll take the opportunity and explain some new aspects of generating glyphs in FontLab Studio 5.
In FontLab Studio 5, we have created a completely new alias.dat file that contains over 3,500 glyph composition recipes for over 2,500 glyphs. We have used the canonical decomposition rules from the Unicode Standard 4.1 as well as other sources, plus we devised many mappings ourselves.
This means that for some glyphs, we have more than one recipe. An excerpt of alias.dat looks like the following:
obreve o+uni0306
obreve o+breve
This means that when the user calls Generate Glyphs with "obreve" as a parameter, or double-clicks on an empty obreve cell, FLS5 will first look for the glyphs "o" and "uni0306" in the font. If both are present, FLS5 will generate a composite "obreve" glyph using these as components. If not all of the components are found in the font, FLS5 will try the next recipe, i.e. will look for the presence of "o" and "breve". If both are found, it will generate "obreve" using these.
If not all components are found and there are no more alternate recipes to process, FLS5 will attempt to generate the "obreve" glyph using as many components as can be found in the font, based on the first examined recipe. So if only "o" is present in the font, FLS5 will generate "obreve" as a composite glyph only referencing "o" as a component. If the lines were:
obreve a+uni0306
obreve b+breve
and both "uni0306" and "breve" were not present in the font, then FLS5 would generate "obreve" as a composite glyph referencing "a" as the only component.
Alias.dat also contains the following line:
uni0306 breve%
This means that if one tries to generate "uni0306", a *decomposed* (which here means: outline-based, not composite-based) glyph "uni0306" will be used that will be a copy of "breve". The "%" sign indicates that the glyph should be decomposed into outlines after creation. This is because you cannot chain composite glyphs in FLS5 (a composite glyph cannot be used as a component in a different composite glyphs).
Double-clicking on an empty glyph cell always uses the glyph recipes from the alias.dat file. But if you use Glyph / Generate Glyphs and type in some text there, you can either use the glyph recipes from alias.dat, or you can override them locally using your own recipes.
As I said, alias.dat specifies "uni0306 breve%" which means that "uni0306" will be create as an outline glyph, not a composite glyph. If somebody still wishes to generate a "uni0306" as a composite glyph referencing the "breve" component, without decomposition into outlines, he can override the recipe specified in the alias.dat. In Generate Glyphs, if you type "uni0306", then the alias.dat recipe will be used ("breve%" which causes the decomposition into outlines). But if you type "breve=uni0306" in Generate Glyphs, then the recipe that was specified before the equation sign will be used (which does not include the "%" therefore the glyph will be kept as a composite).
In FontLab Studio 5, we have also added a two-tier structure of data files (encoding files, naming files, Python macros). Alias.dat is also such a data file. FontLab Studio 5 ships with an "alias.dat" file that gets installed into "C:Program FilesCommon FilesFontLabData" (on Windows). This is the "factory" file that is used by default. However, the user can override the factory data files by user data files. If you place a file named "alias.dat" in "C:Documents and Settings(username)Application DataFontLabSharedData", then FLS5 will ignore the factory file and use your file instead. We recommend that you don't tweak the factory files anymore (as you might have done in FontLab 4.6) but make a user copy and use that instead. This way, you will prevent FontLab Studio 5 from ever overwriting your customized data files by new factory files.
You can specify a different location for your user data files in Tools / Options / Folders and paths. For example, my own data files are in "D:FontLabShared" rather than "C:Documents and SettingsAdam TwardochApplication DataFontLabShared".
This is handy for backup. I don't have to go to the FontLab application folder anymore and laborously separate the factory files from the ones I customized. I just zip my D:FontLab folder which includes ALL of customized encodings, mapping files, codepages, Python macros, alias.dat etc. I can backup the .zip file, do a clean FontLab Studio 5 install on a different machine, and then unzip the backup zip into a new folder. Finally, I go to Tools / Options / Folders and paths, point FontLab Studio 5 to that new folder, restart FLS5 and I'm done. This functionality also allows you to place your data files on a server that is accessible through a local network.
Of course, if any of you makes some interesting customizations to any of the files and is willing to share these customizations (of mappings, encodings, alias.dat, kerning and metric files etc.) with other FontLab Studio 5 users, please send the customized files to us and we'll consider incorporating them into the next release!
More on alias.dat: If one starts with a plain ANSI font, then generates "uni0306" and then "obreve", he'll first get an outline copy of "breve" named "uni0306" and then "obreve" will be generated from "o+uni0306". If "uni0306" were a composite glyph, FLS5 would fail to process the "o+uni0306" recipe and would make "obreve" from "o+breve".
When developing this system, we have even considered a chaining glyph generation system. Let's say we only have the lines
uni0306 breve%
obreve o+uni0306
in alias.dat. Based on this definition, currently, FLS5 will generate "obreve" as a composite glyph only containing one component glyph: "o". So when FLS5 looks at the "o+uni0306" recipe and it fails because "uni0306" is not found, FLS5 will currently not
attempt to generate "uni0306" based on the "breve%" recipe. In other words, the current implementation does not support recurrence. We have decided that it would be potentially problematic: a badly-written alias.dat could lead to circular references, and also, the user could potentially get more glyphs generated than he specified (since all the intermediates would automatically generate).
Needless to say, a recurrential implementation can still be done in Python if one wants it

There's even more to the Generate Glyph syntax, with fancy modifier operators but I just discovered that one of the superfancy operators (|) does not work as advertised in FLS5. Also, negative values don't work: "m+>200macron" works but "m+>-200macron" doesn't. I'll wait for Yuri to fix it before writing the rest of the tutorial

Adam Twardoch
Fontlab Ltd.