DTL Kernmaster?

oldnick's picture

Any significant improvement? I have a major overhaul underway: "new-and-improving" my freeware collection of fonts, most of which were, naïvely, auto-kerned in Fontographer 4.x.

Since Fontographer tended to ignore the "kern these characters only" selections and produce a great many unnecessary pairs—degree-copyright: really?—realistically, I am going to have to jettison all the old kerning info and start from scratch. Even under optimal conditions, manually kerning over 200 fonts is going to be an incredibly time-consuming task.

If I were convinced that Kernmaster would do a better job overall and require only occasional tweaking, I would be happy to consider purchasing a license. However, my past experience with Contourmaster—intended to tune up the original outlines generated by an even older version of Fontographer—was not very reassuring, despite many passes through, fine-tuning the settings and hoping for better results.

Any words of encouragement out there, or should I prepare for my butt to get seriously numb for an extended period of time?

clauses's picture

iKern or MetricsMachine.

oldnick's picture

iKern is probably not economically feasible in terms of ROI, and MetricsMachine is—AFIK—Mac only. Sorry, Apple has turned too much of my money into trash already.

blank's picture

iKern is probably not economically feasible in terms of ROI…

If the fonts are not monetarily worth updating at Igino’s prices then maybe it makes sense to retire them.

But you should contact DTL about Kernmaster. IIRC Frank mentioned a new version being in development.

John Hudson's picture

I've used Kernmaster a few times, including once for a shipping font. If your fonts have relatively small glyph sets, e.g. just Latin 1, then it may be viable. You do need to adjust the settings on a per-design basis, but if working with a large collection what I would probably do is try to group them based on similarity of proportions and basic spacing, then do tests to establish settings for each group, run the groups through KernMaster, then test individual fonts.

I have noticed that if a font is 'cast small', i.e. the outlines are short relative to the em square, KernMaster doesn't do a good job. In those cases, you can scale up the outlines, run through Kernmaster, then scale down the kerning and apply to the original outlines.

John Hudson's picture

PS. I had Igino run his iKern on a font for test purposes, and was impressed with the results and thought the price very reasonable. But note that iKern is really 'iSpace', and his approach involves respacing the glyphs as well as kerning them.

PabloImpallari's picture

If you have a massive amount of fonts, maybe you can talk to Igino and ask for special price.

Also, there is an InDesign script that can extract "optical kerning" values, and export into a kerning file that you can import in FontLab.

blank's picture

Also, there is an InDesign script that can extract "optical kerning" values, and export into a kerning file that you can import in FontLab.

Optical kerning attempts to create even words, not fix pairs for general use. Using it to create kerning tables would probably be worse than not kerning at all.

William Berkson's picture

Here on Typophile, Adobe InDesign's "optical kerning" is famous for wrecking fonts, not improving them.

blokland's picture

Nick: ‘[…] my past experience with Contourmaster […] was not very reassuring […]


ContourMaster should be able to trace and repair basically everything that can go wrong in contours. Over time some functionality changed and some improvements were made, so it might be possible that you tested an older version (?).
 

To test it on a Mac, you could try the ‘Wine’-wrapped version of FM Light 2.7.0 I made for Mac OS X. I have built an installer for Intel Macs running Mac OS 10.5, 10.6, and 10.7, which installs FM Light 2.7.0 for Windows directly in the applications folder. As mentioned, the stuff is ‘Wine’-wrapped, which means that one does not have to install any additional software, or to start up the X Windows System first. Besides a few minor issues, which I described in the Read Me file, the wrapped version seems to run pretty stable and fast. The only downside of the wrapping is the hefty 330 MB, which is used by the application on the hard disk.
As a bonus, the included DTL TraceMaster version is fully functional.
 

John: ‘If your fonts have relatively small glyph sets, e.g. just Latin 1, then it may be viable.’
 
Actually I think that KernMaster also works fine for Cyrillic and Greek, but the new KM 2012 version allows right to left and vertical kerning too. To get the preferred outcomes, probably some tweaking is inevitable; there seems to be always room for discussion about kerning values. The new version will allow different ‘kern strengths’ for different (groups of) pairs in one file.
KM has always worked pretty good for the DTL fonts and, like almost everything else in the font production, I think that the kerning generation should be controlled via parametrization and that the outcomes should be completely reproducible.
 

The ‘old’ KernMaster was tailored for a FM-based font production, hence it only works with BE and IK files. The new version works directly with OpenType fonts also, and it is very much features-file oriented. The resulting kerning can be merged with the original OpenType font data directly. Besides kerning also spacing can be generated, like in Kernus 3.0. Although high on my priority list, the current beta version of KM 2012 is not capable of batch-handling font files (yet).
 

FEB

PabloImpallari's picture

> Optical kerning attempts to create even words, not fix pairs for general use. Using it to create kerning tables would probably be worse than not kerning at all.

I don't know the internals of how the script works, but on the few test I've made the result greatly depends on the contents of the texts files you use to "feed" the script.
I've only played around with it, and the results where "not that bad" for a few seconds of time invested. I would not recommend it for production files, of course, but also won't say that's better than not kerning at all. Auto-Kerning (the same as Auto-Hinting, or Auto-anything) are things to use "with a grain of salt".

oldnick's picture

Frank,

I purchased a license for the older version of ContourMaster: I'm not sure which one, because that was three computers ago (at least six years) and I didn't bother to migrate it to my newer machines because of the unsatisfactory results.

Batch processing really isn't a concern, since I have to modify each of the 130 or so font files in small ways—adding accents and a few other characters, all of which need to conform to the font's specific style. What I am more concerned about is reducing the time I have to spend manually kerning each font. Because uncommon letter combinations in English may be common in other languages, I kern all possible letter combinations, along with punctuation, numbers and a few common symbols. Under the best of circumstances—dogged determination and no breaks—I can accomplish this task in around two hours per font—or 32.5 non-stop eight-hour days of nothing but kerning. Unfortunately, at that pace, I often experience optical migraines, and numbness in both my mind and my rear end.

Al I'm really looking for is some reassurance that money spent will reliably mean time saved. If the end product of auto-kerning requires too much tweaking—or, as in the case of Fontographer, too many silly or spurious pairs—I simply need to resign myself to a frazzled mind and a sore butt.

John Hudson's picture

Frank, an issue I found recently with KM (2.6.0) is that it was applying different kerning between e.g.

T C
T Cacute
Tcaron C
Tcaron Cacute

This made it impossible for me to us KM, as I needed to be able to compress the kerning with classes in FontLab (prior to conversion to VOLT groups/lookups), which I couldn't do because the differences created hundreds of thousands of exceptions.

[Note that I'm using Karsten's plugins to produce .krn files, which prefix most glyph names to avoid some apparent cleverness on the part of KM that he reckons we need to avoid.]

The new KM with native OTF support sounds like it is worth trying.

blokland's picture

Nick: ‘I purchased a license for the older version of ContourMaster […]
 
We checked our customer database and the version you purchased is from late 2006. At that moment CoMa was basically in its final stage of development, so if you recall what did not work properly or as expected still, I would very much appreciate it if you could let me know, either on this forum or directly.
 
[…] 32.5 non-stop eight-hour days of nothing but kerning.
 
That sounds like real fun to me! I reckon you work (mostly) with FLS. For the ‘old’ KM you would need a Character Layout file (.cha) then, which connects glyph names to positions in a (temporary) BE glyph database. I reckon that the simplest way to ensure that one’s naming convention is correctly used, is to convert the FontLab .nam file that one is normally using. The .cha file is needed then for the conversion from a font to BE format and, of course, for generating the kerning data. Secondly, a kerning file is needed, either with or without a kern class file. Then the kerning can be generated in batch and the output options are .afm or kern feature files. The resulting kerning can subsequently be merged with the original FLS font data.
Because the import of fonts can be done in batch (for instance using the FM Light modules) and the generation of the kerning files can be done in batch too, the conversion and kerning generation can be done quite fast. Another option would be the use of Karsten’s plugin for KM. If you want to test KM, I can send you a full version for this purpose.
 
John: ‘[…] an issue I found recently with KM (2.6.0) is that it was applying different kerning […]
 
The examples you give have actually always been a small issue with the algorithm. The fact that something is sticking out can result in a deviation, which is normally (always) very small. Also minor rounding errors can show up, because of the fact that the actual calculation is done in the IK format on a finer grid. For relatively small ‘plain’ kerning files the deviations are not really a problem and basically they can be ignored, but for larger ones the use of kern classes should be the solution in my opinion (we are looking for a way to convert these back to ‘plain’ files, if necessary). If one uses kerning classes in KM, the first character in the class is used to calculate the kern value. But from your post I understand that this did not work for you?
 
FEB

John Hudson's picture

I didn't try kern classes within KM. What I did was to generate a .krn based on broad groups in FontLab, using Karsten's scripts, and ran this with the deliberate intention of getting a very large set of kern pairs that I could then compress to class kerning back in FontLab. My reason for doing it this way is that my glyph set is very large with lots of oddly shaped glyphs, and I wanted to hit as many legitimate exceptions to class kerning as possible. But because of the algorithm issue you describe, I ended up with almost all exception kerning, and relatively few pairs that compressed to class kerning. Karsten's import script has an option to compress within tolerances, but I found that I couldn't rely on that since some legitimate exceptions were within the same tolerances as those resulting from the algorithm problem.

I think the way to fix this must be some way to define exclusion heights, even if this is the relatively crude method of ignoring anything above the capheight.

oldnick's picture

Frank,

My usual routine is to export outlines from CorelDraw 9 into Fontographer 5 (it simply does some things better than FLS), do some basic spacing, then generate an OTF. I open that font in FontLab Studio 5.04, tweak the glyphs and the spacing, kern, generate Latin 1252, Central European 1250 and Turkish 1254 character sets, apply class kerning, add appropriate features, then generate the Kern feature and compile. I test generated fonts in Illustrator, InDesign, Photoshop and Word. And, FWIW, I'm working on a Dell 6-core 3gHz machine, running Windows 7 Professional with virtualization, so I can run 16-, 32- and 64-bit programs seamlessly.

Test-driving a full-featured current version (or a beta of KM 2012) would be greatly appreciated. If I find the program eased my burden significantly, I would be more than happy to purchase a license—the program would pay for itself from the money I'd save on Preparation H alone… ;)

blokland's picture

Hello Nick,
 
I wanted to have a look at the FLS .nam files, but it seems to me that these are hard-coded nowadays. One can add .nam files in the user –> Library –> Application Support –> FontLab –> Mapping folder, but editing existing copies seems not be possible anymore (it was actually quite some time ago that I looked at this, to be honest). By the way, I was wondering why you don’t export .vfb files from Fontographer for further editing in FontLab Studio (but I am far from an expert when it comes to FLS and FOG).
 
Anyway, I just made two .cha files based on the Adobe Glyph List For New Fonts 1.6 and 1.7 versions (AGLFN_1_6.cha and AGLFN_1_7.cha). I reckon that these (mostly) cover the naming convention in the current FLS and FOG .nam files. Hopefully these work for you.
 
In the meantime I have sent the download address for the full version of KM to your e-mail address in our customer database.
 
FEB

oldnick's picture

Frank,

Many thanks. I will wade into the project as time allows: my wife and I are expecting company for the upcoming holiday, which will divert some of my time with preparation, hunting and gathering, and the like, but I hope to be able to report back by the end of the week.

Nick

blank's picture

Please report back here; many of us would love to know how it works out for you.

Francesco78's picture

Frank,

can we hope for a close release date of KM 2012? Or do you plan to release it next year?
I bought OTMaster a few months ago and I find the program very useful (especially the "import/export AFDKO code" option).

blokland's picture

Hello Francesco,
 
Thanks for the compliment concerning OTM!
 
KM 2012 will be released very early next year. Most probably it will support the UFO format also then.
 
FEB

oldnick's picture

Initial Report:

  1. Kerning results appear to be far more predictable with the .cha file exported by the KLTF plug-in, rather than any of the .cha files which ship with KernMaster.
  2. KM also appears to work better with a specially-tailored .krn file, rather than the default file.
  3. The lack of a GUI makes selecting the right settings for Design Size, Setting Size and Kern strength a hit-or-miss proposition; that is, the only way to undo an incorrect guess is to re-run KM, then re-import the kerning. It's not a big deal, because both processes take very little time, but it's not ideal.
  4. On the basis of only two processed fonts so far, KM doesn't appear to function particularly well with punctuation, especially periods and commas.
  5. On the same basis as above, on both occasions, KM has ignored obvious kerning pairs like FJ and TJ.

Nonetheless, overall the program looks promising: a larger sampling is definitely called for, but I have to admit that a modest amount of clean-up is a lot faster than slogging through all of the kern pairs manually. Updates as they happen…

blokland's picture

Hello Nick, thank you for posting your findings.
 
1. Kerning results appear to be far more predictable with the .cha file exported by the KLTF plug-in […]
This indicates that the naming convention in Karsten’s .cha files is more like the ones used in your fonts and your kerning files. Assuming that the KLTF plug-in .cha file is based on the naming convention used by FLS and you used the same (or is KLTF plug-in .cha generated on the fly?), this would make sense.
 
2. KM also appears to work better with a specially-tailored .krn file […]
This could have same reason as I mentioned above, but it could also be possible that the kerning file that comes with KM does not cover the combinations you want to kern, of course.
 
3. The lack of a GUI makes selecting the right settings for Design Size, Setting Size and Kern strength a hit-or-miss proposition […]
Basically I would ignore the Design Size and Setting Size settings and only focus on the Kern Strength. The first two options basically control the same thing as the Kern Strenght. KM 2012 has a GUI for controlling all these entries, by the way.
 
4. KM doesn't appear to function particularly well with punctuation
In that case I would advise to use a separate file for everything that requires a different kern strength than the rest of the glyphs that you consider to be properly kerned.
 
5. […] KM has ignored obvious kerning pairs like FJ and TJ.
KM will kern everything that is in the kerning file (and class file, if applicable) and that is covered by the .cha file too. If kerning pairs are ignored, then I would check these files first.
 
FEB

charles ellertson's picture

Because uncommon letter combinations in English may be common in other languages, I kern all possible letter combinations, along with punctuation, numbers and a few common symbols. Under the best of circumstances—dogged determination and no breaks—I can accomplish this task in around two hours per font

Nick, my hat's off to you. I too do things manually, and I can cover about what you indicate in 3+ hours for an italic font. For a roman, with the extra glyphs -- superiors for note numbers, arbitrary factions, etc. etc., and the knowledge that I can't get away with much, it takes me about 6 hours. Much of the times is spent with punctuation. I even make up a few extra glyphs and use contextual alternates to lessen the kerning needed; it still 6 hours of work (in other words, a full day).

blank's picture

This could have same reason as I mentioned above, but it could also be possible that the kerning file that comes with KM does not cover the combinations you want to kern, of course.

On that note, when KernMaster is released it might be a good idea if it accepted the Metrics Machine pair lists (which are very simple text files) that that designers have already defined.

oldnick's picture

@charles_e

The vast majority of my fonts are for display purposes, so I limit most fonts to the 1250, 1252 and 1254 character sets, which trims the time required down a bit. Plus, I prefer to keyboard kerning values—rounded to the nearest five, which works satisfactorily in a vast majority of instances—rather than manually dragging characters. The manual input method may seem counterintuitive, but it only takes guessing at values for a few dozen pairs to get a fairly reliable feel for the amount of space needed for a good-looking pair. My text file displays ten characters at a time in the kerning window, so it's "type-tab-type-tab, etc."; if I see any mis-estimations along the way, I simply type and tab to the end of the string, then continue tabbing to the trouble spot.

In my experience, using this method makes the work go a lot faster, plus seeing that all of the values end in five or zero fairly conclusively confirms that the font was hand-kerned.

oldnick's picture

Frank,

‘4. KM doesn't appear to function particularly well with punctuation’
In that case I would advise to use a separate file for everything that requires a different kern strength than the rest of the glyphs that you consider to be properly kerned.

That doesn't appear possible: even a 200% strength (the maximum allowable), obvious pairs like O. and O,—and hyphens between straight-sided serifed letters—have been so far ignored. And the missed kerning pairs like FJ an TJ are definitely in the .krn file, whose 4,388 pairs cover all possible occurrences of UC+UC, UC+lc, lc+lc, punctuation+both (as appropriate), both+punctuation (also in context), number+number, and dollar/sterling/yen+number+cent/euro.

blokland's picture

Nick: ‘[…] pairs like O. and O, […] have been so far ignored. […] FJ an TJ are definitely in the .krn file […]


I know that the kern values for O period and O comma are not perfectly, i.e. a bit too loosely, kerned by the ‘old’ KM (one of the things that will be improved in KM 2012), but they are definitely not ignored. The FJ and TJ combinations are not overlooked by the program either. As I wrote before, everything that is available in a glyph database and that is covered by the supporting files will be kerned by KM.
 

To prove this, I have just made a small kerning file:
-------------------------------------------
Comment Typophile test 25-11-2011
StartFontMetrics
StartKernData
StartKernPairs 4

KPX O period
KPX O comma
KPX F J
KPX T J

EndKernPairs
EndKernData
-------------------------------------------
and the previous image shows the resulting kerning pairs (applied kern strength = 100). Perhaps you should enlarge the Max Num of Pairs to 100000 (or something like this) to be sure that everything in your .krn file is calculated.
 


To test the generated kerning quickly, a glyph database can be selected in BezierMaster (Light) and the AFM file can be selected (and edited in the full BM version, if necessary) in the metrics window. There was no editing in the example below (applied kern strength = 100).
 

[…] plus seeing that all of the values end in five or zero […]
 
I am using some simple scripts to remove small kerning values from the stuff KM calculates. In KM 2012 this is one of the settings one can apply. When it comes to rounding, one can write a script for this too, of course.
 
James: ‘[…] it might be a good idea if it accepted the Metrics Machine pair lists […]
 
That should not be too difficult to implement, I reckon.
 
FEB

k.l.'s picture

Maybe a few additional notes:*

1. & 2. & 5. are indeed related. KM does exactly what you ask it for: check whether predefined pairs need kerning or not. If a pair is not covered in .krn, with glyphs identified by glyph names as defined in .cha, then the pair will not be considered for a check.
You could use previous designs to determine which pair are to be checked and possibly kerned. Plug In KernMaster has a script "Extract KRN From Font" which helps collecting kerning pairs from existing fonts which is described in the manual. (This is based on the assumption that designers reuse kerning test strings and as a consequence kern about the same pairs again and again.)
You could generate a .krn file once, analysing a couple of your fonts, or at least similar ones, and use it for future fonts. This implies, of course, that you have a certain standard glyph set.

3. When using KM, I generated three or four sets of kerning, right one after another, each time with slightly different strength settings. (Export KM input files once and then duplicate them.) Then you can compare results side by side and choose one.

4. KM does special tricks with punctuation marks which one may or may not like. I didn't, and in an updated version of Plug In KernMaster did another trick to prevent KM from recognizing punctuation marks as punctuation marks. I will upload the new version next week (need to update the manual a bit too).
Another thing is that you may need to apply different strengths to letter-letter vs letter-punctuation pairs. If you do, you need to make sure that one .krn file only covers inter-letter kerning pairs, and another .krn file only letter-punctuation kerning pairs. It's a bit of work to set these up, but once prepared, these .krn files are reusable for all your fonts.

* Additional refers to yesterday's post. I am a bit slow these days ...

oldnick's picture

Karsten,

First off, hats off for providing a simple and very useful tool: the value of the .cha file your plug-in has is easily illustrated by a snapshot of my first attempt at KM at 200% kerning strength, using the .cha and .krn files available with the program…

After I substituted your plug-in .cha file and my own .kern file, the results were more in line with expectations.

One other anomaly I noted was inconsistent kerning values for straight-side glyphs in the above font: the kern-left values for H I K L M N were different by as much as 10%. I'm also using KM's default .cla files; it occurred to me that these discrepancies might be overcome by exporting shape classes, but it appears that the structure of FontLab's native .flc files and the KM .cla files are different. If beggars can be choosers, the option to export shape classes might be a welcome addition to your plug-in.

As far as the punctuation problem goes, it has been evident even at 200% kern strength, so the separate-file workaround wouldn't necessarily produce different results.

Frank,

One thing conspicuously missing from the current version of KM is the option to discard kerning value below a certain threshold, such as -10. In most of the cases I have encountered, there is little appreciable difference between -6 and no kerning at all. It would be handy to reject these minor quibbles automatically.

blokland's picture

Nick: ‘After I substituted your [Karsten] plug-in .cha file and my own .kern file, the results were more in line with expectations.
 
Assuming that it is syntaxly correct, technically a Character Layout file can only influence the process by either or not corresponding with the positioning of the glyphs in the database and with the kern file. If the .cha and kern files that come with KM not fully comply with the naming convention you use, by definition any other files that are directly based on your font data will work better. For that reason the new KM 2012 offers the option to export both .cha and kern files from the selected OpenType font.
 
Although not implemented yet, for a long time it is on my wish list to indicate the kern strenght in the kern file itself in case this has to differ from the default, i.e. overall value. This will be implemented in KM 2012. In the old KM the maximum kern strength is limited to 200%, but in the new version this is basically unlimited.
 
I'm also using KM's default .cla files […] it appears that the structure of FontLab's native .flc files and the KM .cla files are different.
 
The kern.cla file which comes with KM is very limited and its content is actually only meant as an example. It is especially included because for generating kerning pairs it is mandatory to have a kern.cla file selected in KM, whether it is used or not. For the production of .afm files it is actually ignored, but it is used for the generation of kern.fea files if glyph class pairs are used. The .cla files use the AFDKO syntax. If you use glyph class pairs in your kern file(s) always be sure that these are all defined in your .cla file.
 
[…] as the punctuation problem goes, it has been evident even at 200% kern strength […]
 
If the outcome does not match one’s expectations, it is possible to use a script to correct the generated kerning in a certain direction. As soon as a deviating pattern is recognized, corrections can be made directly (in batch) in the generated .afm or .fea file (which, by the way, can also be optically/manually edited in BM), of course. After all, a kern strength of 200% means twice the amount of kerning generated with a 100% setting.
 
I use quite some scripts to control the stuff, if only because the generated kerning for a complete BE (or IK) database (West, East, Turkish, Cyrillic, Greek, Vietnamese, etc.) has to be renamed (and distributed) for single byte fonts (for instance oldstyle figures to figures and small caps to lower case). Nowadays I use AppleScript in combination with BBEdit, but I used VBA with Word in the past. The nice thing of the combination KM with BM is that the generated kerning files can be directly connected to the glyph databases for the actual font generation (batch). No additional action is needed.
 
the option to discard kerning value below a certain threshold […]
 
This is implemented in KM 2012 already. Rounding is not (yet) part of the application, but it should not be too difficult to write a script for this.
 
FEB

oldnick's picture

Frank,

The voodoo in the punctuation—especially the colon—appears resistant to remedy. It occurred to me that I might try adding extra space in front of the colon before export in order to avoid the problem. Unfortunately, my cunning plan didn't change things: even with 60 extra units of space to the left of the colon, KM still returned positive values. Bummer.

