To amplify (because I can't figure out how to edit the comment), you are in kerning mode. Cursor L/R changes values; Shift adds ten. So far so good.

But command and option also do EXACTLY THE SAME THING.

What is to prevent cmd/opt arrow from changing L/R sidebearings at this point?

The intellectual work behind figuring out what to do with these obvious keystrokes was done by Altsys 20 years ago. What is the problem with taking advantage of something absolutely expected in contemporary software? Or, one might ask, why is the primary key change in Fog 4/OS X that cmd-Y is no longer the undo key; instead it's shift-cmd-Z. WHAT ? ? ? ? ?

Who thought these things up? Why? How can they possibly be justified. I realize I am setting myself here for a 'well, Bill, if you would just read the manual, where we explain such and such, or well Bill, if you would just _think_ for a minute, you would realize why we did such and such and why it's such a good thing.'

OK. I'm ready for it.

Monopoly?

> “Monopoly?”

As in, FontLab Studio, DTL FontMaster and FontForge all being fully-capable font creation environments (with FontForge being opensource and free), and numerous other tools such as High-Logic FontCreator available in the low-end market?

Users interested in getting the tools exactly the way they want them are welcome to write the specifications of how exactly they would like the tools to work.

A.

"Users interested in getting the tools exactly the way they want them are welcome to write the specifications of how exactly they would like the tools to work."

Right, is exactly the way we would like the tools to work. Without competition, we need not write you, we need to write code. You don't respond to even the simplest, or most basic requirements of the type designer with brain onboard. You have a monopoly on FL functionality.

This does not mean, by the way, that I don't like this tool. It means, I would never recommend it to anyone else, and I would not ever dare to teach using it, because I don't have time to explain its idiosyncractic and illogical behaviors.

David, very few people have been drawing type constantly for 30 years, as you have. So that what is obvious to you may be far from obvious to others.

I am new to this, but my impression is that FontLab has been quirky, but that the developers at FontLab are responsive to the suggestions of their customers, and there has been a steady improvement in usability.

Perhaps listing your suggestions here will help. I'm sure others will chime in and confirm your suggestions, or make additional or different ones.

You're Bill, I'm wrong to criticize FL. But, I'd rather be wrong than lazy.

Listing my suggestions is how I started this issue, here, a while ago. Many of those issues got better with 5, some did not, and of course, there were are more issues now that when I began. Since then, I've fed an-issue-a-month directly to Adam, as he asked me to do it that way, (better you know), so now I only raise issues here when they've lingered quitely in Adam's in box for more than a month, or if someone here reraises an issue that's still festers.

"As in, FontLab Studio, DTL FontMaster and FontForge all being fully-capable font creation environments (with FontForge being opensource and free), and numerous other tools such as High-Logic FontCreator available in the low-end market?"

This, misunderstanding of how monopolies are determined, is an excellent response for those who not wonder what their tools can do for them, but what else they can do for their tools.

Cheers!

(sorry bout my typing, but my denrist, knowing of the fondness I have for his assistant, insisted on putting novacaine in my moyth an hqnds this mormng,

We know the drill David :-)

ChrisL

> You don’t respond to even the simplest, or most
> basic requirements of the type designer with brain
> onboard.

We *are* listening to you, David, as well as to other users of FontLab Studio. But please understand that we don’t randomly fix and change small things as they occur. Instead, we collect feature requests and bug reports, prioritize them (we have, after all, a rather small team of developers) and feed them into the development schedule. Just four days ago, we released TypeTool 3, a fully-new version of another product (that is closely related to FontLab Studio but separate). This all takes time and resources. We will revisit your ideas and requests during the next round of FontLab Studio development, I promise.

A.

Adam,

What is the preferred method to submit interface comments/peeves to the development team? Will it make it to the right place by filling out the "problem report" form?

Andy

Yes.

A.

This is what I really would like to do: collect many FLS suggestions that we got and put them into new update. Unfortunately what I have to do at current moment is to work on some other projects that we need to release. But FLS will always be a top priority for us.

I would be just thrilled if FL5 Mac version would not crash so often. It is the only program I have out of hundreds that I can guarantee will crash every time I use it.

ChrisL

>I would be just thrilled if FL5 Mac version would not crash so often. It is the only program I have out of hundreds that I can guarantee will crash every time I use it.

I have had my problems with 5.02 in the past, but whether it is 10.4.8 on a pretty fresh install, or improvements in the latest build, I and several others I know can now run 5.02 for days or even weeks without crashing, and that includes some pretty complex files and operations. In fact, in some respects, I have actually found the Mac build more stable than the some Windows builds.

I don't believe in private feature request lists. My experience is that companies only respond when things get public. Here's another gripe. Can you control the idiotic automatic strings that appear when you click on an entry in the metrics table?

For example, HOH6non is not useful when you want to look at H6H or O6O or n6n etc. It is incredible to me, so many decades after H_H n_n fittings lists have been in constant use, that Fontlab can't get this basic principle across. One sees all these wonderful things happening, yet one constantly gets the feeling that neither Yuri nor Adam has ever sat down for a day or two with a really competent font designer to observe what actually needs to be done. Too many geeks, too few craftsmen.

>Can you control the idiotic automatic strings ...?

You can edit test strings and insert your own by clicking the button with three dots to the right of the window with the strings.

This way to edit test strings is noted on p. 54 of the Windows manual. Bill Troop's question here I think indicates the weakness of the manual, which for me personally is the single biggest problem with FontLab at the moment. If you look under 'metrics' as I have just done, you will find that the metrics sections are scattered over three or four different places of the (huge) manual. So to find the answer you have to hunt all over the place. And you have to know what to ask in the first place.

If all the information on metrics were explained in a task-oriented way, all in the same place, it would help greatly to make the FontLab features accessible to the user.

This would mean repeating information in different places, but there is no problem with that. Currently the manual is organized as programmer's notes, rather than as a guide for users. The makes FontLab's treasures a lot less accessible.

As I said in another thread, Karsten Luecke should write book on FontLab. He seems to be able to explain it in a way that is more digestable by a user. The current manual seems to be written from the programmer's perspective, explaining things in a hardware store fashion rather than as a working process.

ChrisL

Hi William, that's not what I mean. One of the good things about the metrics window is that you can open the metrics table and it will appear in a window at the right. You can now cursor down through each character, and as you do so the new character will appear within a control string. The only problem is that the control string cannot be altered (as far as I know) and is not useful. It is as follows, taking / as the character we have selected:

HOH/non
HHH/nnn
OOO/ooo
XHX/xox

What we want is something more like HH/H OO/O, nn/n oo/o. The FIRST thing you want to see is the new character between the standard control characters of H,O,n,o. This is bedrock fitting practice.

So the questions are:

why did Fontlab do the string in such a perverse and useless way?
can it be customized?

If this were to work in the way I suggest, it would actually be a useful quick tool for font designers to use, always being mindful of the distortions that screen resolution, even with efficient anti-aliasing, will create. Fontlab had a great convenience idea here, but implemented it in such a way that is next to useless.

I am not referring to the fitting strings you can select from the drop down. They are not useful. What you want is something to scroll through. The program is almost there -- so near -- yet so far. Why, why, why?

>This, misunderstanding of how monopolies are determined, is an excellent response for those who not wonder what their tools can do for them, but what else they can do for their tools.

David has put his finger on what distinguishes those who need to produce good fonts and those who enjoy playing around with software.

As for private suggestions . . . how many years is it since I gave Fontlab a more or less simple way productively to semi-automate rational metrics fitting? Two? Three? Four? Five? Six? Seven? How many followup discussions were there? Could anyone even find the emails at this point?

Hi William, that's not what I mean. One of the good things about the metrics window is that you can open the metrics table and it will appear in a window at the right. You can now cursor down through each character, and as you do so the new character will appear within a control string. The only problem is that the control string cannot be altered (as far as I know) and is not useful. It is as follows, taking / as the character we have selected:

HOH/non
HHH/nnn
OOO/ooo
XHX/xox

What we want is something more like HH/H OO/O, nn/n oo/o. The FIRST thing you want to see is the new character between the standard control characters of H,O,n,o. This is bedrock fitting practice.

So the questions are:

why did Fontlab do the string in such a perverse and useless way?
can it be customized?

If this were to work in the way I suggest, it would actually be a useful quick tool for font designers to use, always being mindful of the distortions that screen resolution, even with efficient anti-aliasing, will create. Fontlab had a great convenience idea here, but implemented it in such a way that is next to useless.

I am not referring to the fitting strings you can select from the drop down. They are not useful. What you want is something to scroll through. The program is almost there -- so near -- yet so far. Why, why, why?

>This, misunderstanding of how monopolies are determined, is an excellent response for those who not wonder what their tools can do for them, but what else they can do for their tools.

David has put his finger on what distinguishes those who need to produce good fonts and those who enjoy playing around with software.

As for private suggestions . . . how many years is it since I gave Fontlab a more or less simple way productively to semi-automate rational metrics fitting? Two? Three? Four? Five? Six? Seven? How many followup discussions were there? Could anyone even find the emails at this point?

Bill,

To change those strings you can edit the text file at:

Library>Application Support>FontLab>Studio5>Data>Metrics.txt

James

Bill,

To change those strings you can edit the text file at:

Library>Application Support>FontLab>Studio5>Data>Metrics.txt

James

Bill, I didn't get right the first shot what you are talking about, but I think I've got it now.

When I open the kerning table with the 'metrics' button pushed on the bar and click on E, I get the string HOHEHOH followed by HHHEHHH followed by OOOEOOO and another string. And this is what you are asking for, no?

When I click on a lower case letter, it has caps to the left and lower case to the right, as you say. That is a not good, I agree.

When I open the kerning table with the 'kerning' button pushed and click on say Es, I get the strings you are complaining about, but those seem rational for kerning no?

I didn't know about all this before, so I'm glad you bring it up.

So far as I can see none of this is even documented, much less explained in the FontLab manual.

I really think that lack of documentation is a screw-up, like the lack of documentation of many of the keyboard short cuts.

edit: I think what may be going on here is that there is one metrics.txt file for 'metrics', as James points out. If you have a kern to lower case, such as 'To', then I suppose it is best to have caps to the left of T and lower case to the right: HHHTonnn or some such. But if you want to space both sides of the o, then it would be better to have nnonn, etc. But with only one metrics table, probably intended for kerning, then the way FontLab does it is the only way to go. But then you can't use the table in the same way when the 'metrics' button is pushed. You would need to change the text in the metrics.txt file when you switch between spacing and kerning, if I am understanding this rightly.

James, thanks for this info, William, it actually is in the manual if you do a search for 'metrics.txt' -- so there really is some documentation. However, I have been editing this file and have not seen anything change! I changed the ownership of the directory from System to my name, otherwise I wasn't allowed to edit. Could that screw things up? But where is Fontlab getting the tables from then? Oh, this is driving me nuts, what a waste of time! PS Yes William I think you are right about the kerning. Right now I'm just trying to deal with straight metrics. The better your metrics, the less kerning you need.

OK, I changed the ownership back to system; no change. Why isn't Fontlab accepting the edits? Yes, I have rebooted in case there was some kind of nutty caching going on . . . .

Ok, my mistake on the documentation. Sorry FontLab. However, you are going to find it difficult to locate this in the index. In future, I guess I will have to search the PDF rather than using my hard copy. A better index would be welcome. Also there is no mention that it works--sort of--in metrics mode. You could say that using it in metrics mode is a 'hack', as they don't mention it. But so long as they have the functionality shouldn't they explain it?

On changing the metrics.txt, might you be having a cache problem?

Bill, I'm sorry I wasn't specific enough.

There are two libraries in OSX, I believe you are following the path the the metrics.txt via the Library at the HD level. What you need to do is use the Library that is located under User. Username/Library/Application Support/Fontlab/Studio 5/Data/metrics.txt

I just made some edits there and they show up fine, without having to manipulate permissions.

James

OK James, good info. However, I had only been able to find one metrics.txt file on my system; the data folder was blank in /username/lib/etc. OK. So I copied the modified metrics file over. Still no response. What gives? Grrrrrr!

OK, OK, finally found yet another data folder . . . . yes, it works.

OK, I now have the metrics window working. I have two fonts whose widths I am comparing. I am using the metrics table to scroll down. I look at font 1. I scroll down from A to B.

I click on Font Window 2. I scroll down from A to B.

Now I click back onto Font 1. I want to scroll down to C. But I can't do that just by using the down arrow! THE WINDOW HAS LOST FOCUS. Why? Why? Why? I now need to go through the additional steps of using the mouse or pen to click on metrics table, select B or C, etc. etc.

Just because for some reason this program -- unlike any other I have ever used -- somehow loses focus on what was going on right after you click on another window.

I think this kind of thing might be what David is talking about when he talks about designing for humans?

Similarly, the arcane undo feature. In Fontographer, it is assumed that undo applies only to what you are doing in a certain layer -- it is layer specific. Do 6 actions in the template window. Now go into the outline window and do 5 actions. Now you see something you want to undo in the template layer so you go there and undo it. What happens in Flab? You go into the template layer and it undoes the 5 actions you just did in the outline window (the ones you don't want to undo) because Flab's undo doesn't respect layers. Same thing with masters. This is intolerably bad design in my view. What is the rationale for it? And by the way, what is the matter with UNDO letting you know what action it is undoing -- something most programs have done for a long, long, long time ? ? ? ? We're HUMANS . . . . . . . .

Fog 3.5 "knew" and I'm not going to say how ;) that the "type designer" "wants" the mouse to "stay" in the glyph window and not be "run" about to get "stuff", and that the "designer" "wants" to "work" in the metrics window "ENTIRELY" by keyboard is proven.

I can only say for sure that there is a fully functioning model of exactly what it should look like and work like, that it has been available since 89, and that the developers of FL can see, use and copy it at their pleasure.

Maybe if they had to DO THIS JOB, they could do theirs too, but in the absence of either doing it, or listening to those who do, I'm only designing fonts that "need no kerning," or "already have it", 2 years now.

Cheers!

>Fog 3.5 “knew” ... Maybe if they had to DO THIS JOB ...

Are you listening, Yuri? Yuri, you know I love you beyond telling for all the wonderful things you have done, but . . . are you listening?

Advice from the very highest places doesn't get any better than this.

The world's most competent typeface designer is saying something important here.

How much does it cost to fly to Boston for a couple of days to sit down with someone who can help you beyond measure? And please let's not hear anything more about email suggestions and posts. Sitzfleisch is what is needed here. That 1989 was a long, long, time ago proves that.

Yet more interface insanity:

I'm in the metrics table. I'm scrolling down, trying to fit a face quickly.

WHAT DO MY CURSOR KEYS DO? ? ? ?

Well, right/left arrow increases/decreases RIGHT SB by 1 unit, adding shift by 10 units.

So far, so good, apparently.

But what if I want to change the left sidebearing? What does option, command, control, etc. do? EXACTLY THE SAME THING!

Will tab get me to the next field, shift-tab get me to the previous field? NO.

The only way to get more control is to use the mouse and click on the OTHER metrics table, the one at the bottom. Here, you have option and shift regulating left/ride SB; plain cursor moves the character within the field.

So nothing works as expected or as logic would dictate. Everything is so cumbersome you want to cry. Or, as David says, give up kerning altogether. Because it _is_ a monopoly situation here. The other options are no longer serviceable.

I will try to follow:

- "HOHhoh". It is customizable, but it is class-based. Some classes such as "uppercase" or "figures" are "virtual" - you don't need to define them, but for more specific things you have to. When you have classes, that "metrics template" can be adjusted by editing the metrics.txt file.

- Shortcuts in the MW. On Windows it is designed in a way that it is not needed to use mouse at all - everything can be done by keyboard. I will check if that was not lost during the Mac port.

- Mixed metrics and kerning editing. Well, technically it is very easy to implement. I always though that it is right to work on metrics separately from kerning, so in non-kerning environment font will look good. OK, I will do Fog-style mixed editing, will see how it works.

- Undo. I only can agree that its implementation in FLS/TT is not good. It was improved, but unfortunately it cannot be done as I'd like it to work until next Big Rewrite (which is soon). That Rewrite will also introduce completely new UI and new workflow.

- Fog 3.5 was a great tool and we still have to learn a lot from its simplicity. Unfortunately font technologies changed so we have to care about such complex things as class-kerning, non-Latin fonts etc. Typical font is not Mac Roman anymore and it makes impossible to have simple and elegant solutions that will really work only for Latin.

Anyway, it gives us no excuse to lose focus in windows. I beleive that is implemented OK in Windows build but what I need to check it in on a Mac side.

Good news - now I got Mac computer at home so I am gaining a lot of personal end-user OS X experience :)

"now I got Mac computer at home so I am gaining a lot of personal end-user OS X experience"

Yes! Mac users are people too and would like equal trteatment :-)

