Home› Type Design Software
Options

Convert from vfb

Kemie GuaidaKemie Guaida Posts: 21
in Type Design Software
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

  • Options
    James PuckettJames Puckett Posts: 1,970
    Install the trial version of Fontlab studio and use Georg’s export scripts to covert to .glyphs files
  • Options
    Christoph KoeberlinChristoph Koeberlin Posts: 51
    ... which is available here: https://github.com/schriftgestalt/Glyphs-Scripts
    Or, if you need UFOs, use UFOcentral: http://code.typesupply.com/wiki/FontLabScripts
  • Options
    Kemie GuaidaKemie Guaida Posts: 21
    Ooh, the trial had not really ocurred to me. Thanks, will try that!
  • Options
    Chris LozosChris Lozos Posts: 1,458
    Georg's script does a much better job than export to ufo. Thanks, Georg!
  • Options
    Craig EliasonCraig Eliason Posts: 1,398
    Are you on Glyphs now too, Chris?
  • Options
    Chris LozosChris Lozos Posts: 1,458
    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.
  • Options
    [Deleted User][Deleted User] Posts: 0
    The user and all related content has been deleted.
  • Options
    Chris LozosChris Lozos Posts: 1,458
    But James, Flying Saucers are faster than cars, even if they have good gas and a clean windshield ;-)
  • Options
    Max PhillipsMax Phillips Posts: 474
    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?
  • Options
    Chris LozosChris Lozos Posts: 1,458
    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.
  • Options
    Georg SeifertGeorg Seifert Posts: 669
    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.
  • Options
    Max PhillipsMax Phillips Posts: 474
    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.
  • Options
    Chris LozosChris Lozos Posts: 1,458
    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.
  • Options
    Mark SimonsonMark Simonson Posts: 1,654
    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.
  • Options
    PabloImpallariPabloImpallari Posts: 778
    Is there any macro for that?
  • Options
    Georg SeifertGeorg Seifert Posts: 669
    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.
  • Options
    John HudsonJohn Hudson Posts: 2,977
    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.
  • Options
    Chris LozosChris Lozos Posts: 1,458
    edited July 2013
    "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?
  • Options
    John HudsonJohn Hudson Posts: 2,977
    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.
  • Options
    Georg SeifertGeorg Seifert Posts: 669
    Everybody came up with custom pre or suffixes to mark the classes. But this should have been done one the export script level.
  • Options
    Craig EliasonCraig Eliason Posts: 1,398
    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?
  • Options
    Chris LozosChris Lozos Posts: 1,458
    Not just you ;-)
  • Options
    Chris LozosChris Lozos Posts: 1,458
    edited July 2013
    After a discussion with Karsten several months ago, I have switched my method to the " _1st and _2nd" way of identification.
  • Options
    James PuckettJames Puckett Posts: 1,970
    edited July 2013
    This is why I only kerned one font in Fontlab.
  • Options
    [Deleted User][Deleted User] Posts: 0
    edited July 2013
    The user and all related content has been deleted.
  • Options
    Georg SeifertGeorg Seifert Posts: 669
    The problem is not doing the kerning but moving the kerned data to another app for whatever operation you like to do there.
  • Options
    Paul van der LaanPaul van der Laan Posts: 242
    edited July 2013
    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.
  • Options
    [Deleted User][Deleted User] Posts: 0
    The user and all related content has been deleted.
  • Options
    John HudsonJohn Hudson Posts: 2,977
    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.
  • Options
    Adam TwardochAdam Twardoch Posts: 507
    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.
Sign In or Register to comment.