Hacker News new | past | comments | ask | show | jobs | submit login
Bezier Curves and Type Design: A Tutorial (scannerlicker.net)
111 points by adamnemecek on May 12, 2014 | hide | past | web | favorite | 33 comments

i hate to be "that guy", but please don't fck with my native scrolling.

Being "that guy" is actually helpful!

Thanks for your comment, leeoniya, but I'm not a skilled web designer, and I'm an even worst developer.

Since I did the website on my own and can't afford having someone doing it for me, I'll try to correct it the best I can.

It just might take me a while.


thanks. the solution is rather easy.

1. stop using the jquery.nicescroll plugin

2. set your ".col3" div to "overflow: auto" instead of "overflow: hidden"

Since you started the pile-on...having nothing be the visual indicator that something is a link is a terrible design decision. Are readers expected to run their mouse over the body of the text to haphazardly find which words are links?

This comment made me go back and play hunt-the-link :( Not a fun game, totally agree what an awful design. I don't like the strikethrough on hover either!

To be fair, there are no text links in that article (except "Pedro Amado", which, indeed, has no visual indication that there's anything special with it).

My point exactly...you missed:

> For more information on inflection points, have a __read here__

If I hadn't seen that sentence, and thought, "what's here?", I wouldn't have even guessed that there were any links in the article.

The worst side-effect is the middle-click + move mouse up/down to scroll doesn't work. It completely kills that.

If you're "that guy" I am too.

And please don't fck with my back shortcut.

Is that what was wrong? The article wouldn't even scroll until I enabled Javacript, and then it was so fidgety I had to abandon my trackpad and use the arrows. Very frustrating.

Agreed. I'm surprised no one seems to notice how non-native scrolling in Atom is.

Yes. The scrolling hack is very dissapointing. I only got through the first section before scrolling problems rendered the page unreadable on my phone.

I don't understand this bit:

> But if we were to write one to convert quadratic to cubic, the best the program could do is an approximation of the original outline, usually keeping the anchor points it already had, but adding one more control point per anchor.

Isn't quadratic just a special case of cubic? i.e. a cubic curve with C1 == C2. It does add one more control point per curve (so it's bad for the overall size of the drawing) but it's not an approximation, it's the exact same curve. It also seems like a much simpler conversion than the other way around.

Yes, the article is wrong. It’s possible to exactly convert a quadratic curve to a cubic curve, but going the other way the best possible is just an approximation. (Though the integer control point locations required by font descriptions can make it not quite exact.)

Also, this conversion doesn’t seem like something anyone should do by hand (e.g. adding extra control points which don’t change the curve): some algorithm is going to be able to optimize curves to minimize points, convert between curve types, etc. much better than a human is, and much much faster. [Though for all I know some existing software has crappy implementations]

Personally, I’d recommend people use Raph Levien’s Spiro curves to design their fonts (and not use Béziers directly); they make it much much easier to make whatever shape the designer is actually trying to make. (Folks on Hacker News interested in the mathematics of curve drawing should also definitely check out his PhD thesis.) http://www.levien.com/spiro/


Isn't it the other way around? I mean, isn't cubic a special case of quadratic?

Please correct me if I'm wrong (or my references), I want this article to be as accurate as possible!


A cubic is more general than a quadratic, so clearly a quadratic is going to be a special case of a cubic.

We can demonstrate this by looking at the equation for a quadratic Bézier:

     (1 - t)^2 P_0 + 2(1 - t)t P_1 + t^2 P_2
Now, let's increase the degree.

     = [ (1 - t)^2 P_0 + 2(1 - t)t P_1 + t^2 P_2 ] * [ 1 - t + t ]
clearly this equation is equal to the above one because 1-t+t == 1 and multiplying by one does nothing.

     = [ (1 - t)^2 P_0 + 2(1 - t)t P_1 + t^2 P_2 ] * [ (1 - t) + t ]
     = (1 - t)^3 P_0 + t(1 - t)^2 P_0 + 2(1 - t)^2t P_1 + 2(1 - t)t^2 P_1 + (1 - t)t^2 P_2 + t^3 P_2
Group by powers of t:

     = (1 - t)^3 P_0 + t(1 - t)^2 [P_0 + 2*P_1] + (1 - t)t^2 [2P_1 + P_2] + t^3 P_2
Which is exactly a cubic Bezier curve.

Thus, all quadratic Beziers can represented cubic ones, but the reverse does not hold, thus quadratics are specializations of cubics.


This is known as degree elevation.

Oh, I see my mistake! Thank you very much!

I'm not very math savvy and I was trying to get this right.

Anyway, thank you very much for making this clear!


That was pretty good, right up until the end. There's a curve that the author manually subdivides into 4 separate curves without any justification. With all the talk in the earlier sections about number of points it takes to render a curve, why would you add a bunch of points to a curve which is mathematically equivalent to the original?

It's a two way: file size (amount of points) and rasterization issues.

Since every DTP program has it's own (or multiple) rasterization algorithms (and the same goes for printers) we have to deal with these too. It's about balance. :)

So it's an upfront hedge to work around poorly written rasterizers?

I would love to see some examples of the bad rasterization this kind of thing fixes. I think that would be an interesting article/addition.

I think it's to make the conversion from cubic to quadratic more predictable.

In my experience designing tools, artists often prefer predictable over optimal.

Of topic: before I clicked I have half expected applications of some deep knowledge of category theory in topology to programming :D ... I guess that is what happens when you progam in haskell and share flat with algebra master student.

It got me too -- read the first sentence and thought "Why are they talking about fonts?"

Surprised to see no mention of the underlying math (which is what I find interesting). In case anyone else feels the same, here's an article I wrote about Bezier curves.


Wow! Awesome article! :D

Do you mind if I had your article to mine?


I always love reading artists rules of thumb for how to use curves and surfaces in design.

I'm surprised how much performance is a consideration. In CAD the degree of the surfaces are not really a big deal any more, surface degrees of 3 are most common, in some fields you get up to degree 7 or 8. However there are generally a lot fewer surfaces in CAD then there are curves in a page full of fonts.

A couple of comments:

> to convert quadratic to cubic, the best the program could do is an approximation of the original outline

You can convert quadratic to cubic exactly (the algorithm is called degree elevation). Cubic to quadratic must be an approximation, but the artist seems happy with it and designs around it (Bezier endpoint at inflection point, etc). The other comments about file size and computation still hold.

> Since we still need a worldwide network of computers just to find some more pi digits, no perfect circles to anyone

Hmm, you can get perfect circles with rational Beziers, but I don't know if those are supported in fonts. I know they're not supported in svg.

Well, of course in CAD it won't matter since the surface formula isn't the end product. But with fonts, it is.

Leslie Cabarga's _Logo, Font & Lettering Bible_ has a nice section on this, too. http://amzn.com/1581804369

I know nothing about font design and rendering and I most likely will never need this knowledge but that was quite a fascinating pre-coffee read

Not just fonts, logo design as well. This becomes more relevant now we can have SVG (vector) art as well.

Not just fonts and logos, Bezier curves were invented to design car parts.

Javascript only website alert.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact