Generating shapes starting from the counters - an experiment

daniele capo17 December 2009 · 10:39

I want to describe an 'idea' I had for a tool to be implemented.

The idea is to have a tool for generating shapes in that order:
you give the tool a 'counter' an a set of 'rules'
the tool apply the 'rules' to the counter and generate the final shape.

In the image below the rules are represented as vectors that map points on the inner contour to points on the outer contour. If the rules are changed the outer shape change, accordingly, if the 'counter' is changed the same rules generate another shape (in my image you see the difference of scaling the counter and scaling the resultant shape.)

To test the concept I've written a script (too ugly to show) in python and, using fontforge (as a python module), I generated a 'font' (actually three letters: I'm lazy).

The script roughly performs the things I've described (it takes a shapes – the counter – and a set of rules for each node, and outputs the glyph).
While I was trying to write this script I realized that everything could be parametrized, so that you can make changes manipulating 'meaningful' parameters. The 'rules' can be as well thought as functions that respond to inputs from that parameters, and at the end you have two elastic boundaries tied together by some law.

Ideally you can reuse a counter, transform it and attach new rules to define another glyph, etc.

Below you can see some test:
changing the 'offset' (i.e. changing the stem width)
changing the width of counters
testing for extreme cases (almost Klimax-esque)
changing the defined 'contrast' parameter (horizontal/vertical offsets)

Every variation required only one or two parameters to be modified.

Hrant H Papazian17 December 2009 · 12:53

This is extremely significant work.
Please take it as far as you can.

hhp

EColeman17 December 2009 · 14:51

Being code-illiterate, I have no idea what you just said, but it sure looks interesting.

Riccardo Sartori17 December 2009 · 14:58

Impressive.

Frank E. Blokland18 December 2009 · 01:40

The idea of applying (variable) vectors to counters (i.e. generating ‘counter points’) to represent (combinations of) certain contrast sorts (‘translation’, ‘expansion’, [‘transpansion’, ‘exlation’]), contrast flows (vector length, angle and rotation) and contrast as an alternative to the more traditional (and in some cases questionable) approach of applying the same effects to a ‘skeleton’ or ‘heart’ line is interesting, but also raises a few questions.

The three letters shown are simplified forms, because the counters don't provide any information about the stems top left. This seems to limit the possible variants to the presented ones. At the other hand there is the descender of the ‘p’, which is not described by the counter itself. I am also curious about how letters with multiple counters , like ‘a’ and ‘e’ will be handled by this system.

The counter oriented model also seems to exclude serifs by definition, and assuming that serifs are an indicator/representation of the contrast sort, contrast flow and, of course, the contrast (not to mention the relation to the ‘stem interval’), this seems to limit the system to letters with low contrast. The relatively high contrast pointed pen (‘expansion’) variants (bottom left) require for instance serifs in my opinion.

daniele capo18 December 2009 · 02:01

Ok, now I made some observation about this.
First: the idea came in my mind while I was reading Smeijers Counterpunch
To make things clearer (I suspect that one thing that makes my writing unclear is my funny english): what happens if drawing a glyph you are forced to draw the 'counterpunch' first?
Moreover, what if you the only thing you can really define is the counterpunch itself? Now you have a shape (te counterpunch) and you need to draw something around it in a different way. I discovered that you can do that by saying: move this point on the counter in such a way, move the other point etc.

This is what I meant with the first image. The inner shape is the counterpunch and the arrows are the displacements that 'generate' the outer contour.

(I call the displacements "rules" because I needed to generalize the concept.)

Then I realized that this kind of constraint (drawing the counterpunch and then defining displacements to generate the other contour) was very useful to define a parametric glyph.
For example, the displacement of the lateral point of the counter of lowercase o is related to the weight of the glyph. And the displacement of the points in lowercase n, define the 'stem'. And the relation between the two displacement I mentioned is the difference of straight line to curves etc.

Second:
At this point for me there is a conceptual problem: because if you 'parametrize' something you have to parametrize almost everything (the reason is clear when you think at the relation between horizontal and vertical: if the horizontals change with the verticals, you can: a. change the height of the counter (i.e. parametrize this as well) or b. change the x-height of the glyph.)
But this move blurs the difference between drawing glyph in this way and drawing the usual way (again, the vertical proportions problem)

Third:
This tool is very impractical since you can do the same thing with interpolation etc. Moreover I really cannot see any way to trasform my awful python script into something more functional, like a software with a graphic interface etc. (here the problem is also being a really unskilled programmer).

daniele capo18 December 2009 · 02:25

Thanks for you comment Frank,
I drawn the simplified shapes because it is much easier :) but I made also other experiments with serifs etc:

When I said that every point in the counter is mapped to a point in the contour I was imprecise: you can generate 0, 1 or even more than one point, i.e. you can attach more than one 'rule' to a point.
But this way of defining descender and ascender is impractical: In the examples I used more than one "counter" (notice also that I have closed and open counters), the descender being a line (this is cheating I know).

To draw serifs I decided to also have simple contour (parametrized as well) that I can attach to the glyph (again this is cheating.)
(Yes, the glyphs have overlapping contours at the end, but my 'tool' is just a way to experiment, not a way to really draw a real font)

edit: you can see the overlapping in the images.

Being a piece of software you can also write a conditional statement to attach serifs when, for example, the contrast is greater than a threshold.

Bendy18 December 2009 · 03:27

I like the idea of starting font construction from the counters and I also like the way this results in quick and basic glyph shapes that can be developed.

It looks like you are also able to determine the angle of contrast by including a rotation in the algorithm on your last image?

Can you show an example of what happens with other letters?

Paolo Mazzetti18 December 2009 · 09:29

I think that by trying to define everything starting from counters you probably end up with very impractical results, as you already noticed.

In this sense I don't see the other workarounds as cheating but as different solutions that may be needed by the system (if you're looking for the development of a handy tool, of course).

daniele capo5 January 2010 · 08:23

Ben, Paolo,
I've made other experiments with relative rotation and with lowercase 'a' (a rather complex letter).
Rotations are easy, the big problem is when you have serifs and 'multiple' counters, but it is interesting because this 'force' you to see things from a different angle.
I'm not sure if it is a way to draw quickly, you have to carefully 'plan' your shapes, maybe avoiding curves…
I'm still trying to imagine how to (and if) develop my 'tool'.

aric5 January 2010 · 12:17

This is fascinating. I'm looking forward to seeing how this develops. Thanks for sharing.

Sindre Bremnes2 February 2010 · 04:04

I second all the good things said about your experimentation. (I saw this thread only now.) I hope you're still working on this, you may have begun a piece of very valuable work.

Christopher Tim...2 February 2010 · 07:03

@ MiseEnAbime: Can you project how long it would take you to design a complete set of characters?

@ All type designers: Is this number more or less that your averaged estimates to complete the same task.

daniele capo2 February 2010 · 07:22

Christopher: I'm not able to make an estimate of the time to make a complete set of characters, I can imagine that the usual process with interpolation etc. is (and will be) faster than trying to parametrize everything 'by hand'.

Sindre: This project is 'in pause' but I really want to work again on it.

Hrant H Papazian2 February 2010 · 08:46

Christopher, the intentions of that train of thought are admirable; but the practical dimension of it is non-existent.

Daniele: This is the sort of thing that I feel requires pauses, even hibernations.

hhp

daniele capo2 February 2010 · 09:25

I understand it as a way of testing concepts and their limitations.

Christopher Tim...2 February 2010 · 10:16

I am not a type-designer, but practically I think there could be massive benefits. If a type designer could articulate the "permissions" or aspects of a typeface to a developer such as Daniele through the design of a few key glyphs, who could then develop an algorithm to produce an entire character set, production time (and profits as a result) could improve significantly. Granted, there would need to be some review and tweaking by the type designer.

If we wanted to be altruistic, we could pass the cost-savings back to our clients who could then re-invest their resources into other things like solar panels.

I have a small amount of experience collaborating with a python developer in an effort to design a typeface so I know it's possible, but I am not familiar enough with the business of type design to know it it is actually practical (or profitable) but you never know until you try.

Regardless of it's potential practicality, I think it worthy of exploration. I look forward to the results.

(does anyone know of typefaces produced by automated processes?)

Hrant H Papazian2 February 2010 · 10:42

I would consider the Knuth "augmented skeletons" approach a form
of automation. Of course complete automation would require AI! :-)

hhp

Christopher Tim...2 February 2010 · 11:49

Knuth "augmented skeletons" approach