Once more, I cannot claim any special expertise in the matter, but I have noticed that FontLab has its own ideas about what constitutes proper syntax, and will apply those ideas when it generates a font. Unless the syntax you use is spectacularly wrong, the process is transparent.

Actually, I think it's better to characterize the process in reverse. What you're seeing has more to do with how FontLab decompiles fonts than how it compiles them. When FL compiles a font, you should end up with something which contains the features and lookups which you described in your .vfb file, but there is no way to recover the actual code which your .vfb file contained simply by looking at the resultant .otf file. FontLab can't reconstruct things like class or lookup names from compiled fonts so it makes these up, and it also explicitly includes a lot of stuff which is often left implicit when writing code (such as lookup declarations).

If you really want to know exactly what FontLab is generating, you're better off using a tool like DTL OTMaster (Lite) rather than reopening your fonts in FontLab.

André

Thanks for your replies guys. This already helps me a lot to understand what's going on.

Am I correct in assuming that I did in fact open up the wrong files then? That is, that I accidentally opened up the .oft files instead of the build files? (while i had those .vfb files right there in the same directory). And that FontLab then reverse engeneered / recompiled the fonts from my .otf files into new .vfb files that I - stupidly - saved again over my original .vfb files - hence loosing the original files?

This probably means that I can't get my old files back with the original code. Not that it really matters that the code is different - but there seem to be a few oddities now. And on top of that there is this "Current font contains both OpenType features definition and imported binary OpenType tables" message...'

Any suggestions?

I can't be sure, but yes, it sounds like that's what you did.

The message is asking you whether you want to preserve the original (imported binary) opentype feature definitions (the ones which were created by FontLab when you originally exported the font) or if you want to recompile the features using the source code created by FontLab's decompiler.

While OpenType source code refers to glyphs by name, in the actual OpenType tables glyphs are referred to by glyph index. Therefore, you should only use the imported binary features if you haven't done anything which might have reordered the glyphs within the font.

André

André, thanks for your reply and the explanation. Sounds like it's my bad but good to know this is something tricky (for me). I had already seen some messages elsewhere to prefer the binary over the other option, but it is very good to know that I shouldn't mess around with the glyph order anymore. Thanks!

By the way: is it possible to copy/paste the complete kerning code from one font to another? Say from my regular version to my bold version? The index is the same so I'm guessing that should work just fine?

Sure, open a new Metrics window in your donor font => Save your metrics => open up a metrics window in the bold weight => Open your previously saved afm file => Choose to only import the kerning and nothing else.

And if you're missing some classes, you can do the same there as well. Just copy it all from your donor font.

Thanks wiewouters, that's very handy to know! I am assuming that (in this case with my typeface) I could probably do all the kerning in the 'regular' variant and then import all the values to the other weights?

Yes you could.

If you'd wanna do that, an even quicker way would be to:
— Resave / rename your regular VFB (This_regular_02.vfb) as a duplicate (This_bold_02.vfb).
— Open up your new bold VFB, delete all the characters
— Open up your old bold VFB, copy all the glyphs
— Open up your new bold VFB, rightclick (append all glyphs).
— Go to font info and change the name, …
— Export your font for proofing.

Hope that makes sense.

Oh and for the record, it’s WiewAuters, but don't worry about it, that's a common typo.

hey wiewauters, sorry for the typo :)
Thanks for the info, that helps, good stuff man! Will try this soon. Do these things work for all aspects (dlig, calt, kern, etc?). I'm guessing this is the case, that would make the most sense.

Another question:

I've got the following code right now for salt:

feature salt { # Stylistic Alternates
# Latin
@STARTSWASH = [K R V W Q A];
ignore sub @calt1 @STARTSWASH';
sub K' by K.alt;
sub R' by R.alt;
sub V' by V.alt;
sub W' by W.alt;
sub Q' by Q.alt;
sub A' by A.alt;
} salt;

Even though this is the code, the font itself shows these swash characters in every context (as long as stylistic alternates is turned on). How is that possible? These swash characters should only show themselves if there isn't another glyph in place before the character (@calt1 = basically all glyphs).

