<twist>

hhp

I followed your original thread on this closely, and have given it a lot of thought. As an editing/development environment, I think something based on Cornu curves is a great idea. One fundamental problem that plagues PostScript style outlines is that it is difficult to get a nice smooth transition from a straight to a curve. Working with a Cornu curve (a.k.a. Cornu spiral) would seem to be a great way to deal with that.

That being said, making your own editor for this is really not a great solution for most font developers--though it makes a great proof of concept. The idea would need to be adopted by mainstream font editing applications such as FontLab and DTL FontMaster.

I for one would be happy to play with a prototype editor once you get turnkey installation for Mac or Windows, and would probably strongly encourage the font editor folks to look at it.

Regards,

T

How hard would it be to write a Python add-on for Cornu support in FontLab?

hhp

I'm keen to have a go with your Cornu editor but I can't get it to compile. If I run 'make' inside the ppedit folder, I get these two errors (followed by 100s more, but these look like the killers):

/bin/sh: line 1: gtk-config: command not found
/bin/sh: line 1: libart2-config: command not found

I have installed Fink and XCode 1.5, and tried to install gtk+ and libart2. They both failed for some reason. How about posting a link to a compiled version?

Laurence: is it possible you don't have /sw/bin in your path? Fink requires you to run /sw/bin/pathsetup.sh or the moral equivalent.

Assuming you've already got that covered and it is another problem, try the binary I compiled. It will probably work better if you run it from inside an xterm than from Terminal.app.

hrant: I'm not deeply familiar with that API, but an off-the-top-of-my-head guess is that it would be fairly straightforward to write a batch converting tool, but probably not easy at all to integrate it at the level of the interactive curve editor.

Thomas: I'm glad you're interested in the Cornu curves; obviously you've got a lot of sway in the community. That said, perhaps you could enlighten me exactly how I benefit from having the "mainstream font editors" appropriate my ideas. There's a lot more that I want to do besides the Cornu curve, including optical scaling and revisiting Metafont-like controls. The only way I can see not to be at the mercy of developers in a somewhat marginal niche is to code it myself, possibly with collaboration from the free software world.

Raph:

It depends on your objectives. I can understand why you might not be interested in the mainstream font editors using your ideas without you controlling/directing the implementation.

My own interest in supporting this technology would be to have it really mainstream and something I could rely on. If it's not in mainstream tools, and requires storing the master outlines in what is essentially a non-standard format, then my interest becomes largely academic. I don't think I would want to risk ending up with my outline data in an unsupported format that I can't get at, some years down the road. Not everyone will feel the same way, of course, but I imagine a lot of folks will.

Maybe you can get more out of this yourself if you develop it all on your own. But there probably isn't a lot "in it for you" no matter how you play it. Font editing tools is not a very profitable area to go into.

If it's more a matter of control rather than profit, then maybe something like teaming up with the FontForge folks is the best way to go.

Best of luck with it, no matter what you decide to do. It is a really interesting idea.

Regards,

T

Thomas:

Thanks for your clear explanation of your concerns in adopting a new technology. In the free software community, we also have concerns about becoming dependent on proprietary formats. This is one reason, for example, why we have enthusiastically adopted PDF but not Flash.

I'm not 100% sure what my objectives are. As you say, it's very unlikely that anybody can become rich developing new font technology. At this point, I'm more concerned with recognition than making money off the idea.

There's one specific outcome I would like to avoid, though. I would be very disappointed if one of the major font editor developers introduced Cornu curves into their product without credit to me. Since I haven't pursued a patent or anything, there is no legal reason not to.

I must admit that when I first read your 8 Nov comment, I was rubbed the wrong way by what I read as condescention: "it's ok for you to play with these curves, but when it comes to using them in the real world, you better leave that to the big guys." I'm sure that's not what you meant to convey, so I'll try to stay focussed on the concrete issues.

As far as the risks of being locked into a proprietary format, I feel there are three things I can do:

* Fully document the file format and the underlying algorithms to process it. This part is easy, as I am writing up the ideas in a PhD thesis, and I am designing the file format to be particularly easy to parse and manipulate.

* Release the core code as free software, guaranteeing that it will stay alive so long as there is interest in the community. I am seriously considering releasing the code in a hybrid model, where the Linux version is truly free software, but the Win32 and Mac versions have proprietary UI code, including refinements such as making cut/paste interact transparently with apps such as Illustrator.

* Develop batch converters to standard file formats such as OpenType, so that in the worst case people who develop the font as Cornu curves will have to do follow-on work in a standard tool.

For just drawing curves, such a batch converter should work fine, but to take advantage of the planned optical scaling and meta capabilities (such as continuously varying extender length), it will by necessity "freeze" these parameters into the curve.

Having you as a champion of these ideas could be a very good thing. Hopefully I can allay some of your concerns about getting trapped into an unsupported file format, and you can allay some of my concerns about recognition, and to make sure that the full package of ideas including optical scaling has a chance to live, rather than being crushed by a "good enough" hack of the Cornu curve into legacy font tools.

I'll probably prepare a native OSX Carbon demo some time in the next couple of weeks. I'm sure we will pick up this discussion after you get a chance to play with it - assuming my experience is representative, font designers will flock to Cornu curves and refuse to go back to the bad old days of Beziers.

I suspect Thomas was simply saying: Don't get your hopes up too much.
Such a cautious approach is something natural to me too - on the other hand that's probably why you'll end up releasing some great and useful font editing software (or at least utility) and I won't. Good luck!

> font designers will flock to Cornu curves and refuse to go back

If it's that much better, many people might indeed gladly give up the comforts of what they're used to. But note how much general resistance there is to switching from Fontographer to FontLab, even though almost everybody agrees/admits that the latter is much better in almost every way; and the difference between them is probably less than the difference between either and Cornu spline editing! :-/

It seems to me that a good tactic in terms of getting a solid initial base of users would be to target people who are still using Fontographer, but have developed the need to switch to something else (FontLab being the most obvious choice). Since this group of people has already given in to the idea of change, they might very well form your best user foundation. And there are a lot of them, as evidenced by the demand for Cabarga's FontLab quickie-learning book.

hhp

But note how much general resistance there is to switching from Fontographer to FontLab...

Two years ago, I would have said that was the case, because many people who were familiar with Fontographer wanted similar drawing tools in FontLab, which they now have. Since FontLab 4.6 was released, almost everyone I know has switched to it, except for a few die-hard FontStudio fans. There seems to me now very little resistance to switching from Fontographer to FontLab.

Raph,

Glad I was able to explain myself better. I really don't want to discourage you from developing your ideas, certainly hope you get credited for them, and really wasn't trying to be condescending. I was just trying to explain why it is that I'd need them in FontLab to be useful to me personally, and why a lot of the professional type dev community would probably be thinking the same way.

Honestly, this is one of the couple of coolest new ideas I've heard for type development tools in this decade. Please forgive me for wanting it to be integrated into the tools I use daily.

That being said, I think that both Hrant and John are right. On the one hand, the pro type dev community has really come around to FontLab lately. On the other hand, there are still a lot of people using Fontographer, especially those who don't do this full time, or are strictly doing the glyph design part of things and not final production.

Finally, although diversity and competition is good, I have difficulty imagining that either FontForge or a brand-new-from-scratch program is going to be really competitive with FontLab any time soon. I'm just thinking that it's a ton of work and a certain amount of polishing time that is needed, and that it's not feasible to get there in just a year or two.

Regards,

T

Raph, I don't understand why you don't patent it if it is patentable, unless the costs are prohibitive, and the potential income makes it not worth it, which may be the case.

But wouldn't FontLab or FontMaster want this option, and be willing to pay you something to develop it? It might not be worth it to you, but on the other hand it might be. After all, you are going to do a lot of the work for the PhD anyway. I would think that getting on the phone with them would be worth it, after you've talked to a lawyer. - Whether to listen to the lawyer is another issue! Best of luck.