ChrisL

More news:
We decided to not rely only on internal testing and beta-testing programs but also do extensive professional out-site testing of our key applications.

Upcoming new version of BitFonter passed this testing process (about 2 months of work, about 300 fixed problems) and TypeTool/FLS is in progress (already almost a month, about 100 problems to fix).

MW keyboard (as it now works in Windows build). In metrics mode.

When focus is in main area and some glyph is selected:

Arrows - move glyph left-right without changing width;
Ctrl + Arrows - change LSB and width, RSB is not changed;
Ctrl + Alt + Arrows - change RSB and width, LSB is not changed;

Pressed Shift increases "force" by the "shift accelerator" value that you can specify in Tools > Options > Glyph Window (!) > Dimensions.

When focus is in table:

Arrows - increase and decrease width by modifying RSB;
Ctrl + Arrors (new thing, will work in upcoming 5.0.3 update) - increase and decrease width by modofying LSB;

Shift - accelerates by the "shift accelerator" value (defaulting to 10)

Tab key alternates between "main area" and "table".
To select glyph for editing in the main area use "PgDn" and "PgUp" keys. "Home" and "End" also work. "Esc" drops selection so when you press Tab and switch to table, "HOHOhoho" templates will work again.

It is all about Windows build, I will make sure that it works the same way (and better) on the Mac.

