Fontlab 5 interface peeves

billtroop's picture

I have lately been using Fontlab 5 on the PC for some time, and recently switched back to the latest publicly released Mac build. I have been very happy with it, although I save multiple versions every day or so, just in case. But in spite of the truly wonderful things about this program, there are some things about the metrics window that have irritated me so much that I must speak out in ill temper. Apologies if these issues have already been raised.

Why isn't the tab useful in the metrics window? Look how Fog does it. The tab is a useful key. It is there to be used. So USE IT!

Why do kerning and metrics have to be two completely different operations, with enormous amounts of time lost whilst switching between them? For example, you are in the metrics mode. You have adjusted sidebearings. Now you notice a kern that is required. You now have to switch to kern mode. Now focus is lost on the character you were working on. So you have to select it again. DUH. So you select it, adjust the kerning and now . . . return to metrics. But you have lost focus. You have to select the character again.

Look how Fog does it.

Sidebearing and kerning adjustments all take place fluidly at the same time, with simple, easily remembered keystrokes. Why is there this artificial, time-consuming dichotomy between the two operations in Flab?

Why don't cursor keys work in the intuitive, expected manner they do in fog? Why do they either do something unexpected, or nothing at all?

Cursor keys are there to be used!!!!!!


LOOK AT YOUR OWN PROGRAM, now you own it!

Final example:

Let us suppose you are in metrics mode, and you are directly editing the metrics values in the value boxes. Up/down cursor will let you move up and down between width, left sidebearing and right sidebearing. But what happens to cursor right/left when you want to move to the next character? NADA! What happens when you want to move one element up to the character name box, as you can in Fog, and then move focus to the next slot, or gracefully move on to the next character? NADA!!!!

What possible reason can there be for such behaviour in a version 5 program?

Finally (really), suppose you now want to get into the tempting little kerning box. You can't.

You now have to switch to kerning mode, at which point . . . you lose focus and have to select the character again. OK. You're in kerning mode now. And you _can_ move up to the width/sidebearing cells with cursor up/down. But you still can't move up to the character name box and change the character you have selected, either by typing it or by using the keystroke for previous/next character. Also, the cursor keys now only control kerning. You can no longer change width values via the cursor keys.

Why all this confusing kerfuffle?

What is the intellectual justification for it? Is there some great philosophy of interface design here that I am missing?

Is it too much to ask to get these SIMPLE things RIGHT? I am totally exasperated at the total pointlessness of it all. This is not good enough! Yet I can't return to Fog at this point . . . . at least not until the metrics window gets antialiasing. Yet . . . I believe I could do this kind of fitting much more quickly in Fog . . . .

and what became of the fitting enhancements I and several others have been asking for, for . . . a decade? There's a lot of programming hours in a decade . . . . . . . . . .

billtroop's picture

(they must be looking in the manual)

billtroop's picture

Here's another question. I'm working with a four-master font. I want to make small numbers. I scale them appropriately. Now I have to hand edit them to change weight appropriately.

At _this_ point I would like a button that says, any point you move in one master will move the corresponding amount in all the other masters. (Indeed, that is a kind of feature that needs to proliferate throughout the interface.) That will not obviously work for every glyph/weight combination, but it will work for some; it will be a good starting point and a big labour-saver.

This can presently be kludgily done, I would have thought, using Transform/Shift, since that can be applied to one or all masters. BUT, mark the ineffable intellectual impulse behind this, the SHIFT command in Flab moves only the glyph. By contrast, in Fog, the corresponding command moves EITHER the glyph OR whatever points are selected.

It seems to me such an obvious need that points in a master will at times need to be moved simultaneously that I feel sure there must be an existing way to do this. Could someone let me in on the secret?

A sentence from 'La Cousine Bette' irresistably springs to mind, 'The secret of the profund secrecy of this secret was as follows . . . .'

billtroop's picture

So instead of something really useful and natural like a transformation command capable of moving selected points in several masters, or an editing mode where whatever you do to one point is reflected in the other masters, I am looking at some gee-whiz features that seem to have cost a lot of development effort:

sketch mode
interpolate nodes
move nodes (which seems to be broken on the Mac)

Can anyone tell me if these features are actually useful in professional font design? And if you had a choice, what would you prefer? Multiple master point editing or . . . . neighbours . . . sketch . . . . move . . . . interpolate. The last named seems to me particularly clever and particularly useless.

