Spiro 0.01 release

Primary tabs

Yuri, a plugin architecture allowing for different curves in fontlab sounds fantastic. I would love to explore a nurbs based drawing environment, for example. It would solve the licensing issues for this technology too :)

Yuri, a plugin architecture allowing for different curves in fontlab sounds fantastic. I would love to explore a nurbs based drawing environment, for example. It would solve the licensing issues for this technology too :)

That's why we plan to implement it.

There are many possible ways to draw outline. I personally experimented with several types of splines, some "centerline" methods, Ikarus curves etc. Even in FLS you may find 5 different ways to build outline: 2 types of curved in "main" mode, Sketch mode (some type of spline, point-compatible with Ikarus outline), Primitives (which is "object" UI) and some strange method to use components as "blocks" to build outline with autojoin function (not really useful and never documented).

Only "main" mode actually survived and is used to draw, all others are more or less "experimental".

Oh, there are few more: in standard FLS distributive you may find 3 "Python tools" which are good examples of how this spiral-based technology may be integrated even into FLS5.

Two tools are Line and Curve (latter shows some rudimentary auto-curvature control) and third is called Drops. It creates random-size circles if no tablet is connected. With pressure-sensitive tablet size of the circles depend on pressure.

Actually it is very interesting challenge to integrate spiral-based editing tools into FLS using Python tool gateway :-)

Few words about our future approach to different editing methods: the biggest problem of current Fontlab tools is that all of them mix production with design. We plan to separate it and offer plugin architecture for editing content of glyphs.

Yes thats exactly the 'problem' with Fontlab. It's not really a designers tool as it is. An open modular approach sounds great.

@yuri: What about Peter Karow’s approach to construction of outlines using spirals? Is rougly the same idea? (It is on page 86 in English edition of his book.)

Only roughly. The spiral shown on page 87 isn't Karow's, it's from the Purdy-McIntosh system (I have a bunch of references if anybody's that interested). Basically, the results are good, but the way they have it set up it's very hard to edit: the user has to put in all the spiral parameters explicitly. In my approach, the computer solves a global system determining the spiral parameters, based on curvature continuity constraints at the on-curve points. Completely original to my approach is the "one-way" constraint, which gives you continuous curvature at straight-curve joins (and is more general - the "straight" section can have a slight bend to it, and it solves that too).

We plan to separate it and offer plugin architecture for editing content of glyphs.
There will be only two minimal requirements: plugin must resterize (with smoothing of edges) and provide at least a conversion to and from Bezier outline.

A plugin is an entirely satisfactory approach all around. But let me understand more fully, by asking some questions:

* Will it be possible to write interactive editing plugins in Python and have them work cross-platform?

* To do the rasterizing, as you say, can my plugin generate a (crude) Bezier and hand it off to a FontLab-supplied API for the rest?

* I assume that the plug-in also gets some kind of API for marshalling and unmarshalling the plugin-specific format into the FontLab database file. Is this correct? For what I need, JSON would be ideal, but other choices would also work.

I agree that combining "design" and "production" has serious disadvantages. I have come to believe that the best approach is to generate high-fidelity "masters" using a design tool, ideally with parameterization, and then have a batch-mode converter to freeze those parameters, quantize to a specific Bezier grid (either cubic or quadratic, although at this point I only have optimized conversion to cubics done), and generate the font file.

I also agree that it's possible to do quite a bit better than the .ik file format. It was pretty good for its time, but there's lots that I know now that just doesn't fit into the .ik approach. (Incidentally, the Ikarus spline is one I look at carefully in my chapter comparing two-parameter splines, along with the Hobby (Metafont) spline, Minimum Energy Curves, and, of course, Euler spirals).

I haven't actually played with the Python capabilities in FL5 to see what's possible, only looked at the documentation. It might be possible to do a useful prototype.

@sgh: no, the 0.01 x3 build doesn't load a background image at all. Sorry. It's obviously not that difficult a feature to add, because I do have it in the gtk1 version, but I just haven't gotten around to it, and I'm not sure when I will have time to do so. I was kinda hoping others would pitch in on the coding, but that hasn't happened (yet) either.

@hrant: narrower "S". I know. But at some point we cross the line from "what the tool can do" to "how good is Raph at font design." I'm middling-good and hope to get better, but that's kind of off the main topic of this thread.

