vfb2ufo

[Yuri Yarmola]

Before we release the tool, it would be cool to test it. 

Please, let me know if you want to it try and specify which version do you need: Win or Mac.

vfb2ufo is a very simple and fast console app which can convert fonts both ways.

Currently it converts only the first master of the MM vfb, can handle PS hints, visual TT instructions and OT layout data (both .fea and binary, which is stored in TTX-compatible format).

Custom UFO data that it generates is supported in latest build of TransType 4, so, for example, if you put some TT hinting into UFO, it will be used to build TT font file.

vfb2ufo will be available for free download when finished.

[Frederik Berlaen]

He Yuri

I would like to test vfb2ufo.

What UFO version(s) does it support? 

Is there data in a vfb file, which will not convert or be added the UFO? 

thanks!

gr Frederik

www.typemytype.com

--
You received this message because you are subscribed to the Google Groups "Unified Font Object Specification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ufo-spec+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Yuri Yarmola]

Frederik,

It is doing UFO2, with one element of UFO3: storage of binary OT tables in TTX format is done in 'data' folder.

Most code is UFO3-ready, to which we will switch very soon: we need to store images and guidelines.

For more advanced Vicroria data (shapes hierarchy, power guidelines, interpolated elements, etc) we currently considering 2 options:

1. Create our own storage format.

