Convert from vfb

Options
I have gone from working in typetool/windows to glyphs/mac. So I'm stuck with a lot of old source files in .vfb format.
Is there any easy way to convert these to ufo? Unless I missed something, not even the new transtype will do this...
Tagged:
«1

Comments

  • James Puckett
    James Puckett Posts: 1,978
    Options
    Install the trial version of Fontlab studio and use Georg’s export scripts to covert to .glyphs files
  • Christoph Koeberlin
    Options
    ... which is available here: https://github.com/schriftgestalt/Glyphs-Scripts
    Or, if you need UFOs, use UFOcentral: http://code.typesupply.com/wiki/FontLabScripts
  • Kemie Guaida
    Options
    Ooh, the trial had not really ocurred to me. Thanks, will try that!
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Options
    Georg's script does a much better job than export to ufo. Thanks, Georg!
  • Craig Eliason
    Craig Eliason Posts: 1,412
    Options
    Are you on Glyphs now too, Chris?
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Options
    Craig, I bought it when it came out but have yet to use it all the way through. I am taking the class atTypeCon to get insights on moving files from FL to Glyphs. So, no, not yet. I am quite tired of being on cue with FL to ever do something, though. I am also looking at RoboFont, which I also bought.
  • [Deleted User]
    Options
    The user and all related content has been deleted.
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Options
    But James, Flying Saucers are faster than cars, even if they have good gas and a clean windshield ;-)
  • Max Phillips
    Max Phillips Posts: 474
    Options
    Georg's script does a much better job than export to ufo.
    Could you be more specific, Chris? What's wrong w/ exporting thru FL?
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Options
    As I recall, Max, it was a hit or miss issue with straight ufo. With Georg's script it is always a hit with nothing to fix or find. You still have to fix the foot mark issue coming from FL class naming system though.
  • Georg Seifert
    Options
    The main problem with the UFO export for me were the kerning classes. The ufos exported from FLS are not valid as they use the key glyph system instead of converting them to the OpenType system.
  • Max Phillips
    Max Phillips Posts: 474
    Options
    Thanks, Chris and Georg. I don't know what the foot mark issue is, but it sounds gnarly, and I'll do my best to avoid it.
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Options
    The foot mark (or vertical apostrophe) is used by FontLab to delineate "Key Glyphs" in class kerning but this system is not used by the ufo type design software so you have to remove them all.
  • Mark Simonson
    Mark Simonson Posts: 1,672
    Options
    In fact, the key glyph concept is unique to FontLab's kerning assistance feature. There is no such thing as a key glyph in OT classes, for kerning or otherwise. It's not just a UFO thing.
  • PabloImpallari
    Options
    Is there any macro for that?
  • Georg Seifert
    Options
    The foot mark (or vertical apostrophe) is used by FontLab to delineate "Key Glyphs" in class kerning but this system is not used by the ufo type design software so you have to remove them all.
    If you just remove all "foot marks", you remove all class kerning from your font.
    Is there any macro for that?
    Once you imported the UFO there is not much you can do. And one more thing is missing to be able to convert it properly. There is no information about if the class is a left or right class. I did suggest some solutions to the problem years ago.

    I had support to convert FLS kerning on UFO import in Glyphs but removed it in favor of my own import/export scripts.
  • John Hudson
    John Hudson Posts: 3,036
    Options
    There is no information about if the class is a left or right class.
    In my kerning workflow, I maintain this information in the class names, and have a script that sets the FL flags accordingly. I don't know if this is a usable work around for people dealing with FL-UFO workflows; mine is FL-VOLT.
  • Chris Lozos
    Chris Lozos Posts: 1,458
    edited July 2013
    Options
    "There is no information about if the class is a left or right class"

    What if the class name contains that information in a consistent searchable way?
  • John Hudson
    John Hudson Posts: 3,036
    Options
    This is a typical kerning class name in my workflow:

    _KERN_A_1ST

    In FontLab, the leading _ automatically identifies this as a kerning class, but I include KERN as a key word because when the classes are written to VOLT format the leading _ is stripped. The suffix _1ST of course indicates that this is a first-glyph-in-pair class. I avoid kerning classes that are used for both first and second glyphs, preferring to have duplicate classes labelled _1ST and _2ND.

    By the way, I strongly recommend thinking about classes in terms of 1st and 2nd glyphs, not left and right glyphs. You may not deal with right-to-left writing systems now, but you might one day. And tool developers should definitely develop this habit of thought.
  • Georg Seifert
    Options
    Everybody came up with custom pre or suffixes to mark the classes. But this should have been done one the export script level.
  • Craig Eliason
    Craig Eliason Posts: 1,412
    Options
    You may not deal with right-to-left writing systems now, but you might one day
    Or even long before that day you might get hopelessly confused about whether by _LEFT_A you meant these glyphs are similar to the A on the left side, or they should be kerned like A when it is on the left of other glyphs.

    Or is that just me?
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Options
    Not just you ;-)
  • Chris Lozos
    Chris Lozos Posts: 1,458
    edited July 2013
    Options
    After a discussion with Karsten several months ago, I have switched my method to the " _1st and _2nd" way of identification.
  • James Puckett
    James Puckett Posts: 1,978
    edited July 2013
    Options
    This is why I only kerned one font in Fontlab.
  • [Deleted User]
    [Deleted User] Posts: 0
    edited July 2013
    Options
    The user and all related content has been deleted.
  • Georg Seifert
    Options
    The problem is not doing the kerning but moving the kerned data to another app for whatever operation you like to do there.
  • Paul van der Laan
    Paul van der Laan Posts: 242
    edited July 2013
    Options
    Using the footmark to designate key glyphs for kerning classes, are not required in FontLab actually. I you define a kerning class without any footmarks then the first glyph in that class will be considered a key glyph. (See included picture.)

    Of course the whole concept of a “key glyph” for OpenType class kerning in FontLab is flawed, and not a faithful implementation of the OpenType standard. So the only proper way to export that kerning is as pure OpenType feature code, which will require filters and/or assumptions by other software to interpret it again.
  • [Deleted User]
    Options
    The user and all related content has been deleted.
  • John Hudson
    John Hudson Posts: 3,036
    Options
    Of course the whole concept of a “key glyph” for OpenType class kerning in FontLab is flawed, and not a faithful implementation of the OpenType standard.
    Out of interest, how do other tools distinguish between class and exception kerning? At the OpenType Layout level, this is a matter of lookup structure and ordering, but that would be a pain in the neck to have to do manually.
  • Adam Twardoch
    Options
    This is only partially related but TransType 4 has an automatic class generation feature on the fly: if you have a large "plain kerning" list (inside a TTF "kern" table or in an AFM file), when converting to OTF, TransType 4 will automatically compress the kerning into class-based GPOS kerning with exceptions using identical kerning values. This is not necessarily very useful for kerning fonts from scratch, but is useful for creating optimized GPOS kerning.

    We're currently developing a fully new kerning workflow for our "Victoria" apps, and TransType 4 is just the first emanation of this work.