Raph,

I am not a lawyer, but I believe you would be protected under U.S.C. Title 35, Chapter 10, Section 102.

Especially, arguing that this forum is a publication. And can be reliably dated. It's different, if I'm not mistaken, in Europe where the prize is won by the first to patent and not by the first to invent.

So even if someone did start making the software based off of your work, you can make a big stink and at least get the credit you deserve.

Again, I'm not a lawyer. My legal advice should be taken with a grain or two of salt. Then again, I may bill you for the legal advice anyway.

William:

I did consider patenting the idea, but basically decided that the return probably wouldn't outweigh the costs. In my experience, getting companies to license technology is very much an uphill battle. I've had some success with my screening technologies, but there's an area where big printer companies invest millions of dollars each to develop the technology in-house, and my stuff is just as good and well within reach of smaller companies. But when it comes to licensing technology that breaks truly new ground (for example, my algorithm for suppressing moire using conventional dot shapes), I've had basically no success at all.

Of course, I could be passing up the opportunity to become fabulously wealthy off the idea, in which case I'll just have to file it with all the other missed opportunities :)

Raph, I downloaded and compiled your editor. I'm running a Fink install on Mac OS X 10.3.5 with WindowMaker on a rootless desktop.

OH MAN OH MAN is that ever a sweet way to draw!

Keep it up. I would love to see this on OS X native. Am happy to test for you too.

Jon

My mistake: Raph's got a whole year after publication (in the USA anyway). Or so it seems.

In any case, his list of the three things he can do seems very cool and apropos.

I'm not going to be online much the next few days. Just made an offer on a house tonight, am having guests for the rest of the weekend, yadda yadda. I hope I get a chance to play with Raph's drawing tools soon, but since I don't have the right setup (yet), I will have to wait a while.

Cheers,

T

>I would be very disappointed if one of the major font editor developers introduced Cornu curves into their product without credit to me.

Cornu curves? These are *Levien Curves*. Didn't I read that Bezier wasn't the first to put cubic equations in that form? He was rather the first to see how they could be used effectively for drawing. Your situation is parallel.

Raph, one thing to note about the makers of font software is that -- with the exception of Macromedia, who are not doing anything with Fontographer anyway -- these are all small, developer-run companies. FontLab is currently the most successful of these, but its still just a few guys in St Petersburg, Russia, coding away. In this respect, they are not too far removed from your own situation, and I think you would find them friendly and open to new ideas, as I have.

Very interesting!

I've had several segfaults (OS X, fink), and I don't think I've been able to isolate the cause of all of them. One I can reproduce reliably as follows:

1. Create a circle by joining three points.
2. Toggle one of the points.
3. Drag this corner point round so it coincides with one of the other two.

Hope this is some use. As a cosmetic issue, it would be nice if you could double-click to close the path rather than (or as an alternative to) clicking on the start point.

So when do normal humans get to try this fabulous thing out?

John, I think the situation with FontLab adoption is certainly improving, especially among "pros"*, but there's still enough of a Fog base to facilitate that tactic of Cornu "deployment" - especially if it gets integrated into FontLab.

* On the other hand it's notable that AFAIK Matthew Carter still uses Fontographer... 3.1!

hhp

Matthew is primarily a type designer, not a font developer. Obviously Georgia and Verdana were not manufactured in Fontographer, even though Matthew may have used that tool to create the outlines.


Raph, what would be involved in getting a version of your curve editor working under Windows?

> Matthew is primarily a type designer, not a font developer.

So that means he (and other only-type-designers) would not benefit from a better outline drawing mechanism? Quite the opposite.

hhp

Raph, it just occurred to me that if drawing with your curves is as sweet as John Whipple says, they may have an application in Illustrator and other drawing programs, which is a huge market compared to font development.

So for that purpose you might want to rethink about filing a patent. Then you could explore the market as an add on in Illustrator or other drawing programs. Traditionally draftsmen did use 'French curves', and Illustrator does have a spiral drawing tool, but I suspect not at all as useful and easy to use as yours, with your 'spinners', though I haven't used either one.

