Actually in a way using more points gives you less control, but of course it allows you to make more complex shapes. Another advantage to fewer points is smaller font files.

There's no actual number to shoot for of course (except technical maximums, which are however very high) but use as few as you can as long as you're not -visibly- compromising the shape simply to have fewer points. An exception: you need points at extrema and inflection points for technical reasons. Also, once in a blue moon it might make sense to sacrifice the shape:sometimes for point economy, sometimes because there's not enough resolution anyway (especially if you have to stick to an Em of 1000, especially if you're making an Italic).

Another thing to consider is BCPs: I myself am often tempted to omit a BCP on one side of a curve if the shape looks good enough, but for technical reasons such "half-dead" curves are bad news.

hhp

Another advantage to fewer points is smaller font files.

Does any one actually bother about that?

Does any one actually bother about that?

Some people care a great deal about it...

http://processingjs.nihongoresources.com/the_smallest_font/

Also, when delivering web fonts it can make a significant difference and very sophisticated subsetting technology is often employed when delivering large non-Latin fonts so that calls are only made for the required characters rather than the whole font.

extrema points were deemed unnecessary, due to the small scale of the detail. Sumner Stone was with Adobe at the time this face was developed.

We have had this conversation before: Adobe Postscript specs strongly encourage extrema for reliable rendering.

The Adobe Spec for Type 1 fonts specifically makes an exception for very small curves. Here is the last sentence on p. 29 of the spec: "It is not necessary to place an endpoint at extremes of very small curves such as the tips of curved serifs."

Personally, I think that there are more exceptions than this, especially in italic fonts. I'd be interested in what others' experience is with italics.

Also Going through some typefaces, I found out that some people join the bezier handles. What is the reason behind this? And also I noticed in SBL Hebrew, designed by John Hudson, all open handles of all BCPs are joined to each other. and sometimes this joining touches the curve and manipulates it even though the point it touches has no BCP there(please find the image). What is happening here? Is this just a personal workflow thing? I asked John about this but I also want to know what you guys think.

I'm not sure but I think you might be talking about quadratic (TT flavor) béziers, which have one BCP for each curve. Cubic béziers (PS style) have the "traditional" two BCPs per curve.

hhp

all open handles of all BCPs are joined to each other

Yeah: it’s rather important if you want to generate a closed shape…

I hope I'm not hijacking the thread too much, but while we're on the subject of BCPs, how many and such, I saw hrant added a point on adding them at extremes and inflection points.

May I ask how, why, what does it do and what is defined as an extreme?

From what I know extreme points are those points where the curve doesn't change its direction but still needed to fine tune the curve. Eg: The top BCP of 'o'. The path to the left side of BCP is concave downwards and the path to the right side is also concave downwards.(the same argument can be extended to straight lines also)
Where as a curve changes it's direction at a point of inflection. i.e before encountering that point, the path remains concave and after reaching the point, the path becomes convex. You can find such points on stems of some Ss

Yeah: it’s rather important if you want to generate a closed shape.

I said handles of BCPs and not BCPs. I know that all BCPs should be joined to get a closed path

No, the handles are not joined; just as each control point is independent of all others, so each handle is independent of any other handle…

> what is defined as an extreme?
Locations of BCP and handles are identified in font programs through a Cartesian coordinate system, and the extremes are defined as the top most, bottom most, left most and right most points on the closed path.

I think there's some confusion here…

The screen grab that Typogruffer is asking about shows a TrueType bézier curve, which are defined by two on-curve points (at the start and end of the curve) and one off-curve point. The off-curve point is usually depicted in the UI as connected to both the start and end points. Sometimes it may appear that there are more than one off-curve point between two on-curve points. This is because on-curve points may be omitted if they fall on a straight line between two off-curve points in order to save a few bytes of data. In the screen grab, the red circled area contains one of these omitted (implied) on-curve points.

PostScript bézier curves use two off-curve points, which in the UI are usually depicted as "handles", one connected to the start point and one connected to the end point.

Extrema points can be located by looking for the minimum and maximum x and y values along a curved path. On a circular path, these would be at the 12, 3, 6, and 9 clock positions. The extrema points are needed in order to define horizontal and vertical stems for hinting.

The screen grab that Typogruffer is asking about shows a TrueType bézier curve

Yup, what I said.

BTW I've always used "vertex" (or "point") to mean on-curve points and "BCP" to mean what some people call "handles" (off-curve points). Is that wrong?

hhp

"Vertex" says corner to me; I wouldn't use it to describe, say, an extremum on a continuous curve. I use "nodes" often.