2. Store "compatible" data for glyphs in UFO3 "layer" (something very similar to preview layer of Photoshop's PSD) and more complicated things as 'lib' element.

Currently we do option 1 but I think we will try to switch to option 2, that will simplify many things in the future.

You need vfb2ufo for Mac, right?

Best regards,

Yuri

воскресенье, 1 декабря 2013 г., 23:02:02 UTC+4 пользователь Frederik Berlaen написал:

[Tal Leming]

Hi Yuri,

This sounds very useful. I would love to test it (Mac version, please). 

Could you document the non-spec data locations and formats? Something like what Read did for the PS hint data would be great. Speaking for myself, I would like to know how the TT instructions are stored. I have my own representation of that, but I would rather use yours so that the conversion to VFB is more seamless. 

That's,

Tal

--

[Frederik Berlaen]

It is doing UFO2, with one element of UFO3: storage of binary OT tables in TTX format is done in 'data' folder.

what happens when the UFO data folder isnt available, like after a "save as" in most ufo apps?

what happens when for example kerning is being added by MetricsMachine and the data is not compatible anymore with the "private" data folder?

You need vfb2ufo for Mac, right?

yes, please

thanks

gr Frederik

www.typemytype.com

[Yuri Yarmola]

Tal,

For PS hinting we use the same structure that Adobe is using for their autohining (published here, in this group).

For TT visual hints we using some very simple plist for font-level data and some XML for glyph data. Basically it is flexible now and some changes in representation can happen as result of testing. So it is not final right now.

Yuri

воскресенье, 1 декабря 2013 г., 23:57:04 UTC+4 пользователь Tal Leming написал:

[Yuri Yarmola]

If there is no Data folder, it means that font doesn't have "binary" OT layout tables, much like it can be in VFB (we store both FEA layout and binary layout there).

What to do when both OT layout info is present (FEA and binary/TTX), it is very interesting question. Currently we give preference to binary data. Of course, we do verification and lookup/feature subsetting if necessary.

Yuri

воскресенье, 1 декабря 2013 г., 23:58:37 UTC+4 пользователь Frederik Berlaen написал:

[Adam Twardoch (List)]

On 01 Dec 2013, at 20:58, Frederik Berlaen <fred...@typemytype.com> wrote:

> what happens when for example kerning is being added by MetricsMachine and the data is not compatible anymore with the "private" data folder?

This is something I asked about back in April on the RoboFab list:
https://groups.google.com/forum/#!topic/robofab/9sZd5p7t9_g

There are largely several levels of any information about some font data:
Level 1.0. "deliverable code": binary SFNT data in the final container (TTF/OTF, WOFF, TTC etc.), signed, customized etc.
Level 1.5. "machine code": "master" binary SFNT data
Level 2.0. "assembly code": source representation of SFNT data (let's assume for simplicity that it's TTX XML).
Level 3.0. "source code" Middle level: native UFO XML information
Level 4.0. "code generator code": "above UFO" information, e.g. Superpolator masters with interpolation info, Kalliculator skeletons and pen strokes, Victoria parametric info etc.

Kerning is a good example where there are even more levels:
Level 1.0 and 1.5 as above.
Level 2.0. "assembly code": Lowest level: XML representation of the "GPOS" table and the "kern" table
Level 2.5. "intermediate code": FEA syntax information for GPOS "kern" feature and, potentially, separate contents of the "kern" table, or VOLT syntax for GPOS "kern" feature
Level 3.0. "source code": Native UFO information about kerning groups and kerning values, and potentially some information as to which pairs should also go into the "kern" table
Level 4.0. "code generator code": High-level information, e.g. Victoria dynamic group definitions or formula-based kerning values

Taking Kalliculator as an example, a glyph would typically have three levels (let's forget about the 1.x levels now):
Level 2.0. TTX code for "glyf" or "CFF " representation; in case of "glyf", potentially with bytecode hinting.
Level 3.0. UFO code in GLIF format, potentially with Adobe-compatible PS hinting and FontLab-compatible TT visual hinting
Level 4.0. Kalliculator's own "glyph generation" data, the shape of the skeleton and some pen definitions

In case of Superpolator, there could be instances on levels 2 and 3 (e.g. with hinting info added), and then there could be the Superpolator masters in Level 4.

Generally speaking, I think a good tool and format should have the ability to:
1. Detect when a lower-level code becomes out-of-sync ("outdated") due to changes in higher-level code.
2. Allow the user to lock portions of lower-level code i.e. protect them from being overwritten.
3. Allow the user to overwrite the unlocked portions of lower-level code with code generated from updated higher-level code.
4. Whenever a tool deems it recommended that lower-level data is overwritten, but that lower-level data is locked, it should ask the user: "Unlock NNN and overwrite?" (Yes, Yes for All, No, No for All). For certain types of data, "Keep both" could also be an option.
5. The user should be able to set the preference whether to: present this question every time, overwrite every time or skip every time, and whether to log the overwrites and skips.

All that should happen on font-wide, glyph group, glyph and, where applicable, sub-glyph scope.

Very basic conflict resolution can be done using timestamps. Certain version control systems also have this functionality, but that usually applies to older and newer versions of the same data. What I'm talking about is mostly when a more complex process has to transform one type of data into another.

Is this type of marking certain data as "locked" part of UFO?

It would be very useful. For example, I could declare that my "kern" feature definition in features.plist is "locked" and then it would not be overwritten if I change the UFO kerning. But if it is unlocked and I change the UFO kerning, then the "kern" feature gets regenerated.

The same applies really to every aspect of the font production chain. For example, certain kerning pairs or sidebearings etc. could be "locked" by the user, and then if the user runs an autokerning/autospacing algorithm, that algorithm will do its thing only on the unlocked pairs or sidebearings, but it will not touch the locked entries.

If the build process is so that at some point the font is output as a set of TTX tables, and there is an older version of the tables already present, and the user has declared that the "name" table TTX file is "locked", then the outputting tool would honor that and produce newer versions of all the other table files, but keep "name" as it was before.

What do you think about that? Of course tools would need to me made aware of that.

Best,
Adam

[Ben Kiel]

Adam,

Isn’t a lot of what you’re talking about if you have a UFO, a TTX and a TTF/OTF of the same font in hand? I don’t think that the UFO format can or should know anything about the output formats.

I do see your point about a GPOS kern feature vs the kerning.plist, but this is more of a case for the tool which touches the kerning, less for the UFO itself. The tools making adjustments need to be aware of things that may conflict (and, for the UFO, the major point may be kerning) and ask the user, as you point out below.

Best,
Ben

[Tal Leming]

These are interesting points. Almost all of this can be summarized as "data duplication is a nightmare." That's why we have a guideline against duplicating data. As it stands now, features.fea is the place where data duplication may occur. It's unfortunate that it is possible, but that is the trade off that we had to make. The spec addresses this in the features.fea section:

It is important to note that the features file may contain data that is a duplicate of or data that is in conflict with the data in kerning.plist, groups.plist and fontinfo.plist. Synchronization between the files is not a requirement of this specification. Synchronization is up to the user and authoring tool developers.

The idea of establishing a locking mechanism is interesting, but I'm not convinced that it will solve more problems than it creates. We have worked very hard to not dictate authoring tool behavior beyond the data types and the general recommendation that the user's data not be destroyed silently. If a locking mechanism is established, we will have to define how authoring tools must work with that. That gets into defining user interactions and that is thin ice for a format specification.

I do see your point, though. I think the solution is to not allow duplicated data into the spec. It's fine for a specific authoring tool to define (and publish) their own location and data format for storing duplicated data as long as the location and format don't violate the structure of the UFO. (In other words, they can't put a file or directory anywhere that they aren't allowed and data put into the lib must be in the appropriate format.) It is up to that authoring tool to establish its own rules for detecting and handling conflicting data.

As for your Level 4 data... This is an interesting area. The lib and data directory allow the storage of these. If there starts to be some common themes, these should be considered for standardization. The same goes for higher level family files. That wouldn't necessarily fit in UFO, but a higher level offshoot family format could handle that.

Tal

[Andreas Eigendorf]

Hello Yuri,

I would like to test the win version please.

Best

Eigi

[Joancarles Casasín]

Hei Yuri,

I'd like to test it too.

Mac version.

Thanks,

Joancarles

2013/12/3 Andreas Eigendorf <andrease...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Unified Font Object Specification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ufo-spec+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
- - -

jca

[Adam Twardoch (List)]

On 02 Dec 2013, at 03:38, Ben Kiel <b...@benkiel.com> wrote:

> Isn’t a lot of what you’re talking about if you have a UFO, a TTX and a TTF/OTF of the same font in hand? I don’t think that the UFO format can or should know anything about the output formats.

But it does :) The UFO format is very specifically tied to OpenType. Most of fontinfo.plist is "openType*" entries which are supposed to be passed on directly to OTF or TTF font files.

Or do you mean something else by "knowing about the output formats"?

A.

[Adam Twardoch (List)]

On 02 Dec 2013, at 05:11, Tal Leming <t...@typesupply.com> wrote:

> These are interesting points. Almost all of this can be summarized as "data duplication is a nightmare."

I wouldn't necessarily agree that this is always the case.

Also, I don't think it's really data duplication we're talking about. The path from most general to most specific (or the other way around) is a common case in pretty much all in life. Starting with law: in Europe, you have a constitution, EU law, country law, then regional or municipal law, and then you company-specific regulations and individual contracts. In the U.S., there is a constitution, federal law, state law etc., down to the level of individual contracts.

This is the subsidiarity principle: "the idea that a central authority should have a subsidiary function, performing only those tasks which cannot be performed effectively at a more immediate or local level".

If you apply the subsidiarity principle to font creation, it would mean that, in absence of any special tagging mechanism ("locking" or otherwise), the lower-level (more specific) information should take precedence over the higher-level information (more general). But when applied blindly, this principle would mean that, once a lower-level information -- which can be understood as a "cache" -- is generated, it always takes precedence, i.e. there is no way to override it.

The GPOS table in an OTF can be seen as a cache of the GPOS table in TTX, the GPOS data in TTX as a cache of the GPOS definition in FEA, the GPOS definition in FEA as a cache of the GPOS definition in kerning.plist/groups.plist, and that as a cache of higher-level data (the "code generation level").

For the kinds of applications like Kalliculator, Superpolator or some of our Victoria technologies, the UFO is a "cache", not the source. But for other applications, the UFO is the source. So in a cascade of high-to-low-level caching, you may have user operations which "intervene" at any level of the caching chain.

The point is to determine "significant" and "insignificant" interventions of that kind. Imagining (for simplicity) that the font creation path is UFO -> TTX -> OTF/TTF (rather than the current ufd2fdk workflow), when going from UFO to TTX, some portions of the TTX should ideally be overwritten and others should be left alone.

Currently, the timestamp of a file is one mechanism that is used to resolve these kinds of conflicts, even in a pure-UFO workflow (switching between RoboFont and Prepolator, for example). That's already a decent mechanism, especially if the info is itemized enough (which is true in case of UFO, at least to some extent).

I'm raising the questions here not necessarily because I want the UFO spec extended somehow. I'm raising them more to get feedback from others on this list as to what they are doing and to make sure that we at FontLab are "doing the right thing". So thanks for your feedback so far.

Best,
Adam

[Ben Kiel]

Adam,

> Or do you mean something else by "knowing about the output formats"?

The way I read your was not about the bits that in the UFO tied to the output spec, but that you were suggesting changes to the UFO spec that were based on having various binaries or decompiled binaries (TTX) of fonts around and you were searching for a way to keep them somewhat in sync with each other with a locking mechanism baked into the UFO format. My comment was that I didn't think it was the job of the UFO format to know about built binaries of it's data — this seems like the job of tools, not formats.

My apologies if I've misinterpreted your message.

Best,
Ben

[Adam Twardoch (List)]

If we take the analogy of the "font creation chain" to CSS (i.e. the *cascading* style sheets):

In CSS, by default, the subsidiarity principle applies: more specific definitions override the more general definitions.

However, CSS has the "!important" property which can indicate that a certain portion is, well, "important", i.e. that it should take precedence over any other potentially conflicting information. In particular, the !important property in CSS allows a higher-level set of information to override the lower-level information.

It is still up to the tool (i.e. the browser) to interpret this property properly. And the general advice to CSS authors is to use the !important property wisely, i.e. only in some specific cases.

But it has been included in the format. This is the kind of "locking" mechanism, or at least a "hint" to tools which says: OK, if there is a conflict, do not use the "normal" cascading/inheritance model but make an exception and treat *this* as the important source.

Again, I'm not saying this is something that has to go into the UFO. But perhaps, if a similar flag/attribute were introduced to *both* UFO and TTX, we might have a chance to improve the current situation. Tool makers would, of course, have a choice whether to follow that hint or not.

Right now, we're sort of in a similar situation as HTML/CSS is in case of browser vendors. There is the HTML/CSS standard, and various browser vendors try their best to adhere to most of the standards.

UFO is, fortunately, much more conservative in development than HTML/CSS, so there is no such "implementation race". Yet we have a small number of independent implementors of UFO:
* RoboFab/ufoLib used in RoboFont, Metrics Machine etc.
* FontForge
* Glyphs
* Adobe FDK for OpenType
* FontLab
* at least one more in-house implementation by a foundry
* possibly DTL joining soon(?)

I'm trying to think of scenarios where interoperability can be ensured, without sacrificing flexibility of various tools and workflows. One situation where some efforts may be needed is the "vertical hierarchy" of formats that I discussed previously.

According to my "level lineup", UFO sits near the top though not necessarily at the top.

So I guess my question really is: is UFO (as a format) willing to take on one additional responsibility, or at least participate in one extra responsibility: to "coordinate" the font creation path. Not to "control it", because that's something a tool chain and some scripts should be doing, but perhaps to "coordinate" as in "provide hints" or "guidance" to tools.

With more tools, there are more ways to go from UFO to final font files. Full parity will never be ensured, just like we'll never have 100% pixel-perfect compatibility of HTML and CSS as rendered by Firefox, Chrome, Safari, Opera and IE.

On the other hand, perhaps UFO is more like HTML (in that it defines the "content") while the analogy to CSS would be some "language" to define how UFO should be transformed to OTF/TTF. And perhaps at least parts of what I'm talking about belongs there.

There are, of course, languages in existence that define this. One of the most popular is "Makefile" used by the Unix "make" tool. But I'm still curious whether considering something akin to "!important" in UFO is worthwhile, especially for the potential conflict resolution between the various UFO-based tools.

Best,
Adam

[Dave Crossland]

On 6 December 2013 13:02, Adam Twardoch (List) <list...@twardoch.com> wrote:
> On the other hand, perhaps UFO is more like HTML (in that it defines the "content") while the analogy to CSS would be some "language" to define how UFO should be transformed to OTF/TTF. And perhaps at least parts of what I'm talking about belongs there.

Since UFO and TTX are XML, I wonder about using XSL to do this.

[Tal Leming]

A point of clarification: the UFO is *not* "very specifically tied to OpenType." The reason that there are a lot of openType* entries in the fontinfo.plist spec is because OpenType requires lots of little bits. There is postscript*, macintoshFOND* and woff* as well. Eventually there will be others. The quantity of key substrings should not be interpreted as any sort of preference...

Tal

[Tal Leming]

On Dec 6, 2013, at 11:19 AM, Adam Twardoch (List) <list...@twardoch.com> wrote:

> Currently, the timestamp of a file is one mechanism that is used to resolve these kinds of conflicts, even in a pure-UFO workflow (switching between RoboFont and Prepolator, for example). That's already a decent mechanism, especially if the info is itemized enough (which is true in case of UFO, at least to some extent).

I wrote the change detection code that you are referring, so I have a good understanding of what works and doesn’t. defcon does it’s change detection by looking at the time stamp, but time stamps can lead to false positives. For example, some applications redundantly write over GLIF even if there are no changes. So, that has to be filtered out of potential changes presented to the user for confirmation. To do this, when a file is loaded, the text of the file is cached inside of the object along with the loaded data. When the timestamp indicates that something may have changed, the raw text of the file is loaded and compared to the cached text. If there is a difference, the file is presented to the user as “changed.” (FWIW, this code is all open sourced. You can see it in my GitHub.)

That said, it is still not good enough. In reality, if one application orders the elements in GLIF differently, it could lead to a false positive since the cached data is the text, not a representation of the data in the text. So, in reality, the data needs to be interpreted and then cached. That leads me to...

> I'm raising the questions here not necessarily because I want the UFO spec extended somehow. I'm raising them more to get feedback from others on this list as to what they are doing and to make sure that we at FontLab are "doing the right thing". So thanks for your feedback so far.

I understand what you are trying to do. I have a tool that automatically generate glyphs (child glyphs) based on other glyphs (parent glyphs). Child glyphs usually stay in their automated state so that if I change one of the parent glyphs, the corresponding child glyphs are updated. If I decide that one of the child glyphs should not be updated, I can edit the glyph and the tool flags the glyph as manual instead of automatic. However, sometimes I modify the parent glyphs and child glyphs outside of the context of the tool that listens for the changes. The next time the tool is run, it needs to figure out what to do with these changes that it doesn’t know about. To do this it scans the automated glyphs and recompiles them (in memory, not in the glyph itself) and compares the new result with what is there now. If they don’t match, it is something for the user to decide.

Another way to handle this would be to store a fingerprint of the data that I am paying attention to in the appropriate glyph libs. For example, the lib entry for a parent glyph would say something like this:

- the bounds of the outline was (10, 30, 50, 100)
- there were no components
- the width was 123

In the child glyph, the lib entry would be:

- the bounds of the outline was (100, 310, 150, 200)
- there was a component referencing A with a transformation of (…)
- the width was 123

The procedure for evaluating changes would be similar to the one I described above.

So, short version: if a data A needs to know if data B changed, data A should contain a fingerprint of data B. The fingerprint needs to be maintained by the entity that cares about the data sync.


I have been thinking about your binary table example. Here is how I think you could resolve that with something like this (OS/2 table used as an example):

- the data for the OS/2 table is defined in the fontinfo.plist spec
- grab all of the openTypeOS2* keys defined there
- for each of those, in ascending alphabetical order, make a string representation of both the key and the value stored in fontInfo.plist. ignore any values that are not defined.
- combine these into a single string
- make a hash of the string
- store the data in the lib following this format:

com.fontlab.binaryTables.opentype.os2.<format version> = {
hash = the hash from above
data = …
}

When you need to evaluate if something has changed, you can create the hash from the data in the fontInfo.plist and compare to what you have stored with the binary data.

I know this doesn’t address the binary compilation issue that you described. There isn’t a good answer for that without a spec defining the UFO to binary process. That is out of the scope of the UFO spec in my opinion. (I mean, the OTF spec itself can’t agree on what a correct OTF is.) If someone wants to get together to define a procedure, that’s perfectly legal. Just put the data in org.ufotobinary.whatever.and.so.on. On a personal level, I think that could be useful, so let me know when the site is up! ;-)

