importing kerning classes to FontLab

[GeorgS]

Hi,

I just tried to open an .ufo in FontLab and the checkboxes for right
and left kerning class are missing. How do you deal with this? Is
there any "standard" class name suffix to determine if the class is a
left or right class?

It could be implemented like this:
http://forum.fontlab.com/python-scripting/adding-kerning-classes-to-the-font-t406.0.html;msg1237#msg1237

Thanks
Georg

[Frank Grießhammer]

Georg,
FL classes have a different syntax as the OpenType Classes, as found in an UFO.
It’s only in Fontlab that you have to differentiate a class being “left” or “right”. (I actually think it’s a bit confusing.)
An usual notation differentiating side for an OT class would be something like @_LAT_classname_LEFT

I had the same problem a while ago and got over it writing a script that would strip the classes out of a .fea-file and convert it to a .flc

Does that help you in any way?
If you are interested in more detailed information, just get in touch.

Cheers,
Frank

> --
> You received this message because you are subscribed to the Google Groups "RoboFab" group.
> To post to this group, send email to rob...@googlegroups.com
> To unsubscribe from this group, send email to robofab-u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/robofab?hl=en
>
> Messages from newly joined members are subject to moderation.
> Download RoboFab and documentation at http://robofab.com

[James Puckett]

I do no kerning in FontLab and use Metrics Machine to export the OpenType classes in the UFO to a .fea file which I then copy/paste into Fontlab. It’s not especially efficient but it’s not really any less efficient than doing it with custom scripts or building my test fonts with the FDK. But you know, maybe this problem with go away “by the end of the year.”

[Ben Kiel]

Just to chime in here, the model of being able to have a class be both right and left in FontLab at a fundamental level is a really, really confusing/not such a great thing.  If you kern in FontLab or MetricsMachine, separating your classes into right and left will only help one in the future. Yes, it can seem like a duplication of effort on the front end, but on the backend, not being able to know with 100% certainty if something is a left or right group only leads to pain and confusion when you need to extend/update/fix something in the future, either by hand or with scripting, but especially scripting. The MetricsMachine convention is to prefix a group with @MMK_L_ or @MMK_R, for left or right group. This happens automatically in the program. If one is kerning in FontLab, adopting a similar consistent naming scheme will help if one ever needs to script a kerning change.

Best,

Ben

Ben Kiel

http://www.houseind.com

Direct Dial: (302) 766-7593

[Georg Seifert]

Hi Ben,

I know all the limitations of the classes in FontLab. I just trying to find a practical solution to deal with it. The script from Eigi is a good example. 

I would propose a small addition to the way RoboFab exports and imports .ufos from FLS. As the format used for this is different from the format used be MetricsMachine (no class kerning, the ' as key glyph marker …) I would not hurt to ad _l and _r to the class names (The short suffix increases Legibility a lot, and make it clear that it is a FLS class, not a MetricsMachine class)

This would improve the workflow a lot.

Georg

[Tal Leming]

On Nov 7, 2010, at 2:37 PM, GeorgS wrote:

> I just tried to open an .ufo in FontLab and the checkboxes for right
> and left kerning class are missing. How do you deal with this? Is
> there any "standard" class name suffix to determine if the class is a
> left or right class?

I've explained this to you before (August 11, 2009 to be precise), but I'll summarize...

The class kerning models used by FontLab and the UFO are incompatible. FontLab uses a key glyphs and the class kerning values are implied from the glyph kerning values. The UFO allows kerning of the actual classes. A 1:1 translation between the two is not possible.

As for the prefixes you are suggesting, we have a proposal in UFO 3 that does something similar:

http://unifiedfontobject.org/roadmap.html#kerning

This will solve some difficulties, but the model incompatibility with FontLab is not one of them.

Tal

[Georg Seifert]

I know about the incompatible class kerning models. I just want to find a useable workaround, to be able to export a font from FontLab, do something with it (converting the kerning back and forth or whatever I like) and read it back in and be in a similar state than before.

I will do add some code, similar the code from Eigi to my copy of the objectsFL.py implementation (this would probably go to the readUFO and writeUFO method).

My question is if anyone is interested in this and if it should end up in the main repository?

I would define a unique prefix or suffix that is added to the class name on export according to the checkboxes in FLS. On import, the classname is checked for the identifier, the checkboxes are set and the suffix is removed from the class name.

Two possible formats:
prefix with @FLS_L /@FLS_R
Suffix with _l or _Left and _r or _Right

The distinction from the MM class names is necessary because of the well know incompatibility to not get confused.

I think this can be added without changing the specification as the FontLab class style is a hack anyway.

Georg

[Ben Kiel]

> Two possible formats:
> prefix with @FLS_L /@FLS_R
> Suffix with _l or _Left and _r or _Right

How would the case of a group being both left and right be handled?

Ben

[Frank Grießhammer]

I worked around this allowing no more both-sided groups in FL any more.

Increases the number of groups, but also decreases level of confusion! :)

Frank 

[Georg Seifert]

Groups for both sides don’t have an addition.

Georg

[Tal Leming]

On Nov 8, 2010, at 8:49 AM, Georg Seifert wrote:

> I know about the incompatible class kerning models. I just want to find a useable workaround, to be able to export a font from FontLab, do something with it (converting the kerning back and forth or whatever I like) and read it back in and be in a similar state than before.
>
> I will do add some code, similar the code from Eigi to my copy of the objectsFL.py implementation (this would probably go to the readUFO and writeUFO method).

It's not necessary to hack the core RoboFab code to do what you want for your workflow. In fact, that is a dangerous way to do it because the next RoboFab installation will wipe out your changes. The way to do it is to make your own export/import script. I made some changes to the UFO export/import functionality in the last release to make these kinds of things easier. I even did this in my own UFO importer/exporter:

http://code.typesupply.com/browser/applicationScripts/FontLab/UFO/UFOCentral.py

You can override the default kerning and group import and do whatever you want.

Tal