Going down through my otf fonts opening them in FontLab I find that right away in the A's Arno Pro does something similar.

Does anyone know of any other font editing program that might open the otf and "see" the kerning?

Thanks again,
Ken

Have You tried OTMaster?

André

Have You tried OTMaster?

I tried the Light version of OTMaster and I can only get it to display an old PS Type 1 style kern table, which is not normally present in OT fonts. TTX does the same thing.

If you have FL504, just save the kern feature by saving the Opentype Feature file (click the little folder icon at the top left of the OT panel and select "save features"). You can open the feature file (.fea) in a text editor. The kern feature is usually first.

Each opentype file has a Language and script declaration. That is what you have shown above in your first post.

If you want something more "visual", you can try FontForge. With Arno Pro, if you select Element > Font Info > Lookups > GPOS you get this

and then, clicking on the kerning table you get this view where you can select the two kerning classes, see the kerning value and also see in a right pannel how characters appear.

Here the class of guillemotleft and of A were selected.

I tried saving the features from FontLab but in the feature file I only got the code I put in my first post.

In FontLab when I try to generate the font with which I'm working and the Arno from FontLab it indicates that there are binary tables, so I'm guessing it just wasn't able decompile it in to the feature.

I looked quickly last night for a compiled PC version of FontForge but didn't see one, maybe I'll try that again.

I'm still not real familiar with the features so bear with me. Based on this info from Michel I'm assuming its the gpos commands I'm looking for? I'll also have to figure out how to isolate the information relating to just the glyphs I need to pick up.

Oy.

Many, MANY thanks guys, very much appreciated.

Ken

For a compiled version of FontForge running under Windows, see http://typophile.com/node/84219
Michel

IIRC, Arno uses contextual kerning, which isn't supported by Fontlab Studio 5.x. Same with mark and mkmk. All of us non-programmer sorts who depend on one program are eagerly awaiting version 6. It was promised in December 2010 . . .

You could take a look at & try using AFDKO 2.5

I see no contextual positioning in Arno. You can find such tables in the font Old Standard by typophile Anagnost (ref. this post), that was created with FontForge. Here is how that looks with FontForge:

or read this: http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html
especially chapter 6. Glyph positioning (GPOS) rules

Contextual kerning?!?! Oy-vey! All this is pretty cool stuff but doing this as a side function of my main job responsibilities is really making me long for the days of 256 characters and kern pairs that are just that, simply pairs! :o)

I've since done some searches and found other threads, here and elsewhere, that talk about Arno and it's kerning, a couple of which confirm my suspicion that the kerning is just too complex for FontLab to decompile.

Looking at these other font editing programs really make me appreciate the way FontLab works with the features, making them easy to read and understand.

Probably a silly question but how'd you come to the conclusion that Arno has contextual kerning? And would ALL of the kerning contextual?

Thanks for chiming in Charles!

If you're going to do a search, "kerning triplets" is probably the key topic. See

http://typophile.com/node/34059

and

http://typophile.com/node/43708

I do believe somewhere either Miguel or Thomas mentioned that Arno used contextual kerning; maybe it was just Adam's post & I'm misremembering.

Charles,

As Miguel says in the first thread you link to, to see all the kerning data in ArnoPro, all you need to do is install AFDKO and then execute the command

spot -t GPOS=7 ArnoPro-Regular.otf > gpos.txt

I just did that, went (fast) through the 35701 lines of the gpos.txt output file, and saw no "triples" or anything exotic.

Michel

Michael -- I'll have to take your word for it. As I use only FontLab, I don't get to see anything with Arno's kerning. What did Adam mean, then, that Arno is "too complex"? Simply that the number of kern *pairs* was too great for FL? Odd way to say that.

From the screenshots of Arno above, those are kerning classes not contextual kerning. Kerning by classes can be very compact (and may be more efficient) when you have lots of similar glyphs that kern identically; 10 A-like glyphs and 10 V-like glyphs, that is 10×10 kerning pairs to edit, but only one pair of kerning classes. I find FontForge's UI for kerning classes very informative and makes editing and reviewing kerning classes as simple as it goes.

James: ‘[…] OTMaster and I can only get it to display an old PS Type 1 style kern table […]’

I wonder what happened here, because OTM will show everything present in a font.
 

Michel: ‘If you want something more "visual", you can try FontForge’
 

Or OTM. The advantage of OTM is that there is no conversion or interpretation, and everything can be edited directly. One can even export the features file and (after editing) compile the features again (or new ones, of course).
 

Charles: ‘Same with mark and mkmk’
 
All the mark stuff can be compiled by OTM and positionally edited using a GUI. See also Karsten Lücke’s great OTM manual.
 
FEB

Frank Blokland: The advantage of OTM is that there is no conversion or interpretation

That sounds like a nice feature.

[-]: One can even export the features file

One can do the same with FontForge. Just right click in the GPOS pannel and save.

@Michel Boyer:

"Save Feature File" will save all GSUB, GPOS and GDEF tables, to save only the selected lookup use "Save Lookup".

Michel: ‘One can do the same with FontForge. Just right click in the GPOS pannel and save.’

In OTM one can do this by selecting the Export… option from the File menu, but actually the emphasis in my line was on the second part: ‘[…] and (after editing) compile the features again […]’
 

OTM cleverly compiles features without the necessity that the imported layout features are covered by the character set. It will ‘simply’ generate a subset of the applicable features (and shows this in a listing). At DTL we use a sort of ‘all covering’ features file, which I update and enhance from time to time.
 

By the way, exported features may be edited, but also can be compiled again without doing that, generating things as they were.
 
FEB

Bokland: actually the emphasis in my line was on the second part: ‘[…] and (after editing) compile the features again […]’

Well, FontForge can also read in the feature file. You just select File > Merge Feature Info and then select the .fea file. Here I deleted completely the GPOS tables from Arno, and read in the feature file. Some names are lost but the tables are there.

Edit.

Ok, now I generated the otf font, exited from FontForge and opened FontForge on the new font. Here is what I now see in the GPOS tables:

Bokland: OTM cleverly compiles features without the necessity that the imported layout features are covered by the character set.

With the risk of this turning into this does and that does :) but FontForge does that too; it will simply ignore glyph names that does not exist in the font, though it won't generate a warning which is suboptimal. FontForge also implements all of the feature file specification, even parts not implemented by Adobe (in the other day I wanted to test some of my feature files with AFDKO and it started complaining about certain lookup types not supported and I couldn't get it to compile at all without re-implementing those lookups in more convoluted ways).

Michel: Some names are lost but the tables are there.

lookup names are purely cosmetic, they don't get output in the final font (unless you ask FontForge to output its private table where it can keep such information for later use). When FontForge opens a new font it will generate lookup names based on the feature they are attached to. Feature files have restrictions on table names, so the ones exported by FontForge differ slightly from the ones used originally in the UI.

“ lookup names are purely cosmetic ”
      Indeed.

Khaled: ‘With the risk of this turning into this does and that does’
 
Basically that is the point of discussion now, but before I further elaborate on the differences in functionality between FF and OTM, let me underline here that I consider FF to be a very powerful and highly useful program for professional font production. The by designers often discussed X Windows interface of FF is probably not the most sophisticated one, but with scripting much can be done in FF without having to look at the interface anyway. And with some tweaking the FF auto-hinter is one of the best I have seen so far. So, although I prefer (not surprisingly) DTL FontMaster, FontForge is a serious competitor in my opinion.
 
That being said, although there is obviously an overlap in functionality, there is a big difference between FF and OTM when it comes to editing OpenType fonts and OT layout features. Prior to editing, the FF user has to convert a font to FF’s proprietary format and after editing the font has to be newly generated again. The outcome (besides the changes) will never be identical to the original font, unless this was generated with the same version of FF too, I reckon.
 

With OTM the font is not converted and one can edit the character set, glyphs and tables directly, i.e. the font itself becomes the ‘database’. OTM runs natively under Mac OS and Windows and the latter makes side by side editing with for instance MS’s Font Validator easy (see the illustration above).
 
With the upcoming KernMaster 2012 we will focus even more on the font-as-database approach; KM 2012 can space and kern OT fonts and merges the outcomes with the original font data. Output options include a features file, of course.
 
FEB

Mind, FontForge's own storage format, SFD, is textual as per Unix canon. There is also an SFDir format that saves each glyph as a separate file in a subdirectory, likely intended for collaborative efforts. And now also UFO.

Té: ‘[…] FontForge's own storage format, SFD, is textual as per Unix canon.’
 
This exchange of info on the checking and editing of OT Layout features seems to go in all directions now, but I simply can’t resist replying here that the 30+ years old IKARUS (UNIX) file system of which DTL FontMaster makes use, is also very much text based (UFM [URW Font Metadata], CHA [character layout file] and kerning [.afm or .fea]).
 
I have tried to explain FM’s versatile file structure in this presentation a couple of years ago.
 
FEB

Concerning data representation, I like the xml files produced by ttx. They are text files, but they are also well structured. Just reading the output of ttx -t GPOS ArnoPro-Regular.otf is quite instructive. They can also be parsed, provided you can write some code.

I have no stock in FontForge (not more than any one else), I'm just a big fan of it (and free software in general). Indeed FontForge deassembles and then reassembles the font, so it is not really suitable for some tasks where this is undesirable (though I once fixed serious shaping bug in a font by simply opening it in FontForge and then generating a new font, so it can be useful :)

I read "proprietary" here to just mean its own format, otherwise SFD is publicly documented and its canonical implementation is freely available under BSD license (like the rest of FontForge).

BTW, FontForge can read IKARUS (or at least it claims to, I don't have such files to test).

I wonder what happened here, because OTM will show everything present in a font.

I made the mistake of expecting the feature labeled “'kern' table viewer” in a program for mastering OpenType fonts to show me OpenType kerning. Silly me.

Khaled: ‘I read "proprietary" here to just mean its own format […] FontForge can read IKARUS (or at least it claims to, I don't have such files to test).’
 
Yes, that is what I meant. The proprietary format of the IKARUS system has been publicly documented too (as far as I know, for the first time in the late 1980’s).
I did not know that FontForge does support the IK format and so far I have not been able to open IK files in FF, by the way. I know that FontLab Studio supports the IK format in a limited way. Although it is quite some time ago when I tested this, I was able to open some IK files in FLS.
 
James: ‘[…] expecting the feature labeled “'kern' table viewer” in a program […] to show me OpenType kerning.’
 
As you know, OpenType fonts come in two flavors (CFF and TTF) and there are two ways to include kerning into OpenType fonts, namely as ‘flat’ kerning in the ‘kern’ table (only in TTF) and as ‘advanced’ kerning in the ‘GPOS’ table (TTF’s can contain both tables). You probably meant the ‘GPOS’ table when you mentioned ‘OpenType kerning’, I reckon.
 
FEB

Khaled: Indeed FontForge deassembles and then reassembles the font, so it is not really suitable for some tasks where this is undesirable

Even then, FontForge can be useful. Last summer, I made a font with AAT tables for the Macintosh. I found no way to get with fontforge a ttf output that would work correctly on OS X 10.5, so I used the fontforge python module to generate the appropriate mif file (6770 lines) and then used ftxenhancer. All the precomposed glyphs had been generated with a fontforge script. However, after seeing some outputs on the screen, I realized that some diacritics in the precomposed glyphs needed to be moved. Modifying the font with fontforge and generating anew did not work and ftxenhancer was much too slow for my taste. So, here is what I did: I opened the working AAT font with FontForge, reencoded in the glyph order, modified the glyphs to my taste, generated a new ttf font and then extracted from it the glyf table using ttx and merged the resulting .ttx file into the original AAT font. That worked nicely, and fast. So, with fontforge and ttx, you can do things with fonts that fontforge does not understand completely.

Incidentally, that's why so many type designers here name tool chains rather than single tools. Some tools are better at some tasks than others are.

Aside: Been wondering if there is a lazy way to convert pair kerning to class kerning.

Topic drift. It always gets someone's goat.

Wow! I LOVE this forum! Thanks guys.

I had to call in a 2nd team who was able to give me a GPOS (I'm pretty sure that was what I needed) "dump" though I'm not sure from where (I have an email to him). I took that and, from my limited knowledge, am thinking (as Khaled mentioned) it looks like it is all kerning classes. I've crunched that file and picked from it what I needed creating classes as necessary. I know have a boat load of kern pairs to add to the font and classes to work with them.

However (there's always a but) when I import into FontLab its not indicating the same number of pairs I know I have. In another post (http://typophile.com/node/40041) Adam T. mentions 10,920, though I'm not sure whether than means pairs OT class or "old-style" pairs. I'm trying to import the single and key-glyph pairs I've created, and total I should have no where near 10,920. I've looked but can't seem to find anything definitive as to what the limit for the "regular" (not the OT feature) kern pair limit it. Does anyone know?

Also, at the top of the dump I received there is a lookup containing 505 glyphs that looks like this and I have no idea what they are:

lookup GPOS_LOOKUP_00000
{
lookupflag 0;
pos \A <5 0 10 0>;
pos \B <5 0 10 0>;
pos \C <5 0 10 0>;
pos \D <5 0 10 0>;
pos \E <5 0 10 0>;
...

Below that are kern pairs of some sort?:

lookup GPOS_LOOKUP_00001
{
lookupflag 0;
pos question uni0458 <0 0 4 0>;
pos question uni0463 <0 0 3 0>;
pos B X <0 0 -6 0>;
pos B b <0 0 -11 0>;
pos B v <0 0 -14 0>;
...

Below that are entries that look like this, which I am assuming is the class kerning (these don't seem to repeat what I think are kern paris up above):

subtable;
pos [ \A \Aacute \Acircumflex \Adieresis \Agrave \Aring \Atilde \R_A \K_A \uni0102 \uni0100
\uni0104 \uni01FA \uni1EA0 \uni1EA2 \uni1EA4 \uni1EA6 \uni1EA8 \uni1EAA \uni1EAC
\uni1EAE \uni1EB0 \uni1EB2 \uni1EB4 \uni1EB6]
[ \A \AE \Aacute \Acircumflex \Adieresis \Agrave \Aring \Atilde \uni0102 \uni0100 \uni0104
\uni01FA \uni01FC \uni1EA0 \uni1EA2 \uni1EA4 \uni1EA6 \uni1EA8 \uni1EAA \uni1EAC
\uni1EAE \uni1EB0 \uni1EB2 \uni1EB4 \uni1EB6] <0 0 29 0>;

Am I correct in my assumptions and what is that first thing?

Oy, and thnks again for everyone's time.
Ken

lookup GPOS_LOOKUP_00000 = cpsp Capital Spacing
lookup GPOS_LOOKUP_00001 = kern per glyph pairs
the rest kerning classes
BTW
"lookup GPOS_LOOKUP_00001
{
lookupflag 0;
pos question uni0458 <0 0 4 0>;
pos question uni0463 <0 0 3 0>;"
could be written as:
lookup kernHorizontalKerninglookup1 {
lookupflag 0;
pos \question \uni0463 3;
pos \question \uni0458 4;

Also, if you look at and/or edit that table with FontForge, you get a completely different interface. You get a list of pairs. If you want to change the kerning of one pair, you can simply select it and then drag the right hand character at the bottom of the panel. You add pairs at the bottom of the list. Those pairs override the kerning that would otherwise be given by the class kerning.

OH! I THINK I get it. The CPSP is another GPOS lookup like the kern feature?

I also found that I wasn't getting the total number of kerns when importing due to some duplicates in the incoming afm, it has nothing to do with an upper limit of kern pairs. Though that would still be an interesting thing to know.

Thanks again!
Ken

I just had a closer look at Arno's GPOS kern table. Using the AFDKO command

spot -t GPOS=6 ArnoPro-Regular.otf > ArnoPro-Regular.afm

you can get a huge file in afm format containing all kerning pairs for all the scripts (it takes a few minutes). The first lines are

Comment Begin Script DFLT Language dflt
StartKernPairs 997900
KPX A A 29
KPX A A.a 34
KPX A AE 29

There are thus 997900 pairs which, after converting to GPOS pair kerning, overflows by a few hundred times the maximum allowed.

In particular, in subtable 2, the left class number 34 contains 330 characters and the right class number 26 contains 254 characters; by specifying that the kern of each left character in class number 34 with each right character in class number 26 is -4 (which gives just one pair with class kerning), 330 × 254 = 83820 pairs are required in the afm file: that single pair would already cause an overflow with pair kerning.

Michel

Frank: With the upcoming KernMaster 2012...

Request: options for right-to-left kerning in KernMaster.