http://en.wikipedia.org/wiki/Duke_Nukem_Forever

I'd like to hear how the features are different, technically speaking as I agree FL's bold feature seems like it could be better.

FLS6 will most likely include both the FontLab and the FOG "bold" algorithms. We resumed work on FLS6 after the release of FOG5, and we're in the pre-alpha status now. Our intent is to have FontLab Studio 6 for Windows available by the end of this calendar year, and the Mac version 3-4 months later.

These are early projections but we're on a steady development track right now.

Good news :)

Cant wait! :)

bump, 3 months later: any news on fontlab 6?

bump, 3 months later: any news on fontlab 6?

No soup for you!

> No soup for you!

No vodka for you. :)

Adam's original estimate . . .

Our intent is to have FontLab Studio 6 for Windows available by the end of this calendar year

It's not even time to begin making excuses yet.

However, there is enough wit on this forum the help the FL people out, if you want to start helping them with excuses early . . .

In Russia the homework eat the dog?

To quote the aforementioned Duke Nukem: “What are you waiting for..? Christmas?!”

Great news: FontLab 6 will finally be out in a matter of hours!

Our intent is to have FontLab Studio 6 for Windows available by the end of this calendar year, and the Mac version 3-4 months later.
These are early projections but we're on a steady development track right now.
–Adam
–July 29, 2010 (see above)

Happy New Year!
(And you all were expecting another Duke Nukem?!)

If I were a cynical person, I'd say FontLab is spending their capital eliminating competition by hiring people who are developing alternative products.

Good thing I'm not a cynical person. I can't wait to be able to use FL to work on fonts with AFDKO 2.5 for features.

So, how many hours left for the release announcement?

If I were a cynical person, I'd say FontLab is spending their capital eliminating competition by hiring people who are developing alternative products.

IIRC Fontlab was providing some of the funding for Glyphs from the start.

Dunwich Type: No, we've provided some funding for RoboFab development, but not for Glyphs.

Charles: It's not like that. Georg approached us quite some time ago, giving us suggestions for further development of our product. He started developing Glyphs as a proof of concept that his ideas had merit. We've been in informal contact for a few years, and a few months ago (at the ATypI Dublin conference, in fact), we've come to a mutual agreement that it's best for both sides if Georg is working for us, and helps us improve the products. By the way, the story is quite similar to how I came to work for FontLab. I've corresponded with the developers for a few years and shared my ideas with them, and at some point they decided to invite me to their team. There is certainly no conspiracy behind all this :)

The past few months of development also showed us that we need to rewrite some major parts of our 13-years-old code from scratch. Some limitations of it (such as the integer coordinates, limitation to +-32,000 in coordinate space, hardwired Multiple Master support) limited us largely as for what we could do. But the biggest problem was indeed, the rooting of the Mac version in Mac OS 9, Carbon, and PowerPC. Moving the old code to XCode and Intel turned out to be a huge task and lots of wasted energy. So we concentrated on rewriting the core from scratch, eliminating lots of silly stuff from the past, improving the speed and stability a lot. A huge part of it is already done, but we were not able to finalize the application by the end of the last calendar year.

