1. Glyph marker is available by right clicking on a glyph, and selecting 'Mark'. You can also add notes to glyphs via the same way, by choosing 'Add note'.
Or when you have the Glyph Properties window open for a glyph, there is this little yellowish field where you can type in the notes.

2. I believe that is possible as well, probably via the mask. But I don't know too much about that, so maybe someone else can elaborate.

When you want to make a bold from say a regular weight, you can copy the file and rename it and the style.--then you can copy all to mask layer and have the normal weight in the background while you work on the bold.

ChrisL

Chris,

it's possible to do much faster: open your Regular and Bold styles, in the Bold font choose Tools / Mask / Assign Font Mask, and there select the Regular style. All Regular glyphs will be copied into the Bold's mask.

A.

Nice, thanks all. I couldn't find any of these things in the Learn FontLab fast book. I next need an OpenType Programming for Dummies book or tutorial. :)

Thanks Adam, That is slick!

ChrisL

> Nice, thanks all. I couldn’t find any of these
> things in the Learn FontLab fast book.

Because they're not part of the "fast track". They're part of the "slow, more thorough track", which is the official FontLab Studio 5 manual. I recommend reading it, even though it's 900 pages thick. Remember that you can buy a bound printed copy at http://www.fontlab.com/printedmanuals/

Regards,
Adam

even though it’s 900 pages thick

And there lies the problem. ;)

>> even though it’s 900 pages thick
> And there lies the problem. ;)

An average typeface family takes weeks or even months to develop. I think reading the FontLab Studio manual takes a fraction of this time. Plus, the layout is actually quite generous, so it's probably a faster read than "Anna Karenina", though perhaps without the literary sensations of Tolstoy.

A.

The plot is more complicated than Tolstoy's though :-)

ChrisL

I envy folks who can develop a type family in just weeks or months....

>I envy folks who can develop a type family in just weeks or months….

Me too.

>I think reading the FontLab Studio manual takes a fraction of this time.

I don't know about others, but to me the FontLab Studio manual is about as readable as the dictionary. It is an index of functions, rather than an instruction manual. Like the dictionary it is invaluable as a reference work, but unreadable continuously.
'Learn FontLab Fast' is a good readable instruction manual, but it is only a start. If the FontLab manual had some pieces organized by *task* rather than just by function, it would become more readable and hugely cut down on the learning curve for those using the program.

Also, I hope that in the next round of the manual, FontLab will take advantage of the task-oriented work done. Eg. Ben Kiel's list of keyboard short-cuts (and please expand it!) and Karsten Luecke's recent takes on font naming, vertical metrics, John Hudson's tutorial on using the interpolation and other things in the Typowiki, and Adam, your own many extended and useful answers on Typophile and other places.

In effect these efforts amount to pieces of an instruction manual that doesn't yet exist. Even if it is uneconomical to produce such a work, piecing together what is already out there would be quite helpful. Maybe a FontLab wiki?

ps. the example you just gave illustrates what I am talking about. "How can I use the 'mask' function to help me in developing my font?" is a question you and others would have very good answers to, but they aren't written down in one place that anyone can access.

> “How can I use the ‘mask’ function to help
> me in developing my font?”

William,

I know very well what you mean, and I think we're moving towards that, slowly. We're currently restructuring the way our manuals are being produced so that we can prepare these manuals more thoroughly and focus more on the functional aspect.

Regards,
Adam

Bill, my wife bought a copy of Learn FonLab Fast. As it turned out, the first place I looked, the author was remarking about the general uselessness of "old style figures" in these modern times. As I shut the book I wondered if using the term "lower-case figures" would have helped the author understand why some of us still use them. Some languages just don't relate well to one another. I'm reminded of a friend who claimed he spoke fluent American and passable English -- I don't speak even passable "programmer."

Best,

Charles

He may have been joking?

ChrisL

Chris, I don't think he was joking, even though the book has lot of jokes, which makes is more fun to read. But I just put it down as a blind spot in an otherwise good book.