Ultimately, I think it will take a number of people spending time with the tool and learning how to get good results before we can definitely answer the former question. People spend months, if not years, learning how to draw top-notch Beziers. I strongly suspect that the learning curve is easier for spirals. The big unanswered question is whether the results are better once you've climbed it.

* Will it be possible to write interactive editing plugins in Python and have them work cross-platform?

It is possible even now. Spiro data may be stored in glyph dictionary (Python-accessible storage for arbitrary data). Python tool API allows to redefine mouse events and window paint function, but that is currently very limited.

In future implemenation plugin API (both for Python and for general coding) will be greatly extended.

* To do the rasterizing, as you say, can my plugin generate a (crude) Bezier and hand it off to a FontLab-supplied API for the rest?

By rasterization I mean conversion to 8-bit grayscale bitmap. While conversion to Bezier is OK, it will be much faster if Spiro outline is converted to supersampled vector-only outline. Then it can be passed to system or Freetype rasterizer to get bitmap.

What I mean is that in furure plugin architecture we will define minumal set of plugin functions that are required for it to be included into FLS as "layer editor". That will include on-screen outline rendering, conversion to Bezier outline, rasterization to grayscale bitmap, serialization (it should store data in its own format and Bezier format for compatibility reasons) and UI integration. This plugin architecture is currently in early stage of development, so many more details will emerge as we move forward.

* I assume that the plug-in also gets some kind of API for marshalling and unmarshalling the plugin-specific format into the FontLab database file. Is this correct? For what I need, JSON would be ideal, but other choices would also work.

Future database format will be very different to what we have now. It will allow to store glyph layers in any format that is required by any of plugins.

.ik format: I think that computer power available at the time was an issue when Ikarus was developed. It is actually based on very simple math, which has many limitations. That is the reason why in sketch mode of FLS we are using some approximation of Ikarus curves with splines. That gives much more flexibility to outline (it can be solved with any position of points) while keeps it very close to .ik shape.

@hrant> Could we see how [well] it works out?
Let’s say “skagy” varying from a pretty small to a pretty large x-height.

Sorry about the delay in doing this, but I was traveling and then forgot about it. I've posted a sample that shows varying x-height in Aurulent Sans in that font's critique. The amount of time it took me was changing one line and hitting recompile. The tricky part was figuring out how to install several different versions of the same font. :)

The ability to change basic parameters globally over the entire font is quite nice, but it does require planning the scripts (somewhat) carefully. For instance, I can't push the x-height much over 600, because then the script that generates the question mark barfs. Of course, as Hrant pointed out, it's presumed that the parameters won't vary too much from the value in mind when the scripts are written.

I'v tried to use the app on a mac os x 10.4. It is a great tool and I would very highly appreciate it, if you would work further on this application. Especially for the mac. It makes the best curves on earth!

recommendations:
- better UI (for example a toolset beneath the drawing window)
- export function in different formats (.ai, .eps, jpg)
- lineals would be also great
- a info window to see exactly where the points are lying
- function to underly a scanned image

once again thank you very much for this little app. I think it will have a great future.

Cheers
Derya

p.s. maybe you could make it work as a plugin for illustrator? I would be more than willing to pay for it.

Wow, this is an impressive curve technology tool. Is there any chance that a ported Windows build is available?

If not, how far along is the port -- I might be able to get some interest in development on the project. The developers I know though would probably want to port everything C++ with the QT GUI framework, to make it fully cross-platform.

George Williams has extended FontForge to support Raph Levien’s Spiro curves. I started a thread here on Typophile to discuss that, but it hasn't drawn much attention yet. Anybody have any thoughts to share?

Hi! Just wanted to bump this up. I've been using Spiro drawing in FontForge for months now and it has proven an invaluable addition to the tool set. While there are some shortcomings under predictable conditions, I wouldn't think of going back to drawing letterforms with Beziers alone.

Developement version of Inkscape supports Spiro as well now. It's implemented as a live path effect (that is, there is always a final bezier path in an SVG file) and can be applied to any bezier path or be drawn with a pen or pencil tool. It will be available in final Inkscape 0.47 release (due this autumn probably).

I downloaded the Carbon ppedit app, but nothing seems to happen when I click anywhere on the screen. I tried opening a plate file from the command line and while the terminal window looked like it was logging my mouse actions, nothing was showing up in the drawing area. Am I being a total idiot and missing something obvious, or is there some bug in the app? I'm running Leopard on an intel Mac.