>Shortcuts in the MW. On Windows it is designed in a way that it is not needed to use mouse at all - everything can be done by keyboard.

Yes, in Windows you can move the left sidebearing with control + l & r arrow keys, and you can control the right side bearing with control + alt + l & r arrow keys. And the latter is NOT DOCUMENTED.

I have suggested in an e-mail to Adam that the up and down arrow keys control the width of the sidebearing, adding one unit to both sides (up) or subtracting one unit from both sides (down). That way it is easy to vary independently the two aspects of spacing a glyph between control characters: the centering and the advance width.

edit: I see I have cross posted with Yuri's latest. Let me just emphasize that the lack of documentation of the functions hurts usability, and is really annoying, at least to this user.

Mixed metrics and kerning editing:

If you want to enter numbers, it already works perfectly if you use panel (almost direct copy of the similar thing in Fog 4).

[a trick: instead of entering numeric value there you can enter = followed by the name of the glyph from which this value must be copied. You can also enter things like 200/2 or 50+50(which will result in 100 in both cases)]

OK, that is not keyboard and not mouse - just typing in some numbers - we will consider adding mouse and arrow editing for metrics in the kerning mode.

Adding a unit to both sidebearings seems to be a very nice feature.

Let me think how it could be done without changing current way of working. Maybe there could be an option which will alternate "ctrl" or "ctrl+alt" arrow modes with "balanced" weight-adjusment.

Or alternatively it will replace current Ctrl + Up/Down (currently shifts glyph up and down, with optional shift acceleration) with this new mode.

>nice feature

Thank you. The idea comes from David Kindersley's book on optical spacing. He pointed out that there are two different problems in spacing: centering and advance width.

Currently the left and right arrows move the whole glyph left or right, and the up and down by themselves do nothing, at least on my windows machine. So if the up and down arrows would increase or decrease the advance width by one unit (or with shift accelerated 10 or a defined number of units) that would make for a very natural work flow, I think.

Currently up and down keys are used to navigate in multi-line text. What I am doing is to provide an option (will come to Tools > Options > Metrics window and in similar place on the Mac) that will replace this with balanced width change.

It will change LSB when width is odd and RSB when it is even. Width will change by 1 unit.

Thanks!

It would be nice if you could ask a sample of designers what defaults they want, on this and other issues. I suspect that the balanced width change would be a preferred default, but of course I don't know.

edit: I just thought of something else.

I don't know about anyone else, but if I am having difficulty spacing something I like to make it clearly too loose and then clearly too tight, and then I know the correct value is somewhere in between.

So if you have shift + up and down arrow keys move both side bearings simultaneously by say 2 units, then the user could use this function to get a rough indication of correct spacing. Then he or she could release the shift key and make the finer final adjustment, as you describe.

I consider it OK to change some defaults in first-number version change (from 4.x to 5.0 for example) but when we go from 5.0.2 to 5.0.3 that's too much :)

Anyway, I just implemeted the feature as an experiment and it seems to work perfectly. Thank you!

Yuri,
Thank you for being responsive to us here. Many of us spend much of our waking hours with FLS and would be able to get more sleep if it were to have an improved interface. :-)

ChrisL

And don't forget the TAB!

We're in the metrics panel. We change left sidebearing manually. Now we want to tab over to right sidebearing . . . . tab tab tab tab tab is an important key key key key

I had not realized there was so much difference between Mac and Win. I could perfectly well be using Win version but was enjoying Mac so much I didn't see the point. However, I will switch over to Win before adding to my gripe list, recognizing that Win always comes first with Fontlab. Truthfully, I have found that the build I am using on Mac is substantially more stable than the building I am using on Win, which is not what one would expect.

and my first grip about the Win build I am using is that it seems exactly the same as the Mac build when you're in the metrics table of the metrics window . . . . .

"- Shortcuts in the MW. On Windows it is designed in a way that it is not needed to use mouse at all - everything can be done by keyboard. I will check if that was not lost during the Mac port."