I hope this helps.

Tal

[Tal Leming]

On Dec 6, 2013, at 1:02 PM, Adam Twardoch (List) <list...@twardoch.com> wrote:

> So I guess my question really is: is UFO (as a format) willing to take on one additional responsibility, or at least participate in one extra responsibility: to "coordinate" the font creation path. Not to "control it", because that's something a tool chain and some scripts should be doing, but perhaps to "coordinate" as in "provide hints" or "guidance" to tools.

Just to be clear: I don’t disagree with what you are proposing in concept. When I wrote ufo2fdk I had to read the specs and figure out what should go where and what should happen if and but and then and all of that. It was a lot of work and there were no definitive answers for some things. It would have been much easier if there had been a document that defined all of these things. I suppose that one could be extrapolated from ufo2fdk, vetted and used as a starting point...

I just don’t think this is part of the UFO spec. I don’t want that spec to start definitively giving answers for things that are at times quite subjective. Does that make sense?

I think it would be great if there was a document that describes what you are talking about. It could define how the name table is compiled. It could define the TTX storage locations, how they are to be handled, edge cases and all of that. And on and on. I would cheer on the development and support it any way that I could and I would certainly update ufo2fdk to match the spec.

I hope that makes my position more clear.

Tal

[mathieu...@gmail.com]

