Yesterday at ATypI Sao Paulo, we premiered the FontLab VI Public Preview for Mac OS X. It’s still a pre-release in-development product, but now you can take a look at it and let us know your opinion. We're very much looking forward to it!
Adam Balance segment
Tunni lines for tension editing
Slide nodeRapid tool for speed drawingScissors tool to restore overlaps and open cornersFill tool for complex live pathfinding
This and tunni lines and mixed glyph/metrics window as in Glyphs but with Harfbuzz support is quite cool I would say.
However, I really hope the performance for high point glyphs will improve. Currently even my 'lower' creations are chugging my system down to unusable levels for a decent workflow. Anything around 1k-2k points (and editing glyphs with those counts) becomes quite a strain.
The reason I've been sticking with Fontlab V is that Robofont/Glyphs just haven't been able to deliver at the same standard of performance. If you have to draw/adjust thousands of points daily a latency of some milliseconds quickly becomes a strain on your work.
I guess this has some to do with all the implemented curve aids? (even though turning everything off doesn't give FL5 levels of performance) I've been working around FL5's dated UI and bezier-handling quirks through turning to glyphs for simpler projects, but I'd still like to streamline my workflow and bundle it all together.
I must add though, I'm an illustrator, less of a technician. I love optimising my beziers (hence I actually finalise illustrations in font software due to Illustrators imprecision) I know where the limits lie, however, if there are ways around this problem (and I'm just configuring my programs incorrect), I'm open to suggestions!
I'm still looking forward for the final release! I'm sure a V/VI symbiosis could work as well
the performance has to do with a combination of Retina, Qt and the layered compositing that is used by today's GUI toolkits. We've identified some sources of lags already and will be working on some solutions and also providing some optimization guides for users. Our developers assure me that we'll be able to increase the performance.
I've been playing around with the new gadgets in FLVI for the rest of the weekend and must say it works (and looks) really impressive!
Does FL6 open VFB files from FL5/etc?
Which of those formats does it also save to?
For native font editor formats, it saves VFB, UFO, and its own formats VFC and XFO.
VFC is the new binary format, while XFO is an extended UFO-XML variant that supports all our features.
Are there other formats you would like it to save to?
Glyphs. With .glyphs support FontLab VI will be a useful tool for me. Without .glyphs support FontLab VI will be useless.
I would be happy if XFO meant a spec-compliant UFOv3 with FL6 'private' lib data
VFC is a FontLab native binary format, and will be faster than anything else for file operations.
XFO is essentially a FontLab-extended UFO packaged in a Zip container. So it keeps all the FL data and there are performance advantages over naked/old UFO because of the reduction in file I/O. However, it will remain to be seen if other tools choose to adopt XFO support.
UFO requires that some FontLab-specific data is relegated to private places. If you pass it through other tools, in some cases data may be lost. Whether that data is important to you is another matter. Because each glyph is a separate file, there can be some performance issues, particularly when reading or writing fonts with large numbers of glyphs.
So, there are perfectly good reasons why FontLab has other format options for saving. But UFO is as much an equal player as we can make it.
Duly noted. We will consider enabling saving in .glyphs format.
Moving up and down kerning text files and moving horizontally along each line using only the keyboard should be made possible. Also, of course, assigning kerning values increments with different key combinations.
Is it too much asking for the next Fontlab VI?
Indeed, one of the 40 or so bugs fixed in the FontLab Studio 5.1.5 / 5.2.2 dot releases is one to do with tabbing and arrowing between fields during keyboard-controlled kerning—which I reported myself. So it's fair to say that I am especially sympathetic to that particular request.
That said, like the rest of the team, I am sympathetic to all kinds of reasonable requests, whether they match my workflow or not. One of the historic strengths of FontLab apps is not locking you into a single style of working, but enabling multiple approaches that users like.
That philosophy is not changing in FontLab VI.