You can't use contextual substitutions in salt. Use calt instead. (Hint: the "c" in "calt" stands for "contextual".)

Hey Mark, thanks!! Ha, that explains a lot!

This means that with these alternates it's just a case of turning them on or off, and that's it? If I keep them as stylistic alternates that is? I've already got a heap of alternates in the contextual alternates list, which is why I put them in the stylistic feature...

I take it that swashes are supposed to be in a different feature then?

You can't use contextual substitutions in salt.

You can't? I put my contextual swash code into salt (in addition to swsh) and it seemed to work.

@Stinger in what software are you viewing the font?

Hey eliason, thanks for this. Odd, now I'm a little confused. If you got it to work then it should be possible (that's a great typeface by the way, just checked your post about it, nice!).

I'm using Adobe Illustrator and Photoshop to check out the features. Illustrator seems to have a lot of problems updating its cache though, so I need to restart my system frequently (time consuming!). All those tricks should work in Illustrator just fine I think?

From your screendump I am assuming that it's possible to include more than one stylistic alternate?

From your screendump I am assuming that it's possible to include more than one stylistic alternate?

Yes, instead of using "salt" you can use "ss01," "ss02," etc. That way the user isn't faced with an "all or nothing" setting.

Sweet! That's good to know, thanks!

Is your code basically the same? Am I missing something - as you said it seems to be possible to use contextual substitutions here but they don't seem to be taking off properly.

Yes, that looks more or less like my code. I actually have the code under the swsh feature as a named lookup, and then under ss02 I just recall that lookup. And I defined my classes in the FontLab classes panel rather than right there in the code. I don't know if these differences might cause the trouble you're seeing.
Does it work in the FontLab Preview panel (OpenType Features)?

Oops, guess I was wrong. It should work in salt (something I didn't know). Not sure why it's not working. What exactly is in @calt1? The problem may be there.

hey wiewauters, sorry for the typo :)
Thanks for the info, that helps, good stuff man! Will try this soon. Do these things work for all aspects (dlig, calt, kern, etc?). I'm guessing this is the case, that would make the most sense.

No problem, and yes, you are only copying the glyphs all the other data should stay there. If you'd wanna be 100% save, don't delete and append the glyphs, but just copy the old over the new ones.

Good luck

Guess what, it had something to do with illustrator or my font cache, as today (after a night's rest) my machine decided that it actually works just fine:

Apart for my kerning that is :)

As eliason suggested, it did work in the Fontlab Preview panel so I was really astonished I didn't work in Illustrator.

Thanks for the response as well Wiewauters!

Oh, good.

Two suggestions:

1. You can save yourself a lot of trouble with regard to font caches if you give your fonts provisional names while under development, changing them each time you generate a new version. For example, if your font is called "My Font", you might have development versions called "My Font A", "My Font B", "My Font C" and so on. This also has the advantage that you can compare different versions side by side in applications. But the best thing is that it completely avoids the font cache issues. (Note: I'm talking about the name you give the font in the Font Info dialogs, not the file name of the font file, which has no effect on the font name in the operating system or applications.)

2. Your code could be a bit simpler. Since you already have a class called "@STARTSWASH", you could save yourself some typing by doing this:

feature salt { # Stylistic Alternates
# Latin
@STARTSWASH = [K R V W Q A];
@STARTSWASH_ALT = [K.alt R.alt V.alt W.alt Q.alt A.alt];
ignore sub @calt1 @STARTSWASH';
sub @STARTSWASH' by @STARTSWASH_ALT;
} salt;

It's shorter and a bit clearer what's going on.

Mark,

somehow I missed your comment here even though you posted it a while back. These are two very good and handy points, thanks! Code simplification makes a lot of sense, that'll work well I think. Altering the font's name in the Font Info dialog will also be a good trick to use for my next typeface, that'll save me loads of time restarting both the machine and Illustrator/Photoshop.

Thanks!