Not in my Win build it ain't.

Re metrics.txt (and ... how much sense does it make that there are three possible places it can go though only one of them actually has any effect ...), there are three classes: uppercase, lowercase, and smallcaps. Are there any other classes that are recognized by this file, such as numbers, punctuation, other, whatever? Where might they be defined and perhaps altered? (and not that it should be necessary to do this . . . . )

Bill, what is "tab panel"? In FLS terminology it is a horizontally-oriented table that can be located on top or at the bottom of the main metrics/kerning editing table. There is main area, panel, table (vertically-oriented, at the right) and a ruler (thin line that shows metrics data for the current line and is not editable).

If you are talking about the same panel then (in Win version) Tab works there, it is used to go to previous and (with Shift) glyph. Vertical arrow keys allow to select which value you want to modify in the current glyph.

>Bill, what is “tab panel”?

Yuri, you must mean metrics panel. When I said metrics panel, I should have have said 'metrics table' -- the vertically oriented, editable panel which shows the entire font's metrics. Let us call the vertical arrangement the metrics table and the horizontal arrangement the metrics panel.

Because the only way we can automatically generate context for succeeding characters is by using the metrics table, this will be the primary way we navigate through metrics.

If, on the other hand, you had made it possible to generate a fitting string and then, by having the first incidence of the control character be a kind of master character, and then, each time you change that master character (for example by next/previous character) you change ALL incidences of the master character in the fitting string, then, we would be using the metrics panel, not the metrics table, as our primary metrics editing area.

But you didn't. Honestly, you will never, never, never understand what David, me, or any of the rest of us are talking about until you spend a couple of days sitting down with us. Discussion of this kind, by post and email, is a complete waste of time. Because more than fifteen or so years after being the best programmer of font design programs, you still have absolutely no idea how a font designer actually works. It is time to find out. Start with Berlow. In the entire world, there is nobody better to start with. The problem here is not intelligence, is not intuition. It is fifteen years of bad communication.

No matter how busy you think you are, drop it and force yourself to spend some time with a few key people. And I don't mean just an hour or so gabbing. I mean several hours with each, patiently observing how a font actually gets designed. There is no substitute for this. It is now abundantly clear -- indeed it has been clear for at least the past ten years -- that this is what you need to do. Words just don't do it. You've got see it, you've got to experience it. Don't you begin to see what a complete waste of time words are? The hundred misunderstandings on this thread, so time-consuming to elucidate, illustrate that.

Bill, every designer has very different approaches to do the same things with the font. I am listening to many designers and I've spent quite some time learning how some of them work. In ideal world it will be possible to adjust every tool and every UI element of the program to fit any possible type designer. In a reality we have to make a tool that will suit as many designers (professional and not) as possible. So we have to make compromises. Again, it give us no excuse to make errors and we always try to fix them.

But you are right, we really need to learn more. I will be in Frankfurt on Typotechnica in few weeks, then I will certainly come to Brighton. Maybe TypeCon too. If anyone is ready to share any FLS or Fog experience with me - I will be glad to run my camera.

Actually, it will be even better if anyone interested can just record some routine font-editing process (metrics editing or anything else) with good screen-capture software. It will let us analyse the workflow and isolate any UI problems that eat time.

However, it is also necessary to just learn FLS if you want to use it at full power.

"Automated Template", proposed by Bill:
Very similar thing can be already done in FLS using the Preview panel. In preview panel when you enter '@' into sample string it is automatically replaced by "current glyph" - glyph in GW that is active or currently selected glyph in MW. Which means that you may make something like "H@H@O@A@V@T" and put it into Preview panel. Then when you select different glyphs in MW, preview panel will automatically update.

This is certainly not the same as having this feature built into MW, but it may help.

>when you enter ‘@’ into sample string it is automatically replaced by “current glyph” - glyph in GW that is active

Nice. I missed this in the manual--or is it just not there?

It is not in the manual, just checked that. We will fix that in the next update.

>not in the manual

There are also a series of keyboard short cuts not in the manual that I have kept discovering. [ctrl + plus activates zoom, shift + control + alt activates measuring tool, ctrl + alt activates right sidebearing of selected glyph in metrics window, etc.]

Life will be better for us users of FontLab if this stuff is not only all in the manual, but also is explained as part of a *work process* as several have noted in this thread.

In other words, you take a task, like spacing and explain in the manual three ways to do it, step 1-5, and how each function is used at each step. I have a feeling that if this effort is made in consultation with you programmers, you will catch almost all of the omissions from the manual, as you have for this case.

And of course if it is not in the manual effectively it is not in the program, even if it actually is.

>This is certainly not the same as having this feature built into MW, but it may help.

No, it doesn't help. It's way too cumbersome to have to use the preview panel and the metrics window simultaneously open so that the preview panel can now do something that the metrics window should be doing. This isn't a serioius solution. At least not the way I have been able to figure it out from trying it out based on what you wrote.

Further questions about the metrics table. Why doesn't pressing an alphanumeric key bring you anywhere? It should at the least bring you to the next character beginning with that letter, then the next, etc. etc.

And why on earth doesn't page up/page down work in the metrics table? How on earth are you supposed to navigate through this table then? ? ?

It is all hopelessly inept and you should all be embarassed to present such things in version 5 software. Excuse such harsh words, but if there ever was a time to speak plainly, it is now.

I don't accept your other points, which I will take in turn:

>Bill, every designer has very different approaches to do the same things with the font. I am listening to many designers and I’ve spent quite some time learning how some of them work.

Either you're not listening hard enough or you're listening to the wrong people. The kind of behaviour I have described just within this message should not exist in any program, period. And I know perfectly well you're not listening either to Berlow or to me (not that I mean to put myself in the exalted position of Berlow).

>In ideal world it will be possible to adjust every tool and every UI element of the program to fit any possible type designer. In a reality we have to make a tool that will suit as many designers (professional and not) as possible. So we have to make compromises.

Yuri, this isn't about compromises. This is about good interface design and bad interface design. You have a table. The metrics table. You can navigate through it ONLY by pressing cursor up/down as far as I can tell. Or the mouse. Why don't al/num characters have input? Why doesn't Pgup/PgDn work as expected? That isn't about compromise or preference. That is just about decent interface design.

>Again, it give us no excuse to make errors and we always try to fix them.

In the category of bug fixes, we are all tremendously grateful to you as you know -- except Erik. I am not talking about errors. I am talking about design.

>But you are right, we really need to learn more. I will be in Frankfurt on Typotechnica in few weeks, then I will certainly come to Brighton. Maybe TypeCon too. If anyone is ready to share any FLS or Fog experience with me - I will be glad to run my camera.
Actually, it will be even better if anyone interested can just record some routine font-editing process (metrics editing or anything else) with good screen-capture software. It will let us analyse the workflow and isolate any UI problems that eat time.

This is a mountain must come to Mohamet excuse! However, if you want to set aside a day for me in Brighton, I'll set aside a day for you in Brighton. Just name the day. But while I admit I could help you out somewhat, it's not really me you need: it's Berlow, who has designed more professional quality glyphs than anyone else on the planet. Perhaps he expects you to come to him. Heaven knows, others have. Perhaps you mind that? Others, too, did, no doubt. But they made the pilgrimage, and they came away enriched. We all benefitted.

>However, it is also necessary to just learn FLS if you want to use it at full power.

Yuri, I don't think that's fair, you know I sometimes read the manual . . . . .

