Convert from vfb

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 PuckettJames Puckett Posts: 1,640
    Install the trial version of Fontlab studio and use Georg’s export scripts to covert to .glyphs files
  • ... which is available here: https://github.com/schriftgestalt/Glyphs-Scripts
    Or, if you need UFOs, use UFOcentral: http://code.typesupply.com/wiki/FontLabScripts
  • Ooh, the trial had not really ocurred to me. Thanks, will try that!
  • Chris LozosChris Lozos Posts: 1,151
    Georg's script does a much better job than export to ufo. Thanks, Georg!
  • Are you on Glyphs now too, Chris?
  • Chris LozosChris Lozos Posts: 1,151
    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.
  • After a career dealing with Ikarus M and Letraset Font Studio I am so happy with where I am now.
    Good luck with your UFOs.

    Me, I'm concentrating on the natural things: Powerful Gasoline, A Clean Windshield and a Shoe Shine!
  • Chris LozosChris Lozos Posts: 1,151
    But James, Flying Saucers are faster than cars, even if they have good gas and a clean windshield ;-)
  • Max PhillipsMax Phillips Posts: 463
    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 LozosChris Lozos Posts: 1,151
    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.
  • 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 PhillipsMax Phillips Posts: 463
    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 LozosChris Lozos Posts: 1,151
    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 SimonsonMark Simonson Posts: 1,130
    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.
  • Is there any macro for that?
  • 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 HudsonJohn Hudson Posts: 1,645
    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 LozosChris Lozos Posts: 1,151
    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?
  • John HudsonJohn Hudson Posts: 1,645
    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.
  • Everybody came up with custom pre or suffixes to mark the classes. But this should have been done one the export script level.
  • 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 LozosChris Lozos Posts: 1,151
    Not just you ;-)
  • Chris LozosChris Lozos Posts: 1,151
    edited July 2013
    After a discussion with Karsten several months ago, I have switched my method to the " _1st and _2nd" way of identification.
  • James PuckettJames Puckett Posts: 1,640
    edited July 2013
    This is why I only kerned one font in Fontlab.
  • James MontalbanoJames Montalbano Posts: 897
    edited July 2013
    I've kerned over a 1000 fonts in FontLab. No problems so far.
  • 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 LaanPaul van der Laan Posts: 205
    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.
  • Well if moving kerning data is the problem, I don't have one, since I don't have the need to move it to another app.
  • John HudsonJohn Hudson Posts: 1,645
    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.
  • 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.