makeotf ReportI figure the warning statement is probably the issue, but haven't written anything in my features window, so I don't really understand whats going on?
makeotf [Note] Converting source font '/font.otf' to temporary Unix Type1 font file '/font.otf.tmp'.
makeotf [Note] setting the DONT_USE_WIN_LINE_METRICS OS/2 fsSelection bit 7 from fontinfo keyword.
makeotf [Note] setting the WEIGHT_WIDTH_SLOPE_ONLY OS/2 fsSelection bit 8 from fontinfo keyword.
makeotf [Note] setting the OBLIQUE OS/2 fsSelection bit 9 from fontinfo keyword.
makeotf [Note] Writing options file /current.fpr
makeotf [Note] Running makeotfexe with commands:
cd ""
makeotfexe -f font.otf.tmp -o Basis-Light-1.1.otf -ff features -gf glyphOrder -mf menuname -r
makeotfexe [WARNING][internal] Feature block seen before any language system statement. You should place languagesystem statements before any feature definition [features 3]
makeotfexe [NOTE] Wrote new font file 'Basis-Light-1.1.otf'.
Built release mode font 'Basis-Light-1.1.otf' Revision 0.000
Comments
And please don’t forget to register yourself with your real name in Typedrawers. It’s one of the requirements here.
So I generated a KERN feature inside my font through MetricsMachine, also specified a language statement, and the kerning still isn't being generated on my test-installs. Here's another look at my Output window —
But the fact that you aren’t getting any error message pertaining to the compilation of the {kern} feature makes me think that this is not the problem.
I seem to recall that in order for many apps to recognize any GPOS lookups (i.e., those that control kerning), there needs to be at least one GSUB lookup (and thus a GSUB table) present.
You mention that you haven’t written any features at all yet, and this may be causing your problem. Try including some sort of basic GSUB feature — {liga} is the typical one to use in this case, even a dummy one — and see if that causes the kerning to be recognized in your apps.
Having kerning data stored both in the kerning.plist and as an explicit {kern} feature in the features.fea can potentially lead to discrepancies between unsynchronized sets of data if you’re not careful.
So I got the kerning there in InDesign (see attached image), but for some reason it still isn't loading in a web browser or a simpler program like TextEdit. Any clue why this is the case?
@Kent, I've now included a language definition in my features file, is this a GSUB feature? Sorry but this is my first time working in a features file.
You can read more about the Adobe feature file syntax specification at http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html
Thanks for that, I've appended my feature file but am still coming across the same problem. My kerning is showing in InDesign but not in any other program, including all browsers. Do you have any idea why this might be the case?
In my experience, TextEdit support for kerning is buggy. I’ve got plenty of perfectly valid fonts installed whose kerning TextEdit will not display. I haven’t bothered to investigate where its idiosyncrasies stem from. But I run an older system and haven’t trialed the latest.
MS Word has kerning off by default and it needs to be explicitly activated. So if you’re reviewing in Word, be sure to do so.
Browsers are their own species of beast. I believe kerning may need to be explicitly invoked in your css, and each browser may take a different parameter to do so. But that’s not my area of focus, so someone else will have to point you in the right direction.
Yes the kerning is fine in Adobe apps, but every other program, whether Pages, Word or any other Non-Adobe text editor. This is very strange...
I've researched kerning in browser, and I have the necessary CSS to activate it, but it's just not loading for some reason.
Argh.. this is so frustrating.
Yes just cleared them again and retried w/ test installation. No change in non-Adobe programs...
Just took a look at my fdk components like @Marcos suggested. And I've noticed that even though I've deleted my KERN feature in this font and instead saved my kerning directly into the UFO as a .plist file like Ken suggested, it's still being generated in the FDK features file?
Any idea why this is happening? Sorry for seeming so clueless about this guys!
I have to say, those are some unusual kerning classes you have there — unless you’re using hacked character slots for nonstandard glyphs (which is frowned upon these days).
But that should not have any bearing on the problem you describe.
Wait . . . I just noticed that your language definition has only a latn/dflt declaration. You need to also declare
languagesystem DFLT dflt;
first.For more about this, see the spec: http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#4.b.i This absence could be why other apps are not applying your kerning tables.
I seem to remember that a while ago when I created some test kerning pairs inside Robofont, without using MetricsMachine, the kerning was exported properly and was visible. So maybe the issue is with how MM is formatting the kerning?
FWIW, use of Metrics Machine is very common among Robofont users, and integration is very tight. It seems unlikely that MM is the issue and I've never heard of anyone having the kind of trouble you're having with it. Not saying it couldn't be the problem, but it seems unlikely.
What should I be looking for? I've opened it in TextEdit and quickly search for 'kern' and found two empty feature tags.
If the kerning exported correctly, then you should have a <GPOS> table, within which are a <ScriptList>, a <FeatureList>, and a <LookupList>.
In the <FeatureList>, I’m guessing you should find two <FeatureRecord>s, one for each of your languagesystem definitions, both with <FeatureTag value="kern"/>, and both should reference a <LookupListIndex>.
And then in your <LookupList>, you should find at least one <Lookup> and that/those should contain at least one <PairPos> that should in turn contain a <Coverage> list and a whole bunch of <PairSet> entries for kerning partners and values.
If it looks like this stuff is all present, then the font has some kerning info in it. The main point earlier when I mentioned a TTX dump was just to confirm that there is in fact a GPOS table with a {kern} FeatureRecord in it. Rummaging through the XML is probably not the place to do further troubleshooting, except as a last resort.
If the font was in fact generated with kerning, then I don’t know what else to tell you, in terms of the issues you’re experiencing with other apps. Not without getting hands-on and hands dirty with the font and source, which I’m afraid I don’t have to time to offer right now.
Yeah, it’s frustrating. But remember, you’re not just designing some nice letters, you’re building software.
Everything you mentioned is visible, except for the PairSet entries.
This is really strange then considering that the kerning is working in some programs, like the Adobe Suite.
Could you explain the correct way to do that? Sorry if a lot of this seems obvious to you guys, but I'm learning much of this as I go.