You can't do a direct full conversion, but you can convert aspects of FL hinting to VTT compatible format. But you have to roll your own: there is no publicly available solution, to my knowledge.
This is what we did: we hired a Python programmer to write scripts that run from within FontLab that write out FL hinting in a format that is recognisable by VTT. I wasn't closely involved with this, so I can't give much in the way of detail. Our goal was to reduce the manual workload in VTT by automating the actual stem hints, while leaving the resulting VTT source in a state that enabled flexibility in subsequent editing. The scripts can take a variety of input from within FL, including PS stem hints, so we can leverage the Adobe PS autohinter.
Basically, what you need is someone who can program and who can analyse the data structures for FL and VTT hinting and figure out how to map from one to the other.
There are some incompatibilities between FL's internal representation of hints and what VTT does, so for example 'DoubleLinks' need to be translated into something that VTT will recognise before we do the export. And there is a lot one can do in VTT that simply isn't expressible in FL terms. So while you can translate from FL to VTT and probably at least some data from VTT to FL, you can't do lossless round-tripping.
On the VTT side, there are multiple ways of representing hinting (visual, VTT Talk, raw instruction code), not all of which are perfectly able to express each other, e.g. there are some things you can only do in the raw code. If I recall correctly, our FL-to-VTT tools write VTT Talk.
To be honest, I don't know exactly how our FL-to-VTT process works, since I didn't spec the scripts and I'm not the person who uses them. I'm also not sure how much detail Ross is comfortable sharing: I just wanted to confirm for Frode that it is possible and give some indication of what is necessary in order to do it.
Tom Phinney mentioned to me that he's aware of four independent FL-to-VTT workflows, including ours, and I suspect they all differ in various ways: there are quite a lot of options in terms of how it can be done, and some of the decisions will reflect hinting strategies, i.e. what you want to be able to do in VTT with the imported data and how you like it arranged. For example, do you want to try to write CVTs based on the FL hinting, or do you want to map to existing CVTs in a VTT source, or do you want this to be an option?
That's fine, I was just curious. If I would plan something like that, I'd probably go for the extra font tables. At a glance, their format seems easy enough to figure out.
Jens, I agree. The VTT private table structure is fairly straightforward, so writing those directly makes sense (and is likely what our tools do, although I note an export option to write to a log also). I'm aware of some other VTT table munging tools that colleagues have developed over the years, e.g. to modify the glyph order of a font that contains VTT tables without mucking up the hint sources.
Frode, we in this case is Ross Mills and me, i.e. Tiro Typeworks. Ross does all our VTT hinting work -- which is why I'm a bit vague about some of the details of our FL-to-VTT workflow --; we hired a Python programmer to analyse the data structures with Ross and write the export scripts for us.
12 Sep 2011 — 9:33pm
You can't do a direct full conversion, but you can convert aspects of FL hinting to VTT compatible format. But you have to roll your own: there is no publicly available solution, to my knowledge.
13 Sep 2011 — 2:05am
How?
15 Sep 2011 — 11:25am
The silence is deafening, isn't it?
15 Sep 2011 — 2:00pm
Not so wierd actually. Iceland is the only Typophile that matters right now.
15 Sep 2011 — 3:09pm
Sorry for delayed response.
This is what we did: we hired a Python programmer to write scripts that run from within FontLab that write out FL hinting in a format that is recognisable by VTT. I wasn't closely involved with this, so I can't give much in the way of detail. Our goal was to reduce the manual workload in VTT by automating the actual stem hints, while leaving the resulting VTT source in a state that enabled flexibility in subsequent editing. The scripts can take a variety of input from within FL, including PS stem hints, so we can leverage the Adobe PS autohinter.
Basically, what you need is someone who can program and who can analyse the data structures for FL and VTT hinting and figure out how to map from one to the other.
19 Sep 2011 — 10:27pm
Oy Vey.
21 Sep 2011 — 1:02pm
Sounds promising. Can the format that is recognizable by VTT, be writable into an open format? Or writable back to FL 'ints?
21 Sep 2011 — 4:14pm
There are some incompatibilities between FL's internal representation of hints and what VTT does, so for example 'DoubleLinks' need to be translated into something that VTT will recognise before we do the export. And there is a lot one can do in VTT that simply isn't expressible in FL terms. So while you can translate from FL to VTT and probably at least some data from VTT to FL, you can't do lossless round-tripping.
On the VTT side, there are multiple ways of representing hinting (visual, VTT Talk, raw instruction code), not all of which are perfectly able to express each other, e.g. there are some things you can only do in the raw code. If I recall correctly, our FL-to-VTT tools write VTT Talk.
22 Sep 2011 — 6:16am
How do you import the VTT Talk code into VTT? I guess copy&paste for each glyph is not an option ;)
Or are you writing the VTT-specific tables (TSI*) directly into the TTF?
22 Sep 2011 — 9:00am
To be honest, I don't know exactly how our FL-to-VTT process works, since I didn't spec the scripts and I'm not the person who uses them. I'm also not sure how much detail Ross is comfortable sharing: I just wanted to confirm for Frode that it is possible and give some indication of what is necessary in order to do it.
Tom Phinney mentioned to me that he's aware of four independent FL-to-VTT workflows, including ours, and I suspect they all differ in various ways: there are quite a lot of options in terms of how it can be done, and some of the decisions will reflect hinting strategies, i.e. what you want to be able to do in VTT with the imported data and how you like it arranged. For example, do you want to try to write CVTs based on the FL hinting, or do you want to map to existing CVTs in a VTT source, or do you want this to be an option?
22 Sep 2011 — 10:53am
That's fine, I was just curious. If I would plan something like that, I'd probably go for the extra font tables. At a glance, their format seems easy enough to figure out.
22 Sep 2011 — 11:10am
Thanks John. Just out of curiosity, who are “we”? You can PM if necessary.
22 Sep 2011 — 12:26pm
Jens, I agree. The VTT private table structure is fairly straightforward, so writing those directly makes sense (and is likely what our tools do, although I note an export option to write to a log also). I'm aware of some other VTT table munging tools that colleagues have developed over the years, e.g. to modify the glyph order of a font that contains VTT tables without mucking up the hint sources.
Frode, we in this case is Ross Mills and me, i.e. Tiro Typeworks. Ross does all our VTT hinting work -- which is why I'm a bit vague about some of the details of our FL-to-VTT workflow --; we hired a Python programmer to analyse the data structures with Ross and write the export scripts for us.