Hello Yuri,

I would also like to test vfb2ufo for Mac.

Thanks & best regards,

Mathieu Christe

[mathieu...@gmail.com]

Hey Juri,

I'd still like to test vfb2ufo for Mac.

Thanks & best,

Mathieu

On Sunday, 1 December 2013 16:06:22 UTC+1, Yuri Yarmola wrote:

[Jonathan Miller]

Yuri, 

I'd like to test vfb2ufo for Mac as well. 

-Jonathan

--

[Cosimo Lupo]

Hello Yuri,

I'd also be interested in testing vfb2ufo, both Win and Mac.

Thank you in advance.

All best,

Cosimo

[Joancarles Casasín]

I never heard anything back and didn't get anything.

Should I?

Thanks,

Joancarles

[mathieu...@gmail.com]

Hi all,

Let's expand the question, has anyone received anything?

On the 12th of December, Yuri contacted me directly by email, after my post here, saying: "We are preparing a new build (which hopefully will fix few problems in the original release) and hope to have it available any day now. I’ll let you know."

Since that day and despite one direct reminder and another post here, I haven't received anything either.

Hope or Nope? I'm off but thanks for asking Yuri.

With my best regards,

Mathieu

[Jonathan Miller]

I haven't heard back. Still hopeful!

-Jonathan