That said, there is a much more sophisticated thing that could be happening. Suppose you move a point -- the top of the inner o contour -- down ten units, to increase density. Wouldn't it be nice if the neighbouring handles, relating to the two (left/right) nodes below, were correspondingly shortened? Or that the corresponding bottom point might be heightened? That, if anything, is how the 'interpolate' mode ought to work. It would then be doing something that is actually useful in professional font design.

This is something that actual, professional, real-life font designers who make actual type faces, Yuri, actually do have to do every day.

It seems to me again that too much input is being accepted from enthusiastic hobbyists, not enough from those who actually know how to make good type.

Mark Simonson's picture

Neighbors is useful when making connecting scripts.

cuttlefish's picture

I had been contemplating buying Font Lab for months now, but after reading all this here I'm getting pretty darn scared of the thing. I think I'll stick with my decade-old copy of Fontographer a while longer, until I hear word of at least the documentation being brought up to snuff. The most powerful features in the world are of little use without instructions on how to use them to acheive a desired result.

billtroop's picture

In spite of the fact that working in Fontlab is always irritating and working in Fontographer isn't, I now do 95% of my work in Fontlab. The quality of Fontlab's anti-aliased metrics window, plus its ability to work with multiple masters and 'open'type fluidly, make its choice inevitable. On the other hand, if I had to draw a font from scratch, especially if it were an historical model and I was using bitmaps in the background layer, I would still probably use Fontographer. That said, when I use Fontographer, I use the old Fontographer 5 beta, mainly because of the 3200% zoom and improved interface, which I could never live without. And once the drawing was done, I would probably switch to Fontlab.

The problem with Fontlab isn't the documentation. The problem is that the authors use documentation as a crutch instead of figuring out how to make the program more helpful.

The criticism of Fontlab on this thread has been trenchant to say the least, but you can't criticize to this extent if you weren't using the program all the time, and we wouldn't be using it all the time if it weren't worth it.

When you're using Fontographer, you're very happy because everything that is there works well. But you do have in the back of your mind the feeling, what if? What if this program could actually do x, y, and z? Wouldn't that be a dream come true?

Many of those dreams have been courageously brought to reality in Fontlab. But it's clear we're not going to get those dreams to be happy ones by saying thank you. Hence . . . .

There have been other dreams coming to reality in type that have turned somewhat nightmarish, such as OpenType. Type technology is not moving along happily, compared to the relatively Arcadian days of the 1990s. Only painful criticism can bring about any improvement, as far as I can see. However, most users are reluctant to bite the hand that feeds them. They are mistaken in this, or so I believe. There has been a lot of sloppy thought in type technology these last ten years. Don't let them get away with it!

Many of the most brilliant type software people have long since moved into other, more profitable (or even more interesting) areas.

Recently, the editor-in-chief of PC World quit because a story critical of an advertiser (in this case Apple) was killed. All technology magazines know that the minute they go dishonest, they lose their readers. The situation at PC World reflects the reality that ad dollars are getting shorter and shorter, as print publishing becomes less and less profitable.

There are many things to worry about in this world, but being afraid of Fontlab is not one of them.

twardoch's picture

Bill, and others,

thank you for your comments. Be assured that they're being read and considered.

One small remark: Fontographer is, among others, so great because it is very simple. I believe that if Fontographer grew to the point of complexity that FontLab Studio has, there would be plenty reasons to complain.

Fontographer will come back. Some people will be glad, some will not -- that is quite to be expected. But I myself believe it will be a great tool.


dberlow's picture

"I believe that if Fontographer grew to the point of complexity that FontLab Studio has, there would be plenty reasons to complain."
Agreed. The two rong turns made in summary:
1. trying to line Fog up to a UI that matched Freehand for no reason.
2. trying to make a tool that satifies every level of user, and every form of output.

"Type technology is not moving along happily, compared to the relatively Arcadian days of the 1990s. Only painful criticism can bring about any improvement..."
Agreed and complete. I'm delighted, no...overjoyed! to see that things are "moving" again, and there is not a cliff nearby.

billtroop's picture

"simplicity" ... "rewrite"

OK, we have established two key thoughts, first that a big rewrite is planned, second, that there would not be so many interface problems with Fontlab were it not for its complexity, as opposed to Fontographer.

That is putting it a little too kindly. Fontlab has a very poisonous legacy, and that is the idea, long-held in by Yuri, that the best model for the interface would be Photoshop.

I would like to start by saying that Photoshop succeeds not because of but in spite of its interface. A worse model for a font program could not be found, quite apart from the obvious fact that they are entirely different programs doing entirely different things.

Now let's look at a specific example where this kind of thinking has caused a substantial and fundamental problem in Fontlab.

It is in the simple UNDO function.

In Fontlab, following Photoshop, every action, including cursor selection, counts as an unbdoable action. Undo is a literal concept. Every single thing you do is chronologically undoable.

This is an entirely wrong thing to do in a sophisticated, multi-layer program where _all the layers are used independently_.

Fontographer was the first font program that had independent layers, and each layer has its own undo history.

Thus, the outline layer, the background layer, and the guideline layer -- each has its own undo history.

This doesn't happen in Fontlab.

So: I have a mask [background] element in a glyph window that I want to keep in Fontlab. But I temporarily wish to paste a _different_ element into the mask layer for comparison purposes. Then I want to edit, and then I want to undo the operation _of the mask layer only_ and return to the mask element I had in the first place.

This simple thing can't be done in Fontlab. In order to undo what I have done in the mask layer, I have to do undo what I have done in the outline layer, defeating the entire purpose of the work. And that's not counting whether I could ever successfully paste that other element into the Mask layer to begin with, a far from easy undertaking.

Fontlab compounds the problem in a MM font. I do some edits in layer A. Now I do some in layer B. I now realize that I will have to undo some of what I did in layer A, without touching what I have done in layer B. It can't be done in Fontlab! The only way I can undo what I did in layer A is by first undoing what I have just done in layer B.

This is very bad behaviour and it reflects the rigid, and -- sorry -- unthinking application of Photoshop's interface to Fontlab.

Does anyone else agree, or am I the only person to take issue with this simple problem?

My thought is that if there is going to be a "big rewrite" then the time has come to let go of the Photoshop mentality for good.

twardoch's picture


regarding undo, you're wrong. FontLab Studio counts undo for each glyph separately (though across all layers). For example, in Glyph Window, if you do something to "B", then go to "D" and do something, then go back to "B" and hit Undo, the last action that you did to *B* will be undone.


billtroop's picture

Adam, everything I am talking about occurs in one glyph, surely that's obvious? When I speak of "Layer A" or "Layer B" I mean an arbitrary layer in a glyph window which could be outline, background, metrics, guidelines, etc. This is a very common way of speaking in English and should not be misunderstood. I could have said also "layer 1, layer 2" or "layer i, layer ii, layer iii" and meant the same thing. "Layer" implies we are in the same glyph window. I think everyone by now realizes that what you do in GLYPH A is not reflected in the Undo history of GLYPH B. Would you terribly mind reading my message again and telling me if you still think I am wrong?

Nick Shinn's picture

I agree Bill, and I have to apply a workaround of copying my latest version of one layer to the copyboard, then doing all my undos, then pasting back the outline -- if I haven't been distracted or inadvertently copied something else over. If you know what I mean.

What might be useful is to be MORE like Photoshop, and have a "History" function to undos, so that one could go forward as well as back. Or perhaps that's already there, and I just don't know the command.

billtroop's picture

Nick, I assume you meant that about the undo history in jest; I am pretty confident that there isn't one. But I also find pretty near-unbearable that when you undo, you aren't told what action it is you are undoing as well. I think history would be a good idea, but I still think each layer (including MM layers) should, indeed must, have its own undo. You highlight also the problem that the workarounds are so cumbersome that you are apt to forget what you are doing.

twardoch's picture


you wrote "In Fontlab, following Photoshop, every action, including cursor selection, counts as an unbdoable action. Undo is a literal concept. Every single thing you do is chronologically undoable."

This was a simplification. In Photoshop, you have the concept of layers while in FontLab Studio you have the concept of glyphs *and* layers. A font is a two-dimensional structure while an image is only one-dimensional (I mean the dimensions of different structure elements). In Photoshop, undo is on a per-document basis, while in FontLab Studio it is stored on a per-glyph per document basis, so it is more sophisticated than in Photoshop. It is not stored on a per-layer per-glyph per-document basis (which is what I believe Fontographer does), which would be even more advanced. But I don’t think comparing the FontLab Studio undo to the Photoshop undo is adequate.


billtroop's picture