> It is all hopelessly inept and you should all be embarassed to present such things in version 5 software. Excuse such harsh words, but if there ever was a time to speak plainly, it is now.

Well, metrics table (and many other MW improvements) was first introduced in FLS5 so for this block of features this is really a 1.0 release. For many features (like multi-line, table, "metrics tools") we actually took Font Studio as a sample, not Fog. For others (new metrics panel) we took Fog. Some features (live OT class-based kerning editing with exceptions and kerning/metrics templates) we had to invent new UI - there was nothing like that before. I don't think it is fair to blame us for UI misfeatures in new MW which is just really new. It is improving in any new update and will continue to be improved. I expect that new feedback that will come from TypeTool 3 (which has simplified version of FLS MW) will let us improve it even more.

[watery dissolve]

The right hand is operating the arrow keys, or the bracket keys.

The left hand is operating the modifier keys, Shift, Option, Command and Control.

The hands never move, except to type a non-adjacent glyph (alphabetically), that you need displayed.

(In the last versions of fog3.5, when the glyph repertoire out-distanced the length of the keyboard and memory of the kerner, another keyboard command brought a window so you could type the desired glyph number.)

The arrows, unmodified, accomplish all movement of the cursor amongst the cells that represent either values or glyphs.

In glyph cells, cmmd - [ or ] go to next & previous glyph.

In the side bearing value cells, cmmd-arrow (left -, right +) change the width value by 1 unit (Cmmd Shift 10 unit change to the value.)

In the side bearing value cells, cmmd-option-shift arrow (L or R only), change the kerning value. (Cmmd option Shift arrow X10 change to kerning value.)

[watery resolve]

I'm pretty sure that's how it worked. Numbers were not typed, and there were not separate cells to cursor to to affect kerning vs. spacing. (If I didn't mention a key above, it wasn't used!)(I can't remember if or for what Control was used for, but it's far from the action anyway)

It's somewhat Ironic, it was so fast that I didn't need class kerning, remembering every value as if it was entered seconds ago ;)

The ideal, (90% of which exists!;)) would be to kern the first style manually and "like the wind", distill it purely numerically to classify and test the class kerning, and then, use and modify the class control kerning pairs as you design the next style of the family with kerning nearly complete.

We pretty much do this, I think most others do too, except for the "like the wind" part.

Also, I don't think anyone needs to increase their carbon footprint on account of this issue by running around kerning in public, but if that will help, I will gladly represent those who do kerning this way, have done it this way and would like to do so again, or don't do kerning this way but might be interested.

I will investigate recording a kerning vidoe. I thought about this a while ago, but a problem I see is to textually display the input of the keyboard (instead of video-o-fingers), to a recoding of the metrics window, and I'm not that kind of guy. Failing that, I will be making semi-decadic journeys to both Europe (TypeBerlin) and the West Coast (TypeCon) this year and if anyone approaches me armed with an old enough Mac, I will be armed with a new enough Victorinox data knife. :)

Cheers!

>Well, metrics table (and many other MW improvements) was first introduced in FLS5 so for this block of features this is really a 1.0 release.

Fair enough. But consider a brand-new, super-duper, four-dimensional relational database that doesn't . .
. . .

. . . .

let you tab from field to field.

Consider for that matter a webform, any webform in the world, that doesn't let you tab from field to field.

What would you do with it? You would close it. You would not give information to an organization that was so dodgy that they couldn't design a webform that let you tab from field to field.

Yet you expect users to put up with this in the software you write for them.

And while we're bashing beloved font programmers, Earth to Erik Blokland. Erik, have you fixed those errors in the code for the Robofab tutorials yet? Have you fixed that dodgy four-for-three code yet?

>Failing that, I will be making semi-decadic journeys to both Europe (TypeBerlin) and the West Coast (TypeCon) this year and if anyone approaches me armed with an old enough Mac, I will be armed with a new enough Victorinox data knife. :)

Well Yuri? Why wait? What's the matter with tomorrow? Offers like this don't come every day. And please let me not hear one more syllable about blogs, email, screen captures and videos (forsooth!) - - - - if David's videos are as good as his writing . . . . you see? You have to sit down with the guy. Here's your chance. Besides, Yuri - - - - you're not going to take it seriously unless it costs you something -- at least a plane ticket -- to get it. A couple of days. It might take awhile to establish how to COMMUNICATE together. David Berlow is not the greatest communicator in the world. But he is the one person in the world who can most help you to write better software.

Living in US you have no idea what it takes to make a trip there from here. Let me take a first step and try to implement some things and check if they are good. I've spent months getting FontStudio metrics UI into FLS, now I will spend some more time getting Fog35 there.

I have to take another look at FontStudio. You already long since put in the most important FS feature (thanks to Bill!), namely cursor control of handles, which is one of the best things about working in Flab. I don't remember liking the metrics window particularly, and consider this: there are two known people mad about FontStudio, L de Groot and C Twombly. A lot of other people consider the Fog interface a lot more important. Which is the one worth spending your time on? We do need more zoom, in spite of well-established methods for tricking Flab into zooming more than it wants.

I don't live in the US. See you in Brighton?

Important thing in learning from Fog35 metrics is also learning from Fog 4/5 metrics without ruining it all . . . . but in any case, the metrics table is a feature unique to Flab, and I think it is potentially great. Even with all this complaining, I can't think of doing first pass fitting without it, especially now that I have customized the strings.

Question: at what point size can you rely on screen accuracy with Flab metrics window, assuming a normal text PS font and key screen resolutions such as 1024x768, 1600x1200, 1600x1920, etc. That is to say, at what point size will a one or two or three unit cursor movement be accurately reflected onscreen, with pixel shifting artefacts cancelled out? An interesting resolution/anti-aliasing calculation . . . . .

OK, I improved navigation in the MW table. Tab and Shift-Tab scrolls cells horizontally and vertical arrows browse glyphs (without closing the editing field). I also added there Ctrl+Arrow increment/decrement of the value (without closing edit field) so panel and table behave the same.

What can I say? It works. It works much better than before. Thank you!

That's great. Keys in MTable should work same as in MPanel. Consider also that the in the panel, the cell identifying the key should also be active. One thing great is the way you can keyboard-select by half-spelling the character in MW. For example, d gets you d, da gets you dagger double, and dagger gets you dagger. Nice.

Now, let's get serious. About metrics. I'm starting fresh. I select sidebearings of 150, 150 for H. OK. Let me now press a button and have those values proliferate to I, left side of B, etc.

You can see where this is leading, and how much time it can save? Like, more time than any single font-building feature invented since 1989?

> I select sidebearings of 150, 150 for H. OK. Let me now
> press a button and have those values proliferate to I,
> left side of B, etc.

In the Classes panel, set up two metrics classes: one named ".H1" with the LSB scope activated, where H is the key glyph and I and B are dependent glyphs, and one named ".H2" with the RSB scope activated, where H is the key glyph and I is the dependent glyph. You can proliferate the values now using either the small button below the "H" glyph ("copy to...") or using the Metrics Assistance.

You can also go into the LSB field of "I" and type "=H".

A.

>You can also go into the LSB field of “I” and type “=H”.

In the current instance I am running, doing that will give you a value of 0, which is not the value of LSB. Obviously something is wrong -- maybe it's OK on Win?

Building classes thing sounds good -- would you recommend Mac or Win for this?

Can you do something like say RSB of n is 5% less than LSB of n?