Good question Hrant. In the mathematical discussion on wikipedia they refer to both on and off curve points that determine the curve as 'Bezier control points.' In the Adobe spec I link above, they refer to the handles as 'control points', and the on-curve points as end points. So my terminology above is not so good. I guess the clearer terminology is to refer to on-curve points as 'nodes' and off-curve points as 'handles', at least for cubic Beziers.

Yup, what I said.

Yeah, I knew what you meant, but you said you weren't sure, and subsequent responses seemed to indicate that there was still some confusion.

Yes, "node" might be better than "vertex".

hhp

The PS documentation calls them "points" and "control points" or "bézier control points" (i.e., "BCPs"). The TT documentation calls them "on-curve points" and "off-curve points".

It adds to the confusion that in FontLab lingo, a node is a single bezier curve:

http://www.e-font.de/flpydoc/html/Node.xml.html

...though in FontLab's preferences "node" is used for the points.

So, "node" may be just a FontLab thing?

I find the distinction between nodes and handles useful; they are both BCPs, controling the course/shape of the path.

According to the Type 1 spec, the on-curve points are called "end points" and the off-curve points are called "bézier control points" (BCPs).

FWIW, I think "nodes" and "handles" are fine. People know what you mean, even if it's not what they're called in the spec.

Well, properly speaking, points are points—that is, one specific location within a predefined grid. PostScript renders letterforms by proceeding in an orderly fashion from point to point, along the path delineated an each point's description. However, since the word “point” has at least two different meanings in typographic parlance, it seems to me that “node” is a better choice of names, because a node is a node, and not also 1/72 (more or less) of an inch.

And, “handles” is a perfectly functional description of how you wrangle a Bezier curve…

"Handles" on TrueType curves have always felt a bit unhelpful to me. They seem bound up together, so that it's almost impossible to change one without affecting others unintentionally, unless you want a tangent to become a corner.

Perhaps the "handle" metaphor just doesn't work very well as a way to work with TrueType curves. Or, maybe it does, but that the superficial similarity to PostScript handles leads to an incorrect mental model for those used to working with PostScript curves.

Does anybody prefer working with TrueType curves? My impression is that almost everyone works with PostScript curves during the design and drawing stage, with conversion to TrueType curves left to the last possible step.

No, I steer clear of TT curves.

What I wonder is if TT curves are inherently difficult to work with, or if it's just that nobody has come up with a sensible way to interact with them (as we have had for years with PS curves). Maybe the first attempt to come up with a UI was just to ape the PS handle metaphor, and nobody's ever tried anything else?

Mark, those are great questions, and I agree with your observations. However I recently wrote things to that effect and no less an authority than David Berlow seemed* to say that it's all in my head**. Hopefully he'll notice this exchange and chime in.

* My grasp of Berlowese has never been great. :-)

** Start here: http://www.www.typophile.com/node/96309#comment-522549

hhp

I remember reading that comment. I wonder if he was talking about RoboFont?

RoboFont TT curve editing works a bit differently than in FontLab. Essentially, when you draw a curve, say by making two end points, it looks kind of like you're working with a PS curve with two separate handles. The difference is that there is a phantom point that lies on the curve at a tangent with a straight line connecting the two off-curve (handle) points. In effect, what looks like a single curve segment with two control points is actually two curve segments with an implied on-curve point in the middle (a "smooth" point, in FontLab terms).

I don't see any way to work with individual curve segments (two on-curve points at the ends and one off-curve point between them). This seems more restrictive than FontLab's approach, although less confounding if you're used to PS curves. Maybe that's the whole point.

In FontLab, I also like being able to grab anywhere on a PS curve (far away from nodes or handles), and drag-bend it.

Mark, I remember seeing that in action (I myself haven't used RoboFont yet). Indeed I agree with your hunch that the only reason they would have such a setup is exactly because many (and I think most) people don't like working with TT beziers - or at the very least don't want to learn how.

And I wonder: why not just work in PS and convert? Is the conversion from PS to TT so unreliable that it's worth playing pretend like that? From what I've seen if you follow a couple of simple rules the conversion is always very clean. But maybe there are some dark recesses I'm unaware of (but would of course love to learn about).

hhp

why not just work in PS and convert?

That's exactly what almost everybody does. The fact that it works as well as it does is probably why improving the TT curve drawing UI doesn't get much attention. Maybe not worth the trouble.

I understand that things are no longer very relevant to the question I had asked, But I want to know a things:
1) I understand that working with TT beziers is more painful than PS curves. Am i right?
2) I primarily work with PS curves and and the .otf file renders the font flawlessly but the .tff file look is very lumpy. The curves are still PS while generating the TTF. Is this because of the difference between PS and TT curves?
3) I also want to know if you guys produce both .ttf and .otf files or just .otf files.

1) Right. Few type designers work directly in TT curves, at least during the design and drawing stages.
2) What do you mean by "very lumpy"? The conversion is usually fairly faithful, but conversion from PS outlines to TT outlines usually adds some extra points to the outline and this can sometimes lead to less than faithful conversion. It's typically best to increase the UPM of the font to 2000 or 2048 before converting to TT outlines for this reason.
3) I do both. I would prefer to just do .otf, but some customers prefer .ttf.

and should I change all the curves to TrueType before generating a TT font?

Does anybody prefer working with TrueType curves?

Ray Larabie favored TT curves at one time (certainly when he wrote this old FontLab tutorial). Using a grid seems to make working with them less of a hassle, since FL doesn't support "smooth" points in TT mode. See also: Karsten Luecke's Align TT Nodes script.

should I change all the curves to TrueType before generating a TT font?

Obviously the curves will be converted automatically (otherwise you wouldn't get a TT font), but it can be beneficial to manually convert and change the direction, then possibly optimize the TT outlines. Adam Twardoch's Autohinting Guide has some tips on conversion/optimization which could also be useful for unhinted fonts.

It's typically best to increase the UPM of the font to 2000 or 2048 before converting to TT outlines for this reason.

2048 is far preferable, since it’s the TrueType spec. When I’m ready to generate an OTF font, I make a duplicate file and rescale it to 2048. Since the scaling is not an exact multiple of the original, and since FontLab sometimes makes imprudent decisions on where to locate points on the grid ( a nnisance if the font has joining elements of any kind), I recheck the outlines, the metrics and the kerning before generating the TTF version.

When I’m ready to generate an OTF font, I make a duplicate file and rescale it to 2048.

Could you not just work with a 2048 UPM and cubic beziers? Or has it got something to do with using Corel in the process?

Karl—

CorelDraw has nothing to do with the choice. If FontLab can, if fact, generate a CFF-flavored OTF font with a 2048 em height, I would prefer using a single file AND cubic Beziers (which, of course, CorelDraw does)…

I am pretty sure that should be no problem at all, the classic association of 1000 UPM and Postscript/CFF fonts is just that, an association. When generating, FL comes up with a warning but you can choose to ignore it. You can also convert curves to quadratic beziers and export as .otf. There may well be good reasons for not doing this but there is nothing to stop you from doing it.

Thanks, Karl—

One is never certain whether or not ignoring nags may have untoward results. As long as I am religious about placing my extrema, I prefer to work in and export cubic beziers…

Two things to avoid a "lumpy" conversion from PS to TT:
- No "half-dead" curves (which makes me sad because half-dead curves: take up less memory; and are easier to manipulate, usually yielding an entirely satisfactory curve, I mean when the dead-side adjacent curve is a line). Just to be clear: these are curves where only one node has a handle. Quick tip: in FontLab Alt-Shift-click on the curve and it will auto-add and balance the handles; except you often have to tweak the result.
- Have a node at inflection points.* You can tell there should be one when the handles on a curve are on opposite sides. The inflection node doesn't have to be placed perfectly, but: to be sure it really is an inflection node made sure its handles are on opposite sides; and if you get it just right it should not change the shape of the curve at all (grid coarseness notwithstanding).

* BTW why hasn't this been automated yet? It's pretty plain math.

hhp

In FontLab, if you drag the knife tool from BCP across the contour to BCP, I think that will add a node at the inflection point. I agree that this should be automated.

"I want to know if using too many bezier points is a bad thing."

I think so.

"Is there a set number of bezier points that a user should not exceed?"

There are technical per glyph limitations based on the number of flattened segments in the final output, but I hope you don't mean that. Normally, for cubic beziers, having an oncurve point every 90 degrees of curve is best, with two off curve points in between. There are a lot of shapes that need an additional oncurve point, and these need to be carefully managed. There are few if any that need two oncurves in 90 of curve, so having the right number is pretty easy.

"Using more beziers obviously gives you more control..."

Show me.

Show me.

Or one could quote a highly accomplished designer: "There are a lot of shapes that need an additional oncurve point".

hhp

* BTW why hasn't this been automated yet? It's pretty plain math.

I dunno: because FontLab’s drawing tools generally suck, perhaps? IMHO…

"Or one could quote a highly accomplished designer: "There are a lot of shapes that need an additional oncurve point".

This is obvious, as I stated before the quoted invitation. The line between high accomplishment and difficultly, is extremely fine with said addition(s). Pick up your mice.