Also again on terminology, I think that you could say that 'Levien' curves are sections of the Cornu spiral selected or drawn using your methodology. Ok, it is better if someone else, such as the buyer of your stuff, makes the choice of terminology, but here it is from a third disinterested party as a suggestion.

...may have an application in Illustrator and other drawing programs, which is a huge market compared to font development.

This is oh so very true. Developing this even as plugin for Illustrator would be cool or (keeping it Free) an extension on Inkscape's tools would be awesome.

Levien curves definitely, and can your university help you secure a patent or is that crazy talk?

I like B-Spline tools like the one in Expressions 3 (Formerly Creature House now M$ free download). Clicking three points is the same model. This also has a Bezier Pen and a "Polyline" pen which is a combo straight-segment and B-Spline tool.

Illustrator's spiral tool is okay, but I haven't really used it much. It draws spirals only, as distinct from crurves derived from spirals. Drawing spirals is easier in ppedit (please change the name... ;-)) and S curves and curves that are sections of ovals.

Oh and I meant 'rooted' or 'full screen' mode in my earlier post.

Jon

Jon,

Would you produce some screen shots for us?

Thanks!
Randy

I've got a simple screenshot here (made on Linux this time).

Hey, that looks like it could make outline creation fun again! :-)
Those "arbitrary" 3-point circles sure look funny though.
Raph, what about enforcing extrema points?

And has anybody tried to use Cornus to trace bitmap scans?

hhp

Oh, and it's even easier to crash it than I thought: when you're drawing a curve (and it has more than one point already), drag the new point so it coincides with an existing point on the same curve.

I can stop it crashing with the attached patch. It's obviously not the "right" fix - I guess the right fix would be to prevent points from coinciding at the GUI level - but it indicates where the problem lies.

Patch for ppedit patch (0.2 k)

In case it helps, here's a gdb backtrace from the point at which cornu_seg_to_bpath is called with t0 not a number.

Backtrace from cornu_seg_to_bpath bt (0.8 k)

Yes I have an S curve illustration I was working on last night showing clicks and drags. Will post later today...

Okay this was a logical breaking point, so I'm uploading it now. Won't be back until later tonight.

This is an illustration of the clicks and curves I made to generate an S curve just screwing around. I felt it was faster than using a bezier pen like in illustartor.

Hrant: I haven't tried tracing a bitmap though there's a note that it can happen in the Read Me...going to try tonight.

This is scarygood.

hhp

Well, I have a more or less plausible fix for the crashbug. Patch (unified diff) attached as before. This is instead of (not in addition to) the previous patch, so apply to a clean copy of cornu.c.

Well, it seems plausible to me. Raph will know better, I'm sure.

Patch to fix ppedit crashes patch2 (0.9 k)

I'm not sure that my miserably amateurish drawing demonstrates anything more interesting than my lack of skill, but I just had a quick bash at tracing a bitmap scan; specifically this 60pt Centaur 'E' posted by Raph to his Digitization Quality thread.

The current incarnation of ppedit doesn't let you delete knots or add new ones in the middle, so I stuck with the knots I generated with a quick click round the outline, and pulled them around a bit.

Here it is, with/without the background/knots.

Cool - thanks!

So what do you get if you used let's say half as many points?

hhp

Thanks everybody for all the awesome feedback, especially the screenshots and patches!

Robin: you'll be happy to know that my current working codebase can insert and delete knots. I'll probably make another release later today. Your 'E' generally looks good, but definitely has more knots than it needs. Here's a screenshot of the lowercase 72pt metal Centaur 'e' I'm working on.

Hrant: I think it's best to enforce the extrema in the conversion from high-res outlines to the specific font format. Of course, you're going to get quantization error when you do so, but I don't see any good way to avoid that. Side note: does anyone know of a downside to using 4096/em when generating TT outlines? (With Type1, you can cheat on the precision by using the div operator)