I have noticed that KM appears to have problems dealing with somewhat quirky designs and very condensed characters. With one design—with crossbars extended to the left of the letters—even at 200% kerning strength, KM returns over 1200 positive values, even after sidebearings were increased in order to minimize such an occurrence. On the other hand, KM handles fonts with traditional letterforms reliably and quite acceptably—except, of course, with some punctuation.

In any event, with the exceptions of the exceptional designs, KM is working well for me. Inspecting and cleaning up the results has reduced my time spent re-kerning by two-thirds or better. So, I only have two questions at this point: 1) how do I buy a license; and 2) how much will it cost to upgrade to the new version when it becomes available?

k.l.'s picture

Related to the current version of KM:

New Plug In KM is uploaded now. (Please follow installation instructions described in 'KLTF Plug In KernMaster QUICK INSTALL.txt'. If you get any error messages when running any script then most likely the module file is still existing somewhere on your harddrive. Please send me an email when encountering any problem.)

[NC] The voodoo in the punctuation—especially the colon—appears resistant to remedy.

I would be curious if the new script version helps with this.

[NC] One thing conspicuously missing from the current version of KM is the option to discard kerning value below a certain threshold, such as -10.

[FB] Rounding is not (yet) part of the application, but it should not be too difficult to write a script for this.

Both should be part of the 'Import' script. It would be great to have both right in KM, though.

[NC] One other anomaly I noted was inconsistent kerning values for straight-side glyphs in the above font: the kern-left values for H I K L M N were different by as much as 10%. I'm also using KM's default .cla files; it occurred to me that these discrepancies might be overcome by exporting shape classes [...]

If you have set up classes properly, with a second-of-pair class covering H I K L M N, and, say, H being the key glyph of this class, then you could make sure that your .krn file only covers pairs with H being second-of-pair glyph, but no such pairs for I K L M N. Because your source font contains the respective kerning class, I K L M N would be kerned 'automatically' (and identical to H) because they are included in the H class so H's kerning is applied to them too.

In general, FLS as well as other tools need two pieces of information to generate an AFDKO-syntax kern feature: a) pair kerning and b) class definitions. KM – speaking of the current version – only needs to deal with a). It does not even need to know about b) which is present in your source font anyway.

John Hudson's picture

Karsten, is this new plug in release different from the one you sent me recently?

By the way, I came up with a quick and dirty way of producing .krn files for possible exception sets, e.g. T followed by accented letters. I create a temporary .vfb and make crude kerning classes for _1ST and _2ND glyphs that I want to be included in the .krn. Then I apply dummy kerning in FontLab between key glyphs in these classes, expand the kerning, and run your 'Generate krn from font' script. This spits out a .krn containing all the potential exception pairs. I add a few 'control pairs' to this .krn, which I will use to judge whether the Kernmaster settings need adjustment to produce tighter or looser kerning. I then run Kernmaster on the font, producing a set of exception pairs that can be imported into my already manually class-kerned font. This is particularly useful in the case of something like polytonic Greek in which the number of exception pairs can be high.

blokland's picture

Nick: ‘with crossbars extended to the left of the letters—even at 200% kerning strength, KM returns over 1200 positive values […]
This has most probably to do with the fact that KM tries to prevent collisions at any costs.
 
[…] KM handles fonts with traditional letterforms reliably and quite acceptably […]
Basically that is what it was developed for originally.
 
[…] except, of course, with some punctuation.
For the font production at DTL I circumvent some behavior of KM via additional scripts, as I wrote before. However I will discuss this issue with my colleagues at URW++.
 
[…] KM is working well for me.
Great!
 
[…] how do I buy a license […]
Te easiest way would be via the online shop at the DTL FontTools web site, but if you prefer invoicing, then we can do that too.
 
[…] how much will it cost to upgrade to the new version […]
The upgrade to KM 2012 will be free for those who purchased KM after 1 July 2011. For all other current KM users the upgrade will cost € 50.
 
FEB

k.l.'s picture

Karsten, is this new plug in release different from the one you sent me recently?

Hello John, it is the same.

dezcom's picture

Frank,

How is this going now? Ready for release soon?

blokland's picture

Chris: ‘Ready for release soon?

More or less. We have a new beta version of KeMa 2012 from which the support for the proprietary IKARUS-based formats has been removed, because this is only useful for a small group of users and it makes the stuff more complex than necessary. Still there is some planned functionality missing, but we are making progress.

In the meantime I have sent you off-list a link from which you can download the latest beta version for testing, if you like.

FEB

dezcom's picture

Thanks, Frank!

I just got your email and will give it a try.

Francesco78's picture

Two months have passed since the last post... Any news?
Another thing concerning the DTL Type Specimen (looseleaf) that is reported "out of print". Last year (october 2011) DTL Sales Department wrote to me: "We will update the information on the DTL loose-leaf specimen shortly. We are currently completely out of copies and hopefully a new edition is ready before the end of this year. We definitely keep you posted on this."
Now it's April and I have not seen any news on your DTL Online BookShop. It's a bit frustrating... Are you planning to reprint it or not?
Please let me know.

Bert Vanderveen's picture

Hi Francesco, DTL is a small operation, I think, and it must be hard for them to get all of that done in time. They could contact me and hire me to get stuff out of the door, but that would imply I had to get out of semi-retirement…

(But that would be okay.)

brianskywalker's picture

[follow]

blokland's picture

The Dutch Type Library is an independent (in all meanings of the word) company that focuses purely on the internal development of fonts and font tools. Basically we don’t work for third parties, except when we really like the proposed projects. We are actually never in a hurry and we take our time for our projects (for instance the development of DTL Fell and DTL Romulus takes more than fifteen years now). In a time in which everything seems to go faster and faster and things seem to loose value rapidly, we deliberately slow down.

This summer we will release our first new typeface (DTL Valiance) since six years (DTL Antares was the last one). In the meantime we have been working on WGL4 support for all DTL typefaces. Slowly but steadily we will release these fonts, like we just recently did with DTL Argo.

The DTL looseleaf type specimen is one of our favorite non-profitable projects (the applied material alone costs more than the price we ask for it). The specimen is produced in small quantities, which makes it easy to update. Also the bookbinder, who makes the binders by hand, is actually not capable of producing large quantities. So normally new editions are used to supply long-waiting customers.

Concerning the development of the new edition of DTL KernMaster, we are currently looking at which level we will support the UFO format. I will keep you all posted, of course.

FEB

brianskywalker's picture

Will you be releasing a linux version?

blokland's picture

Briän: ‘Will you be releasing a linux version?

Yes!

FEB

Francesco78's picture

Sorry to come back to this subject, I'm just curious because I'd be very interested in buying it: any news about the release date and the price of this program?
Thanks in advance!

blokland's picture

Francesco: ‘[...] any news about the release date and the price of this program?

The release of KM 2012 is somewhat delayed, because the focus at DTL/URW++ is at the moment especially on the release of version 3.0 of DTL OTMaster coming September. This release will include a new Light version for just € 99, from which the OpenType layout features export/import and the (in the meantime enhanced) glyph editor will be stripped.

The price for KM 2012 will be € 255.

If you are interested in testing, I can supply you with the latest beta version of KM 2012 for Snow Leopard and Lion. It would for instance be interesting to compare the output with that of the just announced TypeFacet Autokern (or any other application for kerning), and to show some results on this forum.

FEB

Francesco78's picture

Thanks for the info, Frank! I'm a happy user of DTL OTMaster so I'm very pleased to hear that you're working on a software's update (by the way, I bought the full version of DTL OTMaster in August of 2011: how much will it cost to upgrade to the new version?).
I would really like to try the latest beta version of KM 2012: I will send an e-mail to your address.
Thanks for everything!

Francesco

twardoch's picture

(tofollow)

Ramiro Espinoza's picture

Hi there,

I am trying to test the current beta version of KernMaster but I have no clue how to use it and I can't figure it out. Is there anybody out there with some experience testing it?
My attempts only get some changes in few already existing kerning pairs (5) but I can't get new ones added.

TIA.

R.

Syndicate content Syndicate content