--

You received this message because you are subscribed to the Google Groups "Unified Font Object Specification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ufo-spec+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Yuri Yarmola]

Truth is that we've faced quite a few problems related to conversion between FL key-glyph based class kerning and UFO group kerning. We want to keep as much information as possible while keeping conversion process very fast. It took much more time than we expected.

But new build is ready, we're testing it internally and plan to release in few days.

Best regards,

Yuri

[Frank Grießhammer]

Yuri, 

That is quite interesting; but the UFO kerning model has been more flexible than what is possible in FontLab, .

I figure a predictably-perfect kerning conversion from UFO back to VFB would be much more difficult.

I hope you (all) know I have tackled this problem with a script some time ago:

https://github.com/adobe-type-tools/fontlab-scripts/blob/master/Kerning/ExportClassKerningToUFO.py

using this module:

https://github.com/adobe-type-tools/python-modules/blob/master/kernExport.py

At any rate, I am also interested in giving vfb2UFO a try.

Greetings,

Frank

--

[Yuri Yarmola]

Frank,

I agree that UFO kerning is more flexible. It is very similar what you can do with kerning groups and classes in Metrics Machine and FLS, but there is no guarantee that it can be compatible. 

Please note that we never promised to make UFO-2-VFB convertor, it is actually the opposite (tool name makes is very visible). We're trying to make UFO->VFB conversion as good as possible, but no promises are given. 