I realize that it's disappointing for many of our customers, but please be assured that we *are* working at our full capacity on the project. It's just a hugely complex application and we do have very limited resources (in short: we're a small company).

I'll keep you posted on new developments, of course.

Best regards,
Adam

So is Glyphs still going to be a standalone app or will it be folded into future versions of Fontlab and/or Fontographer?

But the biggest problem was indeed, the rooting of the Mac version in Mac OS 9, Carbon, and PowerPC. Moving the old code to XCode and Intel turned out to be a huge task and lots of wasted energy. So we concentrated on rewriting the core from scratch, eliminating lots of silly stuff from the past, improving the speed and stability a lot.

So is Fontlab 6 still going to be a more stable and up-to-date overhaul of 5 with Fontlab 7 being a totally new app? Also, are you still planning to do a Windows version first followed by a later Mac release?

Because of the speed of the rewrite, FontLab Studio 6 will be a larger rewrite than originally expected, taking our experience of working on both the old FontLab and the old Fontographer codebase, and of Georg's experience of working on Glyphs.

We have not acquired Glyphs. We have hired Georg Seifert. He does plan to develop Glyphs in his spare time.

Charles: I can’t wait to be able to use FL to work on fonts with AFDKO 2.5 for features.
 
If you really can’t wait for applying the AFDKO 2.5, you could generate your OT fonts without features using FLS, build a features file that contains all you can think of, like this one (I will revise and enhance the file shortly), and use DTL OTMaster, which is available from FontLab Ltd, to generate (and check and [if applicable] edit) the tables.
 
Adam: [...] we need to rewrite some major parts of our 13-years-old code from scratch
 
After releasing DTL FontMaster in 2002 we were in a pickle, because the MFC compiler was not updated to support Mac OS X. So, everything had to be newly coded at URW++ in Qt (if I recall correctly what Yuri told me in Dublin, FL Ltd has switched to Qt too).
All our recent applications, from OTM to LeMo have been made using Qt, and sooner or later we will have a new font editor also.
 
(At the moment I am thinking of an iOS version of [the new edition of] LeMo [which will be for free again, of course].)
 
FEB

Thanks for the details, Adam. I am looking forward to seeing what the formidable combination of the Fontlab team and Georg produce together!

A couple of functional requests:

Could you make the kerning (class information) in the metrics window work properly like it used to in 5.0 - ie. 'referenced in class' or 'key glyph in class' when the little box is clicked under the glyph. At present it says 'cancel' or 'remove this place point'.

It would be great if there was an option to name stylistic sets rather than just 'set 1' set 2' etc.

Thanks.

Nick: Could you make the kerning (class information) in the metrics window work properly like it used to in 5.0 - ie. 'referenced in class' or 'key glyph in class' when the little box is clicked under the glyph. At present it says 'cancel' or 'remove this place point'.

It seems your CurrentWorkspace.rc file was corrupted.

Johnych

One year later, still waiting patiently ... I bet I'm not the only FontLab-using type designer who would love any morsel of information on the development.

love any morsel of information

Certainly. It will be out before the ending of the world. Maybe.

That only leaves a few months!

hhp

Dear all,

About a year ago, I wrote: "the biggest problem was indeed, the rooting of the Mac version in Mac OS 9, Carbon, and PowerPC. Moving the old code to XCode and Intel turned out to be a huge task and lots of wasted energy. So we concentrated on rewriting the core from scratch, eliminating lots of silly stuff from the past, improving the speed and stability a lot."

As you can see now -- primarily because of Apple's decision to drop PPC support from Mac OS X 10.7 Lion -- we had to change things once again.

As it was obvious that the complete rewrite would not be ready before Lion is released, we decided to do what we had dreaded to do for so long. In the last 15 months or so, we did indeed port the Metroworks/PowerPC-based Mac code to XCode/Intel-based Mac code and upgraded all text controls to Unicode (so typing Cyrillic or Greek characters is possible directly in the Preview panel or the Metrics Window's text box), upgraded the Python integration. Especially the first step was a truly major operation -- about 24 man-months of full-time work!

As I said, the lack of compatibility and support of the older development platforms on the Apple side was the primary reason why the FontLab Studio for Mac development was on hold in 2007-2010.

Moving from PPC to Intel in our case was really a great challenge, but fortunately, it's done now. And -- hell! -- we decided to swallow the cost of those 24 man-months ourselves and released FLS 5.1 as a free update for all 5.0 users. While FLS 5.1.1 is not yet perfect, it's MUCH more than just a simple update to 5.0.4. Really a lot was changed to make FLS 5.1.1 run 2.5 times faster than 5.0.4. But most of those changes were done "under the hood".

Anyhow -- the work of the last 15 months has laid a good foundation for FontLab Studio 6 development on the Mac. And after all, in FLS 5.1.1, we have also included some features that were originally planned for FontLab Studio 6: we have integrated Adobe FDK for OpenType version 2.5 and the native Microsoft rasterizers for TrueType hinting preview, included the Clean Up Paths algorithm from Fontographer (in FLS 5.1's Actions panel) as an alternative to Optimize, and done some additional improvements under the hood.

We realize that for some users it's not much, but that's primarily because we never really planned to release FLS 5.1. All this work was supposed to go into FLS 6.0, along with "real new features" but because of Lion, we needed to shift things around, give all priority to the necessary architectural changes first (so that 5.1 could be released), and do the nice creative things later.

There are more features that we're working on, and also more bugfixes. Some are already "ready" i.e. implemented in a development build for Windows, and currently we are merging the changes that two teams had done independently (the Windows team and the Mac team). Others have been developed while we worked on Fontographer 5.0 and 5.1 (a huge lot, actually), and we're now able to "move" them into FontLab Studio. We are also prioritizing the features that still need to be developed, and working on their implementation.

I'd like to add that for years, FontLab and later FontLab Studio were developed by just two people (one on Mac, one on Windows). We now have a team of seven people working on FontLab Studio 6, and they're making good progress.

We also have a separate team working on a complete rewrite of the code, but that project -- while it's hugely exciting and, dare I say, quite revolutionary -- will still take time to gain shape.

Overall, I can say that in the last 12 months, I've seen the most intense development progress at Fontlab Ltd. since I joined the company in 2004.

So basically, the bottom line is: FontLab Studio 6 will be built on the mature, solid foundation of the current FLS 5.1 codebase. It won't be a revolution, but will be an evolution. It's being worked on as we speak. It will suffer from some limitations of the FLS 5.x codebase (e.g. integer coordinates only), and will not include a huge number of revolutionary changes, but our goal is: some good new features and a lot of stability improvements. I still cannot give you any specific times at this point simply because -- as I said -- we're currently doing the major improvement in the code, and it's difficult to estimate when we'll have something which will be ready-to-ship. But we'll start seeding pre-release versions to groups of testers within the next few months.

At the same time, we're working on a product that will be a completely new thing. From what I've seen: if FontLab Studio 5 was PageMaker 6, then FontLab Studio 6 will be PageMaker 7, and "the completely new thing" will be InDesign.

You'll be hearing from us. Before the end of the world, I'm sure of it!

Happy 2012 for you all!

Best,
Adam

> typing Cyrillic or Greek characters is possible directly
> in the Preview panel or the Metrics Window's text box

I need that on the Windows version, please!!
(You can tell I'm serious because I just used two exclamation marks.)
Timeframe?

hhp

Hrant,

I think from reading this thread, you should realize that whenever I announce any timeframes, people end up laughing at me some time later.

I could give you my *goal* though: my goal is to have FontLab Studio 6 released in 2012 for both Mac OS X and Windows. I really cannot be more specific. But early development pre-release versions should be available within the next 2-3 months or so. We'll post an announcement inviting people to a closed pre-release program as soon as those are available.

We're back to work on our "flagship product". Not on Photofont, not on BitFonter, not on Fontographer etc., but on FontLab Studio.

Best,
Adam

> my goal is to have FontLab Studio 6 released
> in 2012 for both Mac OS X and Windows.

That's good enough for me.
I don't know why people make fun of somebody who's in the same boat.

hhp

Forget the effing master of marketing, always wear black, mac. Real people use Windows.

& please, please don't compare the new FL6 to InDesign. We've reported bugs with CS2 that are still there. CS5.5 has added a couple that stopped us dead with file comparison, always needed with multiple proof stages using InDesign. Let's hope FL6 is far better! (or at least cleaner...)

(I'll allow I'm known as the curmudgeon on another forum ;-) )

I must say that after the beta process, FLS 5.1 on the Mac gives me much more stability. There are much fewer ugly crashes but still some abnormalities in the interface between Mac and FontLab. Best wishes for a stable, trustworthy, reliable FLS6.

Thank you for a very thorough answer, and the best of luck with what's left of the development. Good to hear the FontLab team is taking this as seriously as you obviously do. For now, FontLab 5.0.4 is still working fine on my Windows 7 system, but boy! am I looking forward to a major update. Using FL5 now does indeed feel a bit like how using PageMaker while waiting for InDesign must have felt (while knowing that QuarkXPress is available).

Charles,

InDesign has gone a long way now, but the point is the comparison between PageMaker and InDesign. InDesign did bring native PDF support, full vector-based drawing, Unicode, OpenType, plug-in extensibility and an overall "modern" approach to page layout. PageMaker was an old product, based on a very old core.

I'm not trying to compare the future FontLab product to InDesign directly :) I'm trying to make the parallel that the difference between FontLab Studio as you know it now (and which version *6* will still be based on) and the future product (let's call it FLS 7 for now) will be just as serious as the difference between PageMaker and InDesign (which both came from the former Aldus and later Adobe development).

Just as Aldus and later Adobe kept on developing PageMaker while having started a completely new product (InDesign) from scratch, we are working on a similar cycle. We're adding features, maturity and stability to FLS 5.x to make FLS 6. It won't be a revolution but will be an evolution -- of a product which is now (in total) some 15 years old.

At the same time, we're reinventing the font editor completely, from scratch, based on a very modern and flexible architecture.

The bottom line is: we're working hard, and we're fortunate to have the largest team of developers that we've ever had, and they're some some very fine people! :) I'm excited.

Best,
Adam

Charles,

> "Forget the effing master of marketing, always wear black, mac. Real people use Windows."

Unlike any other company that offers font editing tools, we've always developed for both Mac OS X and Windows. This is on one hand a bit of complication (since the development takes longer and the applications may not look and feel so completely slick and fancy as some competing products), on the other hand it allows more users to run the tools.

Macs are somewhat popular in Western Europe and the U.S., but in the rest of the world, they're hardly relevant. We want to make products that allow people to make fonts not just for the Western languages, but also for all the other scripts that exist in the world.

So we have, and will continue to release products for both Mac OS X and Windows.

Best,
Adam

Macs are somewhat popular in Western Europe and the U.S., but in the rest of the world, they're hardly relevant.

Ah. Perhaps that's why my business partner, ethnic Chinese, born & raised in Sabah, educated in Scotland and the U.S., dislikes Macs...

For me, the old Altsys Fontographer, even though developed for the Mac, use to crash on the hour when used on a Mac. It was sort of intuitive. Every time you think "I'd better save now," the program would beat you to it and crash.

But it seemed bulletproof on a P.C. And TeX ran better on a P.C. ...

Please not another Mac/PC flame war? Can't we just keep the subject FLS-6?

Fontographer never crashed on me. But maybe that's
because I used to run it with a Mac emulator on my
Amiga-500... sans hard drive. :-)

hhp

.

Will FL6 be compatible for x64 OS?

Tourdeforce,

FontLab Studio 6 for Mac OS X and for Windows will be a 32-bit Intel application. Just as the current versions of FontLab Studio (5.1 on Mac OS X and 5.0.4 on Windows), FLS6 will work fine on 64-bit operating systems.

As far as I can tell, the primary advantage of compiling applications as native 64-bit Intel is the ability to address more than 4 GB of RAM. Are there other reasons why you'd need a native 64-bit version?

Speed is another advantage. But in the case of font production you really
have to be running large batches of automatic processes for it to matter.

hhp

I, for one, am very glad Fontlab is available for Windows and Mac. It seems that all newer apps are mac only. As a user of both (my desktop is running windows 7 and my laptop is a macbook air), it's great that Fontlab works on both and I appreciate your efforts to keep this a main goal of the app.

Adam.. If you are already working on FL7, why waste your time and energy on FL6?

Can I make a humble suggestion?
Just release and update to the new FL5.1 including native UFO support and call it a day.
Skip FL6 altogether, and focus all your resources on FL7.

@ Adam

That's the only reason why I'm asking (RAM). Thanks.

Pablo,

> If you are already working on FL7, why waste your time and energy on FL6?

As I explained it earlier, it's kind of similar of Aldus and later Adobe working concurrently on PageMaker and InDesign.

Developing an application from scratch takes a long time. FontLab Studio as we know it today is a very feature-rich application with an established user interface and usage patters by the users. Many people are used to it, they're very proficient in the tool but have been asking for more than just UFO. In our minds, we quite well know what FontLab Studio 6 will be like, and we're essentially implementing what already has been planned. We'll "call it a day" once we've given our devoted users *what they want*.

What I'm referring to as "FontLab Studio 7" is a different matter. It may well break with many of the old habits and make users introduce new ones. We're working on it, but it's nowhere near completion. Some parts of its functionality haven't been even started, while others are already quite well-implemented. It's certain, however, that users will need to re-learn. Some people may perhaps hate it in the end. It's very likely that the product won't be called "FontLab Studio 7" at all (again, as with PageMaker, where InDesign 1.0 and PageMaker 6.5 and later InDesign 2.0 and PageMaker 7.0 were different products).

It will take quite some time for the new product to cover all kinds of functionalities that people will need. For some years to come, FontLab Studio (5.x now and 6.0 later this year) will be the *only* product on the market which will offer that particular functionality. In other words, FontLab Studio as we know it now is now a mature product, like a person in their 40s. The fully new product is in its early teen years. At some point, it'll be in its early 20s but will still not be free of faults. There will be people who'll jump onto the new kid on the block but there will be others who'll prefer to stick with the old product.

You can also see it this way: FontLab Studio as we know it now is so extensive that -- when it comes to the "wealth" of features -- it practically has no match on the market. But there is Glyphs and RoboFont, which are more sophisticated and smoother as a design tool, while on the other hand they don't offer (and probably never will) offer certain other aspects -- like for example manual TrueType hinting.

The new product will initially be more in the same realm as Glyphs or RoboFab, I suppose. Only with time, it (or perhaps a separate tool) may also cover other parts which are currently unique to FLS.

With UFO, fortunately, we can have interoperability between all these products.

With any product, there is a certain development cycle. You have it with fonts as well:

Imagine FontLab Studio 6 as a typeface which already had earlier versions released, but you're now adding Greek and some OpenType glyphs. It already has 90% of the intended character set, which is kerned and hinted, but now you're working on some additional glyphs, reviewing existing spacing, kerning and hinting, fixing some problems with them, and writing some additional code for OpenType Layout features.

Then imagine our new product (which I referred to as "FLS7" but this may very well change) as a typeface where you have most of the basic alphabet and quite a few special glyphs already drawn, but you still are deciding on the shape of the serifs, and maybe you'll redraw some of the glyphs completely, and perhaps you'll re-space it fully once again, and there are no composite glyphs or math glyphs or any kerning or hinting done yet.

You certainly wouldn't say "just drop the first one completely and focus all your energy on the second one", would you?

Best,
Adam

tourdeforce,

font development isn't particularly RAM-hungry. The 4 GB limit is far more than enough. Native 64-bit is mostly needed for large images or video editing where you're really dealing with huge amounts of data. Yet developing a native 64-bit version is costly, because you can't just switch to it -- you still need a 32-bit version of code. We're already making a Mac and a Windows version, and adding the 32+64 bit pair to each those would mean double the binaries. Then, there's the PPC + Intel on the Mac etc. When developing applications, they need to be tested in a variety of environments. We already have several versions of Windows and Mac OS X on which we need to test.

Let's say we release the Windows version of the app only as 32-bit native. Then we need to test that code on Windows 7 32-bit and Windows 7 64-bit.

But if we release the Windows version of the app as both 32-bit and 64-bit, we'd need to test the 32-bit code on Windows 7 32-bit and Windows 7 64-bit, and the 64-bit code on Windows 7 64-bit. And then also comes Windows XP and Vista, and the Mac OS X versions etc.

So it'd just add more combinations that would need to be thoroughly tested, which would only delay the release of the products even further. So we think it's not worth the effort.

I hope you understand the above reasoning.

Best,
Adam

Adam,

is there any possibility to have a 5.1 version for Windows addressing the 6,000 glyph limit? FLS runs very smoothly for me (in a Vista 64-bit, using the XP compatibility mode) but the glyph limit does not let me to work with the whole font project.

Although FLS hardly consumes many resources, I found a situation where it becomes almost frozen. When working with _xxx anchors which are referred by hundreds of base letter with xxx anchors, the program takes several seconds to do any operation – even to open the glyph window.

With the help of fellow typophiller Eigi, I did a workaround to edit combining diacritics: changed the _xxx anchors to _zzz with a Python script. To build compositions, just change the anchors back to _xxx. Anyway, this is a rare issue where FLS really stresses the computer resources (but just with glyphs where there is a _xxx anchor, all remaining operations keep normal).

@ Adam

Yes, I understand everything what you're saying and it's not so easy as it seems, as you already explained. It's like when webdesigner make tests on every browser, going down to IE6, cause market dictates some rules.

My question was mostly related to those who will/would, in some moment, have to use Windows (Vista/7) 64-bit as their environment. For example, on this computer, I have 8GB (Vista 64-bit) and on another 16GB with Win7 64-bit. Cause I think people will start moving to 64-bit OS slowly since trends on IT market are moving forward to it, like it or not, and in some moment, most of designers (graphic/web/typo..) would have to switch to 64-bit cause of RAM on first place. Simply said - when you're buying a new configuration those days (for general design usage), somehow 4GB became standard RAM in offer.

I'm just afraid, it might happened, for example, that in some moment, after 1-2 years of releasing FLS6 doesn't become an "problematic" software for OS and reverse. So it doesn't become already old version cause of IT trends we're talking about.

It looks like there’s something wrong with the rasterizer, Adam.

Tourdeforce: Maybe I don't understand what the problem is, but the current FontLab Studio runs on 64 bit Windows 7 just fine.

@ Jens

Then that's good to hear. Didn't had a chance to try it in any Windows 64 bit OS yet.

There was no problem at all, I just thought that FLS6 could have some issues with 64 bit OS and wanted to ask Adam if they were thinking about it in advance. That's all. Cause (theoretically) if something is not made to be used in another environment, then there might be a chance that something goes wrong. But it's cool to know that FLS 5.x works fine.

Tourdeforce,

Most applications made for Windows are 32-bit. Also many Mac OS X applications are 32-bit (although the OS is natively 64 bit since 10.6). For example, Google Chrome, Mozilla Firefox, Skype, Adobe InDesign CS5, Adobe Illustrator CS5 and many many others. They all work fine on a 64-bit system. As far as I could tell, FontLab Studio 5.1 (Mac) and 5.0.4 (Win) work well there as well.

The only slight complication is when you heavily use Python and C-compiled modules. Some C-compiled modules made for Python may be 64-bit only (though it's still a rarity). Or at the very least you need to be aware of that -- so for example, on Windows 7 64-bit, you need to install the 32-bit version of Python 2.4 rather than the 64-bit version.

Best,
Adam

Frank,

Which OS is this? Which FLS? Which rasterizer is selected?

Mac, Lion, FLS 5.1.1, MS Greyscale rasterizer. And while you’re talking: why didn’t you include the Cleartype rasterizer? Who but me hints for Standard GDI anymore?

Frank,

integrating ClearType requires more development work. Given the pressure (release of Mac OS X 10.7 Lion), we decided to postpone that to FontLab Studio 6.

Best,
Adam

Adam said:

> Many people are used to it, they're very proficient in the tool but have been asking for more than just UFO.
> The new product will initially be more in the same realm as Glyphs or RoboFab, I suppose. Only with time, it (or perhaps a separate tool) may also cover other parts which are currently unique to FLS. ¶ With UFO, fortunately, we can have interoperability between all these products.

Adam, I don’t know if it’s a good idea to ask this at this moment, but I am trying to figure out if UFO native support is planned for FLS6 or if it will be available only for “FLS7”.

Clearly, ufo support must be part of FLS-6. Interoperability between all players in the industry is a must.

I assume this would also affect the way FLS deals with tables. Mostly, the way class key glyphs are notated. Instead of requiring the foot marker as an indicator, why not just the first glyph in the list in the class?

Cristobal,

as per Tal's recommendation, we definitely want to have UFO2 support in FontLab Studio 6. "FLS7" will likely support both UFO2 and UFO3.

Best,
Adam

Adam,

Why is it a limitation for FontLab to support only integer coordinates? Is there any font format that supports non-integer coordinates? And if not, why should a font editor do?

Adam,

Why is it a limitation for FontLab to support only integer coordinates? Is there any font format that supports non-integer coordinates? And if not, why should a font editor do?

Adam,

Why is it a limitation for FontLab to support only integer coordinates? Is there any font format that supports non-integer coordinates? And if not, why should a font editor do?

As many Fontographer old-timers will tell you, using fractional
coordinates will only cause trouble. It gives you an illusion of
accuracy while destroying actual accuracy. Just increase the EM.

hhp

Ori,

theoretically, OpenType PS (.otf) supports fractional coordinates, but there are some technical caveats associated with it. In principle, we could say that the final font formats only support integer coordinates but during the work process, having fractional coordinates would be helpful.

For example, if you have drawn your glyphs on an integer grid, but then you'd like to make some adjustments such as: make it slightly more narrow, then slightly wider, then perhaps slant it by a few degrees and then slant it back, or make some tiny rotations, or maybe scale the glyph down and then up again -- on an integer grid, the result will have accumulated the rounding errors from every one of these operations. On a fractional grid, all your shapes (the positions of the BCPs, the angles, the stem thicknesses etc.) will always remain just as in the original design.

Therefore, a hardwired integer grid such as the one in FontLab Studio does impose a certain limitation onto the type designer. A fractional grid such as the one in Fontographer allows you to avoid those rounding errors. But of course, at the very end, when you decide to generate or ship the font, you'll need to align your points to an integer grid, or the software will do this for you.

Hopefully that helps to answer your question!

Best,
Adam

Thanks, Adam, you make a very good point.

(Sorry I've posted my previous comment three times, I didn't realize I was doing that.)

Are there any news about FL 6? It is gonna be released in the next 3 or 6 years?

I don't think ridicule is going to speed things up.

hhp

Any news about FL 6?

Thank you

Not to make light of the indefinite delays, but I thought this was both comical and cogent:
http://fuckyeahtypefacedesign.tumblr.com/post/61863698353/its-not-the-to...

hhp

Hrant, its gone!

Dave, I guess the owner of FYTD is in bed with some/all of the SuperRoboGlyphsPolator people and/or Dunwich Type. Cronyism - yay!

BTW since then there's been another moral failing:
http://fuckyeahtypefacedesign.tumblr.com/post/67465965024/i-put-so-much-...
It turns out James Raftopoulos –the winner of the competition– submitted no such thing. Libel - yay!

After all, what use is ethical behavior if it obstructs a cheap laugh, right?

--

And what Jan said.

hhp

I have given up waiting, and now use RoboFont on a Mac. I really, really, really wanted to go on using an updated FontLab (and by no means am I an Apple fan boy), but I also need un-rusty, modern tools. (I guess FontLab 6 now will be released in a month or so, given my usual luck.)

It is so very sad that two of the things I really loved the most about type and type drawing, FontLab and Typophile, are both dying (or so it seems).

Sindre,
I hope you are finding other things to fill the void you feel.

Yes, I've taken to the bottle.

Then, Salud! or perhaps Skaal?

Sindre, I think Typophile has picked up. FontLab: I remain hopeful; the fact that they're still sponsoring conferences is a good sign.

hhp

Skål! (There is only Darjeeling in my cup, but it does have a noticeable muscatel flavour, so I can pretend it is a Sauternes or something.)

I wonder if type designers at large have abandoned FontLab now for lack of updates, by the way.

I remain hopeful too, Hrant, and will definitely upgrade if/when it comes out. A UFO-supporting FL6 could easily be integrated into a RoboFont-based workflow, as I really want the best from both worlds. I am so used to the very good drawing tools of FontLab that I still prefer them.

FontLab has been re-architecting themselves on a new codebase. TransType 4 is the first app to come out using the new codebase. I imagine we will hear more soon.

soon?

What I like most about TransType 4 is not just the speed, but the really first-rate UI. :)

I've been doing a little work for the FontLab folks, but I can’t reveal product plans. I will just say that I have reviewed a lot of specs.

Good news, Thomas.

hhp

Every time I see Adam, which is usually at least once a year, I ask for a progress report. The good news is that there is always progress, and some of it is very cool. The bad news, from my perspective, is that updating to FontLab 6 might require as much of a re-investment in Python scripting as switching to RoboFont or Glyphs.

This is mostly guesswork, but I think FontLab are a little wrong-footed by the recent advent of competition in the primary glyph tool category from RoboFont and Glyphs, just as they were previously wrong-footed by the initial poor implementation of the Mac version of FontLab Studio, which contributed to the development of that competition. It took a lot of effort from what I understand to be a reduced team to remake a stable version of FLS for Mac, and that is part of the reason why 'Victoria' -- the new code architecture for FontLab 6 -- has been delayed. Remember, FontLab has always been primarily a Windows tool and only secondarily ported to Mac. I was reflecting recently that it was about 20 years ago that I saw an ad in a desktop publishing magazine and bought my first license for FontLab 2.5. It was good, and successive (Windows) versions of FontLab have remained good. Current trends favour more openly scriptable object structures, which is a good thing, but it terms of core functionality FLS remains better than any other tool I have tried, and even with its current scripting model fits nicely into my sfnt-centric workflow. I also remain impressed by the size and performance of the VFB source format, even for large fonts of the kinds I regularly build, compared to UFO, which contains less information in much larger files and takes ages to load even in dedicated UFO tools. While I can understand why people are keen for a version of FontLab that natively handles UFO files, I'd like to see the VFB format open-sourced and supported in UFO tools.

"...a little wrong-footed..."

A kind of Hobbit. But if you call them that, they shout, "We're Little Wrong-Feets!"

Current trends favour more openly scriptable object structures, but only if extendable. Is that VFB or sfnt?

Time management concerned with figurative "ages to load", while waiting literally "years to do", seem reasonable?

I do not notice any difference in loading time between UFO and VFB files on my 3 year old Mac.

The only time I notice quickly is when there is a software or bug issue that prevents me from working well and efficiently. Whatever FontLab does to make Victoria dance needs to be rock solid above all. I much prefer rock solid to glitzy and cute features. The main feature that needs attention is search and replace.

I have licensed and support the further development of the 3 major players, FontLab, Robofont, and Glyphs and hope they all prosper and have a lovely synergistic competition among themselves. Competition is vital. We can never trust putting all of our eggs in one basket again. I have seen this in Quark, Adobe, FontLab, Apple, and Microsoft. When a product becomes the default standard, developers get complacent and the user gets screwed. May healthy competition thrive and keep all parties active and honest.

But the hobbits did save the day in the end.

hhp

We’ve been releasing the things first which were ready first.

TransType 4 was primarily made so that we could test the fully rewritten and modernized import/export infrastructure (OTF, TTF, EOT, WOFF, SVG, VFB, UFO and all the other formats, including conversions between them). We basically wanted the “gear” done and stable — before releasing a follow-up to FontLab Studio. We figured, it’s more important to have a tool with limited functionality which generates good fonts than to have a tool with full functionality that generates bad fonts.

FontLab Pad was done because it was very easy — it’s essentially the Preview panel of TransType. In the same vein, we wanted to have a tool for ourselves — a testing app for the color fonts in all the relevant formats (sbix, COLR, SVG).

We’re heavily under way on glyph editing right now. The lack of my activity here on Typophile and other forums actually indicates that we’re working hard.

We’ll start publishing pre-release versions of our new font editor in the next months.

You’ll love it, and you’ll be blown away :)

A.

I love it when loyalty pays off. Hopefully soon!

hhp

I recently purchased TransType 4 because i had a large number of fonts to generate. Overall, I have been very pleased with the results, except...

when TTF fonts are run through Font Validator, these error messages appear 100% of the time...

W0020—Tables are not in optimal order: table 'glyf' precedes table 'loca'

OS/2
E2132—The version number is invalid: 4
E2127—The table length does not match the expected length for this version
W0051—Cannot perform test due to other errors in this table: OS/2 table appears to be corrupt. No further tests will be performed.

gasp
E1003—The version number is not 0: 1
E1000—Some rangeGaspBehavior fields contain invalid flags

Only used TransType a couple of times since I got the update but like others it is very zippy and seems to work well.

Nick,

Microsoft Font Validator has not been updated in a long time. The OS/2 table version 4 and the gasp table version 1 have been added to the OpenType standard after the release of Font Validator, so the complaints related to OS/2 and gasp are all a false alarm. The tables are correct.

As for the "W0020—Tables are not in optimal order: table 'glyf' precedes table 'loca'" warning, it's by no means critical but we'll look into it.

Thanks,
Adam

Nick, with regard to the table order warning, this is a test that Microsoft put into Font Validator based on performance testing that they did in the 1990s. If the tables are in a particular order, Windows can do some things faster. If you're concerned about this, you can run the FastFont command line tool from MS on your fonts, which will put the tables in the 'optimal' order.

Adam, I don't know if the preferred table order is published anywhere, but you presumably run FastFont on a font and then look what the resulting table order is. If your new tools would write that order by default, it would save us a post-productions step.

It is mentioned in the OT spec's recommendations: https://www.microsoft.com/typography/otspec/recom.htm Search for section 'Optimized Table Ordering'.

John,

I routinely use FastFont to order the tables correctly, and it's a breeze: simply drop the font filename onto fastfont.exe, and it does the job in the blink of an eye. During my latest rounds of updating, I had to do this over 600 times, which became a bit tedious. I pointed out the anomaly in order to to save others the effort, because it seems to me that the fix should be easy.

Nick: ‘[…] I had to do this over 600 times, which became a bit tedious.’

TBH, I never used FastFont, but just had a look at it. Actually you can make a shell script for FastFont (using a listing of all your .ttf files). This is a bit less tedious ;-)

FEB

Great, great news. So looking forward.

I'm looking forward to the new FL release. Working on my latest typeface I have a set of swashes. I have been laboriously copying from 'results' in the Open Type Features Preview panel, then pasting into the Metrics panel to do the class kerning. It would be great if any features results could be incorporated into the main metrics panel for ease of editing. That would be a huge improvement.

Nick, while you wait, there is this: http://typedrawers.com/discussion/581/simple-kerning-pairs-builder-helpe...

That's very nifty Pablo. Thanks, it will come in very handy for those pesky extras.

"Fontlab Pad was . . very easy . . ."

So is it the fault of Fontlab Pad or TransType that kerning doesn't work on Photofonts?

Surely a glaring omission, considering the euphoria Fontlab seemingly displayed with the whole Photofont thing?