> Can you do something like say RSB of n is 5% less than LSB of n?

Yes, with classes (which can be auto-generated) and Metrics assistant.

Although we have FL5 we have never used it for serious production work. We still use FL4.6 on both Mac and PC.

It is just not financially justified in the amount of time and resources it takes to make the change to 5 - compared to the increased benefits of running 5 over 4.6.

just my 5p's worth.

>You can also go into the LSB field of “I” and type “=H”.

> In the current instance I am running, doing that will
> give you a value of 0, which is not the value of LSB.

It does work in the Metrics panel (which is the horizontal Fontographer-like thing) but not in the Metrics table (which is the vertical FontStudio-like thing).

As Yuri pointed out, the Metrics/Kerning table is a 1.0 release in FontLab Studio 5, i.e. the very first implementation of this kind of work.

Please keep in mind that font technology has been a "running fox" in the past years. Digital image editing has followed virtually the same principles for decades, so Photoshop has been a mature application for years. The novelty of digital photography RAW image "development" has brought about brand-new 1.0 applications such as Aperture and Photoshop Lightroom. At Fontlab Ltd., we have not developed a brand-new application just for OpenType font production, but instead, we integrated many of the new concepts into FontLab Studio. So to some extent, FontLab Studio is a "5.0" application but in some regards, it's "1.0".

In fact, I consider FontLab Studio 5.0 the most important upgrade to the FontLab product since the switch from 2.5 to 3.0. While we did not revamp the UI completely in FontLab Studio 5, we have improved practically every single aspect of the application. I do realize that some people still use FontLab 4.6, but I must admit that I'm quite surprised with that. Especially since we release 5.0.2 a year ago -- an updated that fixed many important problems and bugs that were still there in 5.0.0 and 5.0.1.

I'm currently working on some ideas for better communicating with users and on improving the way feature suggestions and problem reports can be submitted. I will announce some solutions soon.

Regards,
Adam Twardoch
Product and Marketing Manager
Fontlab Ltd.

>>You can also go into the LSB field of “I” and type “=H”.

> In the current instance I am running, doing that will
> give you a value of 0, which is not the value of LSB.

It does work in the Metrics panel (which is the horizontal Fontographer-like thing) but not in the Metrics table (which is the vertical FontStudio-like thing). <

Not on the Mac it doesn't. You get zero.

> It does work in the Metrics panel (which is the horizontal Fontographer-like thing) but not in the Metrics table (which is the vertical FontStudio-like thing).

Another thing to fix.

Anyone else reading this will be terribly confused.

I forgot to write above my quote: it DOESN'T work (type in I for LSB) in the Mac version. Yuri, who is capable of reading thoughts amongst his other accomplishments (it's one of the great secret achievements of the Soviet science), realized what I meant, but others may not. I can't wait to try it out in Win -- but trust me, anyone who can't get 5.02 to be rock solid stable on the Mac has got something wrong with their system.

Yuri, here's another weird slight bug in the Metrics Table. If you are in Metrics mode, and switch to Kerning mode, and then switch back to Metrics mode, the sort order (Glyph) gets wrecked and can't be re-sorted. You have to close the entire metrics window and then re-open it. Observed so far only on Mac. All the more reason to be able to kern in the metrics mode panel . . . although I appreciate the logic of making the separation. Fog did too, because you could make kerning visible or invisible in the metrics window, though you could always see the values. Also irritating is that if you change from SB by guideline back and forth, you lose your place in the metrics table. Keeping focus in the metrics table is important, if it is going to be used at all, though there is of course the difficulty of balancing that against the metrics panel's needs.

"but trust me, anyone who can’t get 5.02 to be rock solid stable on the Mac has got something wrong with their system."

My what astounding confidence! Pretty amazing prediction coming from someone who has never seen my system. I would be curious what rigorous testing you did to come to this absolute conclusion?
I find it curious that the ONLY program that ever freezes on my system is FontLab 5.02.
The most common way the spinning beach ball from hell begins its endless path to the error message "FontLab is Not responding" is when I zoom in on a part of a glyph. It does not happen every time I do it but at least once a work session. I use the keyboard shortcut command and spacebar plus dragging a bounding box with the mouse around the area I wish to zoom to. This works just like the Adobe apps but they are much more stable. It goes to wongaland more often when zooming in the mask layer but it happened to me three times in a row in the glyph window just an hour ago.
ChrisL

Certainly that should never happen. It's too common an operation. Are you sure you're on the latest build of 5.02? What's your hardware setup and are you on OS 10.4.8? (I'm afraid to switch to 10.4.9.) Do you always run some other program at the same time? If all else fails, since it is so easy to have a separate partition or boot disk on Mac, why not try a completely fresh install of 10.4.8 with no additional programs? At the moment I'm using only a Ti-book 800 with only 512 MB RAM. I'm always simultaneously running at least Cog or iTunes, Unison, Safari, Font Explorer, Quark 7, and Fog OS X. If I try to run much more on this particular machine, it slows down. I would almost hazard a guess that there is a video driver problem. This might have been solved if you are on an earlier version of OS X. Why don't you contact me offline and let's see if we can't troubleshoot this.

A.T. -- I do realize that some people still use FontLab 4.6, but I must admit that I’m quite surprised with that. Especially since we release 5.0.2 a year ago

Wasn't there a recent post somewhere mentioning Freehand 9 and XPress 4? I.e. two to three versions before the current one, not just a 0.4 difference. (How many years have passed since these have been published?) Also, I know people who are happy with CS1 and have no plans to update to CS3. I don't think these are exceptions, it's reality.

Karsten

> ...the ONLY program that ever freezes on my system is FontLab 5.02.

True and true. FL and Force Quit are really really really good friends. The problem is/was with OS X 10.4, 10.4.7, 10.4.8, 10.4.9.