Adam, once you realize that a glyph is conceptually the same 'space' as a Photoshop object, then you are still talking about a one-dimensional space. You aren't addressing the problem. Each master, and each layer of each master, needs its own undo history. Until this is implemented, undo is a pretty useless function in Fontlab. Hasn't David in an earlier thread written something about getting these basic functions right before you go on to 'neighbours' and 'interpolate points' and things like that? It really doesn't matter just where Fontlab's undo function came from historically. It matters that it is dreadfully, embarrassingly inadequate and needs to be at the top of the fix list.

William Berkson's picture

>Until this is implemented, undo is a pretty useless function in Fontlab.

This is a ridiculous exaggeration. I use undo all the time, because for me anyway letter design is about trying lots of possibilities to see what works best. I agree that having the mask layer with an independent undo would be nice, but the fact that you now can go from glyph to glyph and each has its own undo is very useful indeed.

billtroop's picture

William, all font programs since the beginning of time have had undo on a glyph-by-glyph basis. Nothing else is conceivable, and Fontlab certainly deserves no credit for this innovation. I would agree with you that the undo function of Fontlab was adequate -- barely -- if _all_ of your work occurred exclusively in the outline layer -- as apparently it does. But if you need to do substantial work with the mask and guide layers, and if you need to work with multiple master fonts, it is simply not adequate. In Fontographer, everything you do in the mask or guideline layer is undoable on a layer-by-layer basis.

Do you work with multiple weights/masters/instances? Do you work with the mask layer?

Is anyone who works with these additional layers happy with the way Fontlab does undo? If so, why? I would really like to know. For myself, I cannot imagine any right of doing undo other than the Fontographer way.

Let me give you an example where this is useful. You are working on a character in the outline window. Let's suppose it is a bold. In the mask layer you have an earlier bold version for reference. Now you want to see what happens when you put the Roman version of the character in the mask, or an earlier version of the bold, or an instance of the character from a different font that you intuit might be helpful to look at. So you do that, and you make some more edits. Now you want to have the _mask_ layer revert to the first of the characters it held. In Fog, this would be one simple undo operation, or two. In Fontlab, it means undoing all the edits you have made in the _outline_ window.

Do you see anything rational in this? Is there any reason why, in order to undo what you have done in the mask layer, you should first have to undo everything you have done in the outline window? Does this seem like a professional modus operandi to you?

yuri's picture

I have to say that "layers" concept is not really developed in current versions of FL. It is more or less artificially here on UI, but not in data structures of the file. In the next version of the tool layers will be suppored at full power.

William Berkson's picture

>Fontlab certainly deserves no credit for this innovation

Bill, I am not a mind reader. I was responding to what you actually wrote, not what was in your head. What you wrote is that "undo is a pretty useless function in FontLab". That is ridiculous because without undo, the program's usability would be crippled. What you meant to say, I see now, is that FontLab has problems in this area, and no useful innovations compared to other Font development programs. That is fair enough, but it is not what you wrote.

And yes, I do use the mask layer continually, and giving layers separate 'undo' controls would be very good, as you suggest. And Yuri, if I understand him, will implement that in the next version of FontLab, which is great.

billtroop's picture

Good, so that's settled, or is it? Re-reading this section, I am not so confident, William. Yuri says layers will be supported at full power. Is that the same thing as saying that he will implement undo properly?

While we're at it, here's another interface insanity: you're reviewing an MM. You're in the Axis panel, using the slider quickly to slide from extreme to extreme, checking that the interpolation and perhaps the extrapolation is working OK.

Now you want to go to the next character, and quickly do the same thing; and then you want to go to the next, and the next and the next.

You would expect, wouldn't you, that all you had to do was press one of the various 'next character/previous character' keys, and continue happily on your way?

You would be sadly mistaken.

Those keys don't work while focus is on the Axis Panel.

You actually have to take up your mouse, move to the glyph window, and click, before you can get your next char key to work.

For some reason, the world stops when focus is on the axis panel, and I think there are similar problems with some of the other panels. Could anyone document these?

Vladimir Tamari's picture

Hi does anyone know what are tiny double arrows doing superposed on the curser arrow in glyph window. They change from vertical to horizontal and obscure the points. I need to switch them off thanks. FL 5.2 Win installed on Win8.1 as a guest in Virtual Box on a Mac host.. These superfluous arrows behave like the ones that appear to move guidelines. On other occasions I get an outline cursor and dragging behind it and just visible a black arrow cursor. Strange.

Syndicate content Syndicate content