Personally I think that UFO does have future while VFB does not – we are turning to XML-based storage formats ourself, and we trying to make them as close to UFO as possible. We'll report on that soon.

Actually I'd like to try what we've done - it was not made by me, I am busy with some other stuff. There will be updates very soon.

Best regards,

Yuri

воскресенье, 9 марта 2014 г., 17:21:42 UTC+4 пользователь Frank Grießhammer написал:

[Frank Grießhammer]

Yuri,

Great news! I understand you are making a VFB → UFO, and not the other way around.

I was just pointing out the potential roundtrip difficulty.

The script I pointed out also only helps with exporting kerning from VFB to UFO, something that has often been a bit of a problem.

Cheers,

Frank

[Jéremie Hornus]

Hello Yuri,

I would be interested in testing vfb2ufo, mac and windows versions.

thank you,

Jeremie

[Adam Twardoch]

Hello colleagues, 

Fontlab Ltd. has just publicly released vfb2ufo for OS X and Windows, build 2014-12-10: 

http://blog.fontlab.com/font-utility/vfb2ufo/

(The above URL is the permanent home for vfb2ufo). 

The tool is available free of charge, it requires a free registration. 

Best,

Adam

[Behdad Esfahbod]

Thanks Adam, that's very nice!

> --
> You received this message because you are subscribed to the Google Groups
> "Unified Font Object Specification" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ufo-spec+u...@googlegroups.com

> <mailto:ufo-spec+u...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
behdad
http://behdad.org/