I haven't tested on Leopard - it's entirely possible that there is a bug. Unfortunately, I have very limited time to work on this now (I'm really trying to concentrate on finishing my PhD), so it'll have to wait a while unless somebody else wants to play with it.

In the meantime, you might want to try out an Inkscape dev build - that has Spiro integrated and is definitely more polished than the ppedit test app.

I can't seem to get Spiro working with FontForge, either*...but is does work with Inkscape! I gotta say, this is seriously sweet. I'm doing my MFA thesis on type design for e-paper, and this is going to help a lot. Kudos!

@ exfish: I had that problem with an earlier release, but it was cured on the next month's build. Make a note of the issue (specifying your system specs and OS version along with the FF build version) on the fontforge-devel mailing list and George will fix it, or at least tell you what to do.

Hello Raph,
I'm little bit confused by FontForge's tutorial on Spiro's http://fontforge.sourceforge.net/editspiro.html.
I also compiled the ppedit. But there's no tutorials/docs.
Is the only way for me to understand these 6 operations is actually to read the code?
Thanks.

I've been using a somewhat different technique than what is described in the Fontforge/Spiro tutorial. It involves a lot of switching back and forth between Spiro and Bezier drawing modes. The knife tool behaves unpredictably and the alignment tools are disabled in Spiro mode. Since I build letters with a lot of cut-and-paste, that sort of behavior is a hindrance.

I suppose I should write my own tutorial once I figure out exactly what I'm doing.

There is one simple curve I can't represent very well using Spiros in Fontforge
I've tried using fontforge.spiroLeft and fontforge.spiroRight to enter and exit curve but it doesnt seem to draw a perfect circle. It seems more like logarithmic curve.

I'm not a spiro expert by any means, but:
- Try putting an extra point in the middle.
- There's no such thing as a perfect circle, except the
actual circle equation; any other form of equation is
necessarily an approximation.

@dimitre: No, there's no easy way to do this in Spiro. The underlying math can do it, no problem, but I deliberately simplified the UI so there wouldn't be huge numbers of point types representing the different constraints. Christoph Knoth at ATypI suggested adding one more point type, which would be an extremum point - it would function similar to the curve point, but force the tangent to be a multiple of 90 degrees.

One way you _can_ do it is to set points 1 and 2 to be corner points, and put an additional point on the arc, but that doesn't guarantee continuity.

@Hrant Spiro can represent exact circles. Beziers can't, so in the conversion to Bezier you get an approximation, but of course it can be a highly precise approximation.

Hi @raph Thanks for the detailed answer.
Let me ask you something, Did you build the Nodebox Cornu extension or were the Nodebox guys? It would be amazing to be able to use different kinds of Spiro points there.
I want to make an ppedit alike editor with a tight grid.

About ppedit, after saving I can't find the plate file in OS X 10.7
Cheers,

@raph: Christoph Knoth at ATypI suggested adding one more point type, which would be an extremum point - it would function similar to the curve point, but force the tangent to be a multiple of 90 degrees.

This would be fantastic! One of the difficulties I've had in using Spiro for type design is the lack of control over extrema. This is particularly troublesome when converting an existing design into outlines or trying to match specified metrics.

These four conditions balance the four degrees of freedom a general Spiro segment has. Do these seem like the right conditions? I think it should be pretty straightforward to extend your solver to include this type of point.

I discovered this thread when seeking information about one of the earliest computer-based type design tools.

It was mentioned in a standard type design textbook, so I'm sure many here have seen it. A single Archimedian spiral was seen as sufficiently general that it was the only tool the system offered, playing the same role as Bezier curves in today's digital type formats.

Quadibloc, according to yester lore, the AM Varityper worked with this spiral thingy -- their salesman told me this so it must be true ;-)
If I had salvaged one of its 8" font disks I would have tried to see what sort of format its fonts were stored in. Oh, and if I could attach an 8" disk drive to my system, of course.

It Was 1989 ("my thoughts were short, my hair was long") and the bosses' son returned from the US of A with two "laser printers", one from HP and the other one from a small but determined firm called "Apple", sporting an actual programming language ("PostScript", I recall). Soon after that, we abandoned AM -- just like pretty much the rest of the typesetting world.