The OSX port is coming along (right now it can load files and display outlines, but not yet edit them interactively). The last few days, I've been giving more attention to much needed UI improvements, though. I've been tracing 72pt metal Centaur miniscules, which is of course a pretty good real-world test. I'm also willing to do the Windows port myself, but coding does take time. If someone with good Win32 coding skills wants to volunteer, I'll gratefully accept.

Last but not least: I've tentatively chosen the name "Spiro" for the project. At least it's an improvement over "ppedit".

Raph: this is all excellent!

Perhaps it's fixed in your development version, but I've discovered an issue with the algorithm that converts cornu segents into Bezier paths. It can fail to terminate in certain circumstances. Since I don't understand the algorithm I have no idea how to fix it, but I attach a very small (57 bytes) plate file that causes the problem for me.

(It can happen that t0 == t1 in cornu_seg_to_bpath, so that the recursive calls have the same parameters again, ad infinitum.)

plate (0.1 k)

> I think it's best to enforce the extrema in the conversion

Well, a conversion would certainly have to do that, but is there a way -and is there a drawback- to facilitating the placement of your points at extrema? For example, what would a "perfect" circle look like with points at the four compass points?

One thing about the "e" (not Cornu-specific): the left curve of the eye/counter seems more closed than the lower open curve - the other way around is better.

BTW, "Spiro" sounds nice to me.

hhp

Spiro? We could then write a companion program and call it Agnew. Two reasons I'd vote against Spiro:

1) It conjures up Spirograph, which your editor most certainly is not.
2) (Apropos 1), there is already this: http://cgibin.erols.com/ziring/cgi-bin/spiro.pl/spiro.html

What about Amalthaea, or Achelous, two figures from Greek Mythology related to the Horn of Plenty, Cornucopia?

hhp

Hmm, I think I've found some sort of minimal case that causes the algorithm to diverge.

(plate
(o 0 1)
(o 2 1)
(o 1 0)
(z)
)

Perhaps this sheds some light (or perhaps not).

If you perturb a "fatal curve" a little, you can get some oddly distorted geometry, such as this egg-shaped circle:

(plate
(o 10 110)
(o 205 115)
(o 110 10)
(z)
)

Sorry to bombard you all with techy stuff. This will be the last one today, I promise.

Part of my last patch makes no sense at all. What was I thinking? It doesn't even stop the thing from crashing when you overlap knots, you just have to overlap three consecutive knots rather than two!

Here's my current diff. It includes a *slightly* saner fix for the overlapping issue. (If two points coincide, surreptitiously give the second one a very very gentle nudge.) Also it detects if the rendering is obviously going to diverge, and yells & backs off. This doesn't address the real problem at all, but does stop it from actually crashing.

patch3 (1.4 k)

Hi, Raph. I tried to make freehand drawings (1, 2). Drawing a capital serif A turned out to be very difficult

Sergej, those are nice drawings. I think the A was hard especially because there's not a lot of "backing away" from an initial attempt the way things are now (no addition or deletion of knots until the next code release from Raph).

Raph, further to Hrant's suggestion about extrema: I was think even mapping and marking the extrema onto the curve after it was calculated (and drawn?) would be useful as a reference, even if you were't to make it interactive. A Triangle or X mark would be nice. In fact it might be better that using extrema interactively.

Steve I like both the Spirograph and Agnew references even if unintended, but that's just me.

What about Curve Master Curvilicious or Curvaluscious? That's just silly.

More later.

Jon

The problem with A is that ppedit doesn't have an option to make a smooth transition from a straight line to a Levien curve.

Raph, is this an inherent design limitation or just an oversight on your part? As it is, I don't see how it will become usable.