Charles, in spite of this to me shocking blind spot about text figures--and I put it down to Cabarga being primarily a display type guy--the book does explain some of FontLab's capabilities in a task-oriented, functional way, even though it is just a start.

Adam, thanks for your gracious reply. I do understand that it is a big job to explain how to use FontLab Studio's capacities in the work process of the type designer. I'm happy that that it's part of Font Lab's goals to strengthen the manual.

Bill, I really do think it is a matter of language. Couple of examples -- my business partner is, among other fine attributes, a pretty good programmer. He decided to write the last TeX macros using what he called an "object-attribute" structure. "\textpage" was an object. "orientation="x" was an attribute. ???? says I. He offered the following analogy "This is a face. It is an object. It has certain attributes, nose, eyes, hair, etc." "Look," I say. "This is a body. It is an object. It has certain attributes, one of which is a face." The point is that you can't look for meaning in the words borrowed from plain English; Adobe's using "Frame" for InDesign doesn't help me a bit. The meaning of the terms comes from the acceptance of other users, in this case, other programmers. Their (and our) mistake is to assume that people outside the group know what they mean.

And within typography itself -- I don't like the term "text figures." I know what you mean, I think, but what figure style is used in display and text depends on the context. If your heads, either chapter or subhead, are full caps, you should use lining (capital) figures. If they are Cap & lower case (a cap on each significant word, the rest of the letters lower-case, you have a choice. If initial cap only(the first letter of the first word is all that is capped, old-style (lower case) figures should be used. And in the body copy (text), words like "B-17" should be set full cap, lining figure. Also, I think, references to newspaper sections, such as "C-1." You can set them small-cap/lower case figures, but that strikes me as an affectation.

To call them "text figures" falls into the same opacity of language as the problem of standard terms borrowed by programmers. Those of us who know what's involved have no problem; doesn't matter what we agree to call them (old-style figures, text figures, whatever). To an outsider, the term "lower case" might be more helpful. And of course, it might not.

Charles, it has always bothered me that there is no good standard term for 'Old Style figures'--I don't like that term because it makes them seem antique, rather than something currently useful, which is what they are. Your term 'lower case figures' I like best for reasons you explain, and I will use it in future. It would be great if Adobe and others would use it in their applications.

I don't understand your point in your first paragraph. Are you saying that 'Learn FontLab Fast' is written in programmer jargon or style? To me it is exceptionally accessible compared to most manuals.

I think the language used should be focused on the most likely user. There are some programmers designing type, true, but there are many more with a typography, publishing, and graphic design background. The terms common to these fields seem to be the best to use in manuals and interface. Terms like oldstyle figures are well known to the typography community. The difficulty comes with the young beginner with no background. Whatever terms used will be new and perhaps strange to them. The term leading is a good example. Anyone with a history in typesetting or design is quite familiar with the term. To the "FNG" (@!#%* New Guy) it makes no sense. We then have to mix in modern-day terms like typolinegap, winascent, etc., and the party really begins. The current state of affairs is that we are in the middle of a conglomeration of old farts like me (who have hand set metal type and drawn letters with a brush) and the younger computer generation who are pixel and hinting savvy with a splash of programming to boot. We are as a group a hodgepodge of the visually literate, the techno savvy, and the practiced craftsman of prior media.

ChrisL

Charles,

some people already use the term "lowercase figures", e.g. John D. Berry (http://www.creativepro.com/story/feature/17560.html ), also Erik Spiekermann. I support this view. Lowercase figures and uppercase figures instantly tells you in which context these figures should be used.

In the threads about small-caps figures and stylistic sets I’ve been advocating for a more consequent "linking" of figure cases to letter cases.

A.

A.

Bill, the term "lower case " & "upper case" was coined, far as I know, by Paul Rand, not me.

As to the first paragraph, no, I'm not criticizing LFF, rather pointing out some inherent problems in any such endevour, and that a really GOOD manual, for users who are not engineers, needs to pay attention to this.

Or perhaps the question becomes, who is going to supply fonts in the future? People with a strong programming background? People with a strong design (not engineering design) background? Only a special few who have both? If the latter, there are far too few; we would lose the likes of Matthew Carter. To the extent that FontLab is a tool, writing the manual for it's use has to depend on assumptions about who you feel will use that tool. But that's easy to say; I agree that writing such a manual is a difficult task. I mention it only as something for Adam to think about.

I don't have the book in front of me to know whether it was a joke or not. Could you write the sentences "exactly" as they appear Charles?

I'm inclined to think its a joke, particular when the book has a vector art illustration of a silhouetted boob.

I'm trying to program OpenType features and I find the most difficult thing to understand in the book is that section. (BTW, the entire example in the book is about old style figures.)

I'm not a programmer, and I've got some more specific substitutions I need to do. Is there a serious tutorial somewhere about how to program OpenType features? It sure ain't easy for some of us to understand.

who is going to supply fonts in the future? People with a strong programming background? People with a strong design (not engineering design) background? Only a special few who have both?

Fontographer was way ahead of the curve, providing "user generated content" 20 years before the adbiz caught on.

But since then all design software has become way more complex and technical.
It's not just the manual, but the software and interface.
You get more features and customizability with FL than Fog, but the downside is the shift from art towards engineering (relatively speaking, of course).

So like has happened many times before in design, as technologies evolve, the creativity moves from being embedded in the craft to being split into two functions - direction and production. And then more.

The evolution of markets has something to do with this too -- in our (indie type designers) case from Mac-using graphic designers to multiple-platform corporations that require complex fonts that are vastly more complex and robust.

Terry -- it takes a lot of effort and trial and error, but that's design, ennit?
It's not quite the same "learning of an instrument" as, say, a calligraphy pen or a piano, but as Adam would say, you want easy or good? (or words to that effect).

Getting familiar with OT features is certainly worth th effort, because it is really the only fundamental design ability that OT adds to type design, and it is really quite singular, i.e. it's all substitution.

Well...I'm trying to figure out multiple key stroke substitution.

Like: yum=gravy...how do you do that?

sub y...?

Hello Mr Biddle,

apart from the little OT introduction in the FLS5 manual, I think the single best document for understanding OT features is Adobe's Feature File Syntax Definition document. (There may be some typos near the end which obscure some things*, and one or two outdated examples; also it looks quite complicated at first; but then, it gives all information you will need.)

* You may not set these values by OT feature code, but e.g. in the example for section "9.f. OS/2 table", the value for winDescent should be positive not negative (else your font may crash Windows), while in "9.d. hhea table", Descender should have a negative value.  :)

Karsten

"I don’t know about others, but to me the FontLab Studio manual is about as readable as the dictionary."

:o that good? You've read the dictionary, or are you talking about that great book once called, "a long poem about everything."

How Do You make all but the mask disappear in the glyph window? (answer to follow if no one else gets it). You can't write a manual for a program that requires such a level of ecclecticity of its users. The relative of this problem is that I can't teach type design with this program either because of what it exposes you to explain.

Go ahead, I dare you, write a better manual and then teach with it without dozens of "bug-n-hu!?" fixes to the program. Or, fix the program first...hmmmm.

Hmmm. You posted it twice, but I still don't understand it :)

What does "You can't write a manual for a program that requires such a level of ecclecticity" mean?

biddy,

No, Learn Font Lab Fast is my wife's book & she has it at work. Like most sensible couples, we try to keep our work addresses separate, even though we're more or less in the same field.

But a tip on understanding features generally & the old-style-lining substitution: Take a "professional" font like Adobe Minion & read it into FontLab. Open up the OpenType" features pannel, & using the tool there, write the features off to a separate file & study it. I think everything will begin to click.

One of the problems I have with FontLab is that I write the features in a text editor (V-Edit) & then bring them in. FontLab keeps telling me I now have new kerning & don't I want to update. What is really going on is the kerning I added in the external file isn't in FL. If I "update," I lose what I just wrote. We all pay for our afflictions, but I sure like writing code in a nice big window, in large type, and with the text handling features of V-Edit.

BTW, you get a new problem if a font has small-cap-height lining figures. I've been known to put them in a "stylisitc set" to preserve the integrity of "lining" figures.

Karsten, many thanks...I'll be putting that to good use tonight.

Charles, I wasn't talking specifically about old style figures. More like image substitution. I'll take a look at the book tonight and see if I can find the passage.

With AFDKO and FLS5 you can substitute more glyphs by fewer glyphs, but not the other way round. E.g. you can do this:

sub m' a' n y by f;
sub f n' y by e;
sub f e y' by w;

The glyphs followed by quote will be substituted by the glyph after the "by", the others serve as context. You have to step through glyphs and substitute them one by one -- and with each line the word transforms a bit more. In the first line, I did a ligature substitution, two glyphs by one.

I think substituting fewer glyphs by more is possible with TT-OpenType fonts in Volt.
One could smuggle this kind of substitution into a PS-OpenType font with TTX, but unfortunately it would not work in Adobe apps, so better don't do it.

[But I should say that this is a bad example since features better do not changes the character code.]

"What does “You can’t write a manual for a program that requires such a level of ecclecticity” mean?"

Well, in the example I gave, and there are dozens like this Bill (in FL Studio 5), you have something attached to the glyph window called "Editing Layers" (a nouned panel). It has the name of each layer and a check box beside it. The name is picked when the designer want to make that layer active for editing and the check box is to make that layer visable or invisible (or at least that's the way some of it works, and I assume it's all s'posed to). Sounds simple enough until you try to use it: Then, if, e.g. you just want to see the "mask" you think you'd just uncheck the layers other than the mask, and you'd be done. But that does not happen, instead The only way I've found to see only the mask is to select the mask and then UN-check the mask checkbox. This makes all else disappear, (somethymes). But most assuredly, the outline will will not dissappear if you are on the mask layer and you uncheck the "outline".

Teach that, and you'll be a fool. Document it and you'd be fool in writing. I have to choose neither fortunately.

I get exactly the same effect that David speaks about above when using the layers palette. There are other weird things like the occasional “one-move click auto-deselect” in the mask layer. Here is what I mean. In the glyph layer, you can use the arrow keys to move bezier control handle in single units by tapping on the arrow key until the curve is as you like it. With each tap, the control handle stays selected. Try this in the mask layer though and you don't know what will happen. Sometimes it stays selected and sometimes not. You have to click to select, hit the arrow key, then reselect because it has deselected itself for no apparent reason and not even consistently. If you quit FL5 and then reopen the file, it may work fine for a while--until the voodoo needle strikes the mask layer again. There are plenty of mysterious quirks in FL, weirdest app I ever saw! Somehow, you learn to deal with the flakiness because it is the only tool that despite its goofiness, will do the job.
Another example,in the OpenType panel, when typing feature code, the curser is never where you think it is. There seems to be added spaces or you can't select what text you want without "guessing" where the text might be. I end up typing all my feature code in a separate text editor and then pasting it into the feature window to avoid the "Where's Waldo" game in the FL feature window.

All of this said, it is like talking to your whacky uncle Yannis who is a little nuts but very smart and knows how to help you in the end. You put up with the eccentric flake-outs because in the end, it is worth it (and he is family).

ChrisL

Ah, I see what you mean now. I'd probably call this 'eccentricity', but it's more complicated than that. I think there are at least two things going on:

A. "Holy documentation, Batman!"

I was talking to a guy who has done programming about my frustrations in learning FontLab, and he said that documentation is an extremely important part of the software development process. I've got to say, I think this part of the process at FontLab could be improved, because there are holes in the documentation.

For example, the manual says that in the metrics window if you chose a glyph and want to adjust its left side bearing only, one way is to hold down the control key (windows) and use the right and left arrow keys to move one unit at a time. Ok, good. What about the right side bearing? Nothing. So who designs a font only adjusting the left side bearing, not the right? Um, a little eccentric.

So having spent time with this program, I know the functionality must be there and I'm supposed to play detective. So I start trying combinations, and sure enough, if you hold down control-alt (windows), then the right and left arrow keys will move the right side bearing only. Not in the manual, not even in Ben Kiel's nice summary sheet. Does it also work the same way on the Mac? Well, maybe, you will have to do the detective work.

David describes a similar adventure concerning how to see the mask only.

These adventures can be fun, if you dig that sort of thing, but when you are going on these adventures you are not designing a font.

B. The Mind of Man

My friend the cognitive scientist tells me that the latest theory on the way the brain works in storing memories is basically by scenario: come up to the door, turn the knob, open the door, etc.

So that's the way to explain something in an instruction manual also, so human beings will understand you: take a task that the user wants to do, and explain to him or her the scenario for doing it. For example that's the way Cabarga does it in 'Learn FontLab Fast'. So he has chapters on starting a font, drawing a font, spacing a font, etc. Task-oriented.

Because the FontLab manual is not task-oriented it is not a manual, but an index of functions--and there are holes in the documentation as well.

The result is to make it far more difficult than it could be to learn FontLab. For example, Adam, who probably knows more about the program than anybody except the programmers, said that the diagram and explanation on p. 50-51 of 'Learn FontLab Fast' came as a revelation to him: there was everything in one place on how to draw a line in FontLab.

Ladies and Gentlemen of the jury, I rest my case.

How to improve it? Since different designers likely have different work processes, particularly at an advanced level, doing the whole FontLab manual organized by task is going to be maybe too huge a job, given the size of the market and the production team.

What is easier to do is I think answer the type of question I hit on above, based the existing index of functions known as the 'manual': What are the different ways the designer can use this function in designing a typeface? Hence you have question of how to use masks, sidebearing functionality, etc. etc. etc.

As I said, users have already started writing this manual. John Hudson's tutorials (in the typowiki) on using the interpolation tool for bolds and small caps are a good example.

I'm sure task-oriented documentation will always be a work-progress, but any increase in task-oriented explanations (and filled holes in documentation) in the next edition of the manual will I'm sure be gratefully received by users of FontLab.

David,

I already once submitted the feature request to our engineers that the outline layer should be "hide-able" just like any other one. I take your voice as a reason to re-submit that request. I myself find the current behavior illogical. If you find more of such illogical points, keep 'em coming. I humbly hope that these issues don't disqualify FL Studio in its entirety as a useful application.

A.

"the outline layer should be “hide-able” just like any other one. "

It is in it's own ecclectic way. From the outline layer turn off the Mask. Then, make the mask layer the active layer, and "poof" the outline dissappearrs.(that's what I meant to say before). When I first started using FL, I though I'd accidentally deleted the outline, it's box being checked, but my letta' been done disappear'd. But, now, I just go with the flow :) the checks mean something, the layers mean something, and you just have to figure it out. (that's what I'd say in the manual too.)

If you're going to ask them to revisit this, that'd be great thanks Adam. I pine, you can tell them, for the days when this was so simple (the activity and visiblilty of layers), that it was a keyboard function, allowing one to keep one's mouse on the ball.;)

David, you can keep your mouse wherever you want— but um...couldn't you have kept that little tidbit to yourself? :)

I would, but it's actually the most important thing — having mousey run around all day doing things other than shapey curvey is the largest single class of negative difference between this and tools dating back to places few have ever seen. De rodent is yo only finger, thumb, hand, wrist and executor of your eyes' estate when it comes to letter-forming, a complete-enough-seeming task-set to me. To have it also running back and forth fetching tools, layer states and poking "yes" in case FL forgot to activate the CR for the highlighted option, is pure unadulterated consciousness raising, to say the least.

You might not think about it, but every time I'm deep in the midst of an outline glyph, and all it's dependencies, and their's, and their's, all the way to "the Cleint's" dependencies, and then allofasudden, I've got to shoo the little rat out to Long Island City for a part... it has a tendency to disturb the dependency threads and decision speeds. Not by much, but when there's a lotta glyphs and a lot trips to LIC, (for me, at least), it's worth pointing out. As I said up thread, the problem does not exist so much for users with prior letter forming experience to find the least disturbing path regardless of how eclectic, but trying to teach or document, under the circumstances, can be an extra-trying experience.

Biddy, has other opinions, but that is obviously based on his own concepts of mice and men.-)