It's not possible to help with HW/SW problems if you don't give any HW/SW details. Checking for latest external peripheral drivers is important, too. For example, are you using a Wacom tablet and have you got the latest driver installed? (My rock solid FL 5.02 system works fine with 6.0.0-3.) Here's a small user group and some are having no problems at all and some hare having a lot. If we could identify a common thread amongst those who are having problems (like maybe it's the same video card or driver), then we could get somewhere. In a reasonably standard system, there are only so many things that can go wrong. The video system is one of them. Pointing devices and any other kind of peripheral need to be looked at too. Fontlab is too small a company for it to test on every likely Mac configuration, but I am certain this problem can be solved. If I didn't have pretty extensive personal experience with 5.02 and its stability, and know others who have had the same experience, I wouldn't be so sure that the problem must be relatively easily isolatable. As a first step I would go into System Profiler (from the Apple Menu/About This Mac/More Info/Save as/, save the info, and email it to Adam. If you were feeling really sadistic you could cc me, as I would be interested to have a look.

Here's another interface suggestion for the metrics window.

You open up the metrics window with a key combo. THE FIRST THING you want to do is to start typing a string!!!!

So you start typing. And nothing happens. Nothing at all. Here's a great example of a completely wasted opportunity. Focus should automatically go to the content bar or whatever it's called in the MW -- so that if you want to do something -- like type -- something actually happens. This is a perfect example of good interface design. You use a key to open something; You press some more keys and something else happens. It's simple, easy to grasp . . . . . that's the way it's all supposed to be . . . . . . . .

I am running the most current build of OS-X (10.4.9). My system is a 2 and a half year old G-5 Mac Dual processor desktop with 4 gigs of RAM. I have the standard mouse and keyboard--no Wacom or any other such devices. I never run any other program while working in FontLab. Occasionally, I have a small text editor open when using FontLab when I am writing Opentype features since the built-in text window in the FL5 opentype panel is run by voodoo. (I began using a Mac under system 2 before multitasking and got in the habit of quitting a program before opening a new one.)

ChrisL

There really shouldn't be a problem on a new system like that. Have you tried installing a new partition, absolutely clean install, with no additional programs other than Fontlab? If your stability problems then went away, you would know there was some kind of conflict with some other installed software. If they didn't go away, you would I think be safe in deducing there was a hardware problem. I _have_ had problems in the past. There is something one can do on relatively simple system that conflicts with Fontlab. Whatever it is, I'm not doing it now. I don't even have Acrobat installed on this system. I'm really curious about this.

There really shouldn't be a problem on a new system like that. Have you tried installing a new partition, absolutely clean install, with no additional programs other than Fontlab? If your stability problems then went away, you would know there was some kind of conflict with some other installed software. If they didn't go away, you would I think be safe in deducing there was a hardware problem. I _have_ had problems in the past. There is something one can do on relatively simple system that conflicts with Fontlab. Whatever it is, I'm not doing it now. I don't even have Acrobat installed on this system. I'm really curious about this.

Another interface suggestion: MULTIPLE BACKGROUND/MASK LAYERS. Like 1 through 9. This could be tremendously useful -- I would love to have it right now. And of course, undo/redo that is layer-specific. And being able to perform transformations whether the mask content is bezier or pixel flavoured.

I use the keyboard shortcut command and spacebar plus dragging a bounding box with the mouse around the area I wish to zoom to.

I never have that problem.
However, I don't use keyboard shortcuts with the zoom tool.
I'm running FL5 on an Intel Mac.

The only time FL5 has frozen on me is when I dragged a zoom marquee box around a referenced path, so I always just click to select those.

@ChrisL:

In case you had your Mac update itself (eg automatically), or you used the incremental Updater that's on Apple's site — download the Combo Updater (MacOSXUpdCombo10.4.9PPC.dmg) from Apple's site and run that. The Combo updater is more reliable.

I am finding the @ symbol in the preview window extremely convenient (=time saving). It works--substituting the selected character--not only when you select a glyph in the metrics window, but also in the glyph window. That means with the @ symbol in a control string, the character you are working on drawing or re-drawing automatically jumps into the control string in the preview window. That is very convenient also. Please document in the Manual!

While I am at it, here is a bug: with a character selected in the metrics window, on a PC if I move the left side bearing with the arrow keys + ctrl, then I can switch to the right sidebearing and continuing working with the arrow keys + ctrl & alt. But if I work on the right sidebearing first, then the left sidebearing is frozen, and to activate it I have to click on the character again.

"...FL5 has frozen on me is when I dragged a zoom marquee box around a referenced path,"

Perhaps the 2 problems are related since they both involve the marquee box?

ChrisL

Thanks Bert! I will give it a try.

ChrisL

> Wasn’t there a recent post somewhere mentioning Freehand 9
> and XPress 4? (...) I know people who are happy with CS1
> and have no plans to update to CS3. I don’t think these
> are exceptions, it’s reality.

That's true. But I also know that financial reasons are one of significant factors in such case. Upgrading the Creative Suite or QuarkXPress -- especially if you also own some plugins or extensions -- usually means spending many hundreds or several thousands of dollars. Going from FontLab 4.6 to Studio 5 is US$99, which I think is an excellent price for the value of what you get.

However, since I use FontLab Studio 5 very very often, and I have considerably contributed to the new version, I obviously like the outcome. Perhaps the objective advantage of 5 vs. 4.6 is not that huge, though I still think it's significant and definitely worth the upgrade price.

Simply speaking, many of the problems that 4.6 users have simply go away in 5.

A.

FL5 is way better than 4.6 and worth the $99. Let's hope there continues to be improvement in the near future.

ChrisL

For some reason, the thread on Carol Twombly now contains some discussion which should have been included here. The major point I want to make is that the Flab implementation of cursor controllable handles a la Studio is half-hearted. The glory of studio is that you can tab from control point to node to control point to control point on NEXT node, to NEXT node, to second control on point on NEXT node, and so on. You can keep on going, so long as the points are selected. This is one of the greatest bits of aesthetic fine tuning a computer program has ever offered. Flab should do it this way. Any reason why not, Yuri?

Combination of PgUp-PgDn and Tab is not enough for node-handle navigation?

"Combination of PgUp-PgDn and Tab is not enough for node-handle navigation"

I didn't know about that one! Someone really needs to write a book called "Really Cool Shît You Didn't Know About FontLab"

ChrisL

>Someone really needs to write a book

Yeah, it's known as the manual, which is the most serious weakness of the FontLab program. And yes, the manual is an integral part of the program.

It's weaknesses include:

1. Missing documentation, such as the fact that if you shift, then click and hold on a curve it will control move the handles, but not the nodes--mentioned in another thread--and other things mentioned above and elsewhere.

2. Things documented, inventory style, but *not* put into the context of a work process. This includes the 'PgUp - PgDn and Tab' controls just mentioned by Yuri. It is in the manual, but not in an accessible way--hence neither Chris nor I nor I would guess most others know about it. --I did know about the page up page down, but not the tab control.

Sure it's good enough. But when is good enough, good enough? It's three keys to do what FontStudio does with one.

Let's look at it more closely. Let's look at the hand movements.

With Studio, everything is accomplished with the tab key in the left hand and the cursor arrows in the right hand. No need to move. No need to think about what you're doing. Your eye/brain is in complete control. It is a seamless, thrilling, creative experience.

Now let's look at FontLab with the extra keys.

You may easily be working on a keyboard where PgUp/PgDn is physically distant from the arrow keys. You may be on a Mac laptop where you have to press FN to get PgUp/PgDn. You may be on a Dell where the arrow keys are at the bottom of the keyboard and the Pg keys are at the top.

The two extra (and quite unnecessary) keys you are asking for create a lot of extra hunting and pecking, even for touch typists.

So no, it isn't good enough. The goal should always be that you are looking for ways to make things the MOST simple, the LEAST intrusive.

Why use three keys when you can use one?

Why create extra movements (from arrow keys to Page/Up/Dn keys) when you don't have to?

What makes the Studio experience great is that you can contemplate the glyph and perfect it and NOTHING gets in your creative way.

That said, it is a good thing in FontLab to have keys that navigate from point to point. I'm not convinced those should necessarily be Pg/Up/Dn because it might also be nice to have those for moving the glyph or metrics window up and down. Maybe Pg/Up/Dn really should be allowed to do just that.

Nevertheless, here is the compromise I would propose, combining the best parts of FontLab and FontStudio:

Leave Pg/Up/Dn as point navigation tools. Simply change (perhaps by a live option -- not a preference) the way Tab works. Instead of Tab confining you to one point (if you want to go back, you have Shift-Tab anyway), let Tab get you from handle, to node, to handle, to next node, like Studio does.

Now you have the best of both worlds, and you have improved upon the Studio experience, because Studio will only let you dance from node to node if they are all selected.

DOES FLAB HAVE A SLOWDOWN KEY?

In Fog, there's a key, I forget which, perhaps control, perhaps option, whatever, that slows down movement in metrics and glyph windows, allowing you to have much finer cursor control. With Flab, I am always running out of precision. I want to drag a handle in the metrics window by five units, but the minimum change is ten -- for example. Is there a key that I can press that will stretch this all out as I can in Fog?

In addition to multiple background layers, have you thought about different right and left points for the measuring line, not to mention right and left anchor points in glyphs for the measuring line? Not to mention measuring lines that are unique on a glyph by glyph basis, rather than being global?

Tab key and PgUp-PgDn are separated because node and handles are different things. It is much easier to adjust handles with single Tab key than to break your fingers with Shift-Tab. But you are right, there could be an option which extends Tab over all available handles and nodes.

There is no "slowdown key" in FLS. There is "live zoom" which I think is much more useful. While you are dragging node (or anything else) you can very quickly zoom in and zoom out with Z and X keys. You don't have to release mouse button.

We had "slow key" in FL 2.5 but I always had a problem with that feature (same in Fog): it is not really easy to move mouse in slow mode to position the point as you want it. Live zoom works much better for me. When mouse is not pressed - Alt-wheel works as zoom tool.

However, slow key is good in metrics window, I will try to find a way to integrate it.

"You don’t have to release mouse button."
...is there a keystroke for locking and unlocking the glyph window so the other shortcuts become possible without going to the lock?

"PgUp - PgDn and Tab’ controls just mentioned by Yuri"
Lefties rule! but really who's this for? if you're in the glyph window, on the little buggers outline, who needs to tab through the points and for what? fog's point info panel let one change all sort of things about a point from a dialog box. So tabbing through the points and changing things was useful in some old way that was fully kbd-based but I've forgottten. Does FL have such a dialog box for points?

"FontLab 4.6 to Studio 5 is US$99"
Are there any first-class ugrades available for this flight? I'd go as high as $299 for my own private hybrid FLOG Classic! ;)

> Does FL have such a dialog box for points?

Edit / Properties.

A.

Adam, I must say I find that Flab property box rather confusing compared to Fog's, which is pretty straightforward. What advice would you give someone trying to bridge the gap? David, FontStudio is obviously too primitive to have appealed much to you even in its infancy, but I do think the tab-dance through handles/points is a really elegant modus operandi. I can see why designers as disparate as Twombley and de Groot like it so much. I am more and more frustrated by the separation of kerning and metrics in Flab. I'm doing metrics. I see a problem, I want to do a kern. Now I have to switch to kerning mode, an annoying hunt and peck with mouse move. Now I have to switch back to metrics. But whoa, the switch, in the Mac version, means that the metrics table is in no sort of order, and can't be re-ordered -- and there are now all kinds of problems with the arrow/opt shortcuts. The only cure is to close the current metrics/kerning window and open a new one. Lots of time lost there, and much fraying of temper. Although I can see some philosophical justification for separating the two operations, there now appears to me no practical benefit; the separation only seems to make things worse. Even if the bug with the re-sorted metrics table were fixed, it would still be tedious to keep on switching back and forth. The operations in reality are not separable. David, what's your position on this?

OK, here's my first crash in 5.02 within Mac within recent memory. Open four-master font, open metrics window, switch to kerning mode. Open the metrics table -- called the kerning table? Delete some pairs that only have 0 values by highlighting and pressing delete key. Sure to crash.

Yuri, another problem with metrics/kerning tables is that you can't select a group of values to delete. Obviously, the table should be fully editable.

So: is there ANY method in the metrics view to view kerning?

"> Does FL have such a dialog box for points?

>Edit / Properties.

Ahh...but a. it doesn't seem to know what properties are important (to a type designer), or b. whatever in the world to do with TT point properties?

Fog once again provides a perfect model that should be looked at.
Fog allows: adjustment of coordinates, flipping point to on-off curve, start-point definition, and point type definition. Catch up! (or tell me what I'm missing in this undocumented little buttons that seem to do nothing.

From the "Did you know?" departamenté: FL allows a glyph to be 1/2 TT and half T1 at the same time! (this makes it 1/2 as hard to convert to one format or aother, I s'pose ;)

"I’m doing metrics. I see a problem, I want to do a kern."

I don't work this way, usually, so I don't share your passion for a single kern/metrics view. I actually like having the operations separated so I don't accidentally destroy a width instead of add a kerning pair. I recall that with FOG, I had to be careful to avoid that pitfall.

While it doesn't solve the overall problem, there is another way you could get around this: It's possible to have 2 metrics/kerning windows open at once. Leave them both open. One can be in kerning mode and the other can be in metrics mode. Switch back and forth between windows and nothing is lost.

"Switch back and forth between windows and nothing is lost."

I like that idea, Carl.

ChrisL

I don't! Nothing is lost except my sanity and my focus. There's a little checkbox in the Fog metrics window. Show kerning. Don't show it. Way to go. I should not be having to look at two windows. Besides, there is never enough screen real estate anyway. I want a metrics window to be as big as possible -- preferably filling one of the at least two monitors I always use. I don't want that screen real estate being completely wasted by an unnecessary window. Not only do I have to switch back and forth visually, but there is the matter of all the additional mouse/pointer movements that entails. Good software is about minimizing effort. How do I minimize how long it takes to get from a to b. Period. Nevertheless, Carl, I am grateful for the suggestion. I was too annoyed for it to occur to me. It's not ideal but it is a workaround.

I also take your point about inadvertently making a kern instead of changing a width in Fog, but since you must be in the kern cell to do that, it doesn't seem to me to be that easy. It is always possible to do unintended things in a metrics window. I do it all the time in Flab, and rather more so than I used to in Fog, it seems to me, because of the unintuitive way it works. For example, you have left sidebearing and you have right sidebearing. You have, to the left of the spacebar on a Mac keyboard, the command key, and to the left of that, the option key. So you've got this little pair of keys, in a row, that control your right and left sidebearings. Common sense, everything that man has learned since the invention of the wheel, dictates that the leftmost of these keys, option, will control left sidebearing, and that the rightmost of these keys, command, will control right sidebearing.

Where does FontLab get off reversing this natural order?

I think I'll go a little further. Though I really do like the Flab paradigm of letting you change sidebearings without being in the cell (the way Fog demands) it is just because of that I think it is easier to make an inadvertent mistake in Flab, especially because the natural order of left and right is inexplicably reversed.

Needless to say, this indignant argument only applies if you are using a Powerbook keyboard that doesn't mirror the option and command keys each side of the keyboard. On a full keyboard, you could use the right hand side of the keyboard. But that still isn't intuitive. You should be using the left hand to control whether right or left sidebearing, and the right hand, on the arrow keys, to control the amount. Let cmd-opt together control kerning (since we want to reserve the control key for slow-down). David has pointed out how adept Fog is at utilizing your right and left hands and getting them to work together.

All of this said, it seems to me I must have forgotten some Fog shortcut for adjusting metrics values -- what have I missed?

David, I'm very glad to hear your comment on the Flab properties box. I was too embarrassed (if you can believe that) to ask the same question. Fog properties are a great model. Being able to switch point type is great/set startpoint, etc. -- everything is great about it.

Would someone from Fontlab care to explain how the point property box works and how it relates to Fog's?

(they must be looking in the manual)

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 . . . .'

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:

'neighbours'
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.

Neighbors is useful when making connecting scripts.

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.

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.

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.

Regards,
Adam

"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.

"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.

Bill,

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.

A.

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?

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.

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.

Bill,

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.

Regards,
Adam

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.

>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.

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?

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.

>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.

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?

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.