Urg, I can't make a background load. I have a valid .ppm but it isn't getting picked up (have tried placing it in same dir as ppedit, and in /tmp. Something I am missing?

...doesn't have an option to make a smooth transition from a straight line to a Levien curve.

Yeah, this is pretty early stage proof of concept stuff, and a lot of tools that we'd like to see won't appear for some time. I'd like to be able to program to help out, but I'm not a programmer.*

I have found that the position of the knot after the curve smooth transition is the only way to get a smooth transition for now.

---
*Raph: I am graphic designer and technical writer so if I can be of help in the future I might be able to spare a little time...

Jon

Hmmm. The ease of doing a really nice smooth transition from a straight to a curve was one of the main things that made this whole idea attractive to me. I'll be very curious to see how it works once that is ironed out.

T

Sergej: thanks for your comments. I appreciate negative feedback as much as positive. Well, almost as much :)

Here's the deal about straight-to-curve transitions. The Cornu spiral can do a very good job with them, but my program does not yet automatically find the curve parameters to fit this case. You can fit by hand if you're willing to do some nudging of points (and perhaps add an additional knot or two beyond what Sergei had), but ultimately my feeling is that this is something the computer should be able to solve for you.

My sense is that Ikarus got the UI issues about right. In addition to the curve and corner points present in my code now, Ikarus also has the concept of a "tangent point", which is used primarily to join straights to curves. I'm pretty sure that I'll add that third knot type, with behavior similar (probably not identical) to Ikarus.

That said, the mathematics of the straight/curve transition are devilishly difficult. I have about a couple dozen papers printed out now that directly address the problem of fitting a smooth interpolating spline, but none really address the issue of a straight/curve transition directly. The best result I've seen so far is Moreton's work with MVC's (minimum variation of curvature)

Here are some screenshots to demonstrate the point I was making in the previous post. I traced a 36 point Century Catalogue A, scanned at 1200dpi. Here's the original scan:



Here's the resulting outline without knots or background image. For this trace I chose sharp corners.



Here's the outline (with knots) superimposed over the reference image:



And finally just the outline and knots:



Each round corner is accomplished with three knots. Placing the knots so that the two on the end have the right tangent (coinciding with chord to next knot) and curvature (zero) takes some patience. That's the part I'd like to have a better UI for.

Jon: to make a background load, you have to put it in /tmp and call it foo.ppm. Literally foo.ppm, foo isn't just a metasyntactic variable here.

Robin, thanks I'll try later today.

Raph, nice example A especially instructive with the knot locations.

Talk soon.

Jon

You are welcome, Raph. I took your advice to heart, but eventually my patience run out. Ahem.

On a second attempt I got what I wanted. (This particular serif style is one I might use for my typeface.) Once you know where to put points the contour shaping becomes manageable and not as hard as it seems at first, but the current approach is still unnecessarily painful. As you say, there needs to be a third knot type. That said, I don't see the advantage of using your curves instead of Bezier's in this particular case. Do you? (I'll try drawing letter U later.)

I think your curves have interesting dynamics. If you have a series of points and you change one, the curve changes between them all. Reminds me of wave propagation. With Bezier curves one is used to the curve between neighbouring points to stay the same. With quadratic curves also the neighbours are effected. So, the results of drawing with your curves are harder to predict, though I'm not saying that I don't like it that way. Predictability is overrated anyway. Another thing is that one doesn't have to worry about curves not being round. That's what I referred to when I said drawing the same D in FontLab felt kind of lame. This is a very nice property. So, yes, I agree with your original statement that it's faster to make

So when will non-Unix people get to try this out man?!

hhp

Soon. The (provisional) patent application got filed last night, so it’s just a question of me banging this stuff into releasable shape. The initial release will contain:

a) GPL’ed source of the tool I’m using.

b) A Mac build.

c) A web-based test app with partial functionality.

The initial release will be for brave souls - it’s got lots of rough edges I don’t mind working around, since I built it. But at least people will get to try it out.

Cool. I guess a Mac build is easier than a Windows build because OSX has a Unix heart? I have access to Macs here and there but if you manage to release a Windows beta as well that would be super.

hhp

Hi there,

what a cool app. I’ve tried a little bit (mac os x), but had problems with getting into the ui. Anyway it generates great curves, which i imported in illustrator and played around with.
I am also doing illustration and this is not type, but i am hoping to motivate you with this to make it a better app!

Yeah
Derya

p.s. sorry about my english...