The service

Terms of Service

The service is the creation of new spacing and kerning values to be imported into fonts. These values are generated automatically (autospacing and autokerning)  by the iKern program after specific inputs consequent to studies and tests performed by a ‘human’ operator.

The submitted fonts can be either in Fontlab Studio .vfb or UFO format. Multiple Masters fonts are welcome too. If features are present they have to be necessarily correct and compilable.

Preliminary to the iKern processing is the building of a specific database for each font. To speed up input operations and reduce the risk of errors a series of automatic data processings have been introduced. As a consequence the fonts submitted should have Unicode compliance and a correct, standard and coherent naming system possibly using the Adobe naming convention and extensions. So, for example, a ffb ligature should be called f_f_b and a small cap a should be called a.smcp.

Unless otherwise requested class kerning will be produced using the generated classes (kern classes eventually already present would be overriden) and after having submitted an opportune standard pair list.

If a typeface is part of a type family then it should be processed along with the rest of the family for obvious consistency and time saving reasons. It would be opportune, in this case, that glyphs number and glyph indexes coincide between family members.

Unless otherwise stated or authorized, confidential informations won’t be disclosed and reasonable precautions to keep confidential the informations received will be taken. Opportune Non Disclosure Agreements can be signed if required.

All the different possible fitting solutions needed to arrive at the desired and suitable result will be provided; developed after a meaningful feedback. Unless otherwise stated, the customer should be responsive and prompt enough to let the feedback and finalizing process be completeted within 60 days from the first shipment of a reworked file.

Meditated, correct and definitive outlines to work on are expected to be received. But it’s also possible to procede by partial runs on typefaces in development to help work critical shapes out with less effort. Unless otherwise stated the typefaces received are considered final. However it’s always possible to change outlines after test even during finalizing phase but without changing the glyph set (glyphs number, glyph names, glyph indexes).

It is also possible to request any kind of type metrics elaboration. They’re numbers, in the end, and numbers can be manipulated. Probably the opportune solutions or required features have already been developed. Otherwise they could.

The service price is decided case by case after estimate.

Payments are due after complete satisfaction.

Technical notes

Interpolations can be handled. There are two different ways depending on the chosen workflow. Interpolating the iKern input data applied on interpolated shapes or interpolating the iKern outputs (spacing and kerning; in this case interpolated ‘kern’ features with classes could eventually be provided) in the Multiple Masters way. From a conceptual point of view the first solution could be prefereable: the real and final shapes would be effectively used so the working model would be more faithful because intermediate instances wouldn’t inherit behaviours proper of geometric specificities only present in the masters. The opportune strategy, that could also consider the introduction of intermediate masters, should be decided and agreed case by case.

The import into a FLS file of the new metric data is performed by a wonderful macro written by Karsten Luecke. The macro imports into FLS the ‘kern’ feature as produced by iKern (containing kern classes and kerning values) also updating the internal “kerning assistance” (both FLS classes and kerning values). This way is possible an immediate testing inside FLS; but it also happens that kern classes are defined twice: this may lead to a “warning of double class definition” if the “General Options > Unicode and OpenType > Add all glyph classes to OpenType definition code” option is checked. This option setting depends on the adopted OpenType production strategy: relying or not on internal FLS class definition. It’s just a warning and not an error because the two kern class sets are perfectly synchronized. The inclusion of the ‘kern’ classes into the feature is optional depending on the desired strategy: usually it’s a decision based on the structure or the received files; anyway it’s better to explicitly tell the desired mode.

Class kerning compiling troubleshooting for fonts created using the Karsten’s macro:

a) If you get a warning of double class definition you alternatively may:

  • ignore the warnings (recommended);
  • uncheck the “General Options > Unicode and OpenType > Add all glyph classes to OpenType definition code” option;
  • delete the kern classes definition from the ‘kern’ feature code;
  • delete the FLS kern classes;
  • ask for a file not containing double class definition.

b) If you get an error of “glyph class not defined” you alternatively can:

  • check the “General Options > Unicode and OpenType > Add all glyph classes to OpenType definition code” option (recommended);
  • ask for a file containing double class definition.