Thoughts and examples of collaboration in the type design process?

[abattis]

This topic was imported from the Typophile platform

I had a discussion mainly with John Hudson about the potential for collaboration in the type design process over on the technical OpenType mailing list a while ago, and promised to bring up the subject here on Typophile, and then became busy with other things.... But I was reminded of this when Thomas Phinney recently wrote:

"As noted previously, one key difference between Linux and a typeface in an open source perspective is that the latter can benefit from contributions from lots of people, and the former will not work if too many people are working on it."

I'm not sure this is true, because I've not yet heard of anyone trying to do a collaborative type design process with many people involved, and failing.

Still, I'd be very interested to here people's good and bad examples of collaboration in the type design process at any scale.

Most type designers who work as individuals seem to collaborate with a font developer on the actual production of the final files that users have on their computers, and small foundries seem to share both the design and production around a bit between their overall group.

Has anyone had a great internship doing the "unglamourous" work of 'filling out' character sets?

Or mentored an "appentice" in that way? :-)

I would guess that, before the MA courses that are now so popular, this was the way that most people learned digital type design...?

Best,
Dave

[chrisherron]

Recent Collaboration: Adrian Frutiger & Akira Kobayashi: Avenir Next and Frutiger Serif

[Si_Daniels]

>Still, I’d be very interested to here people’s good

Most East Asian language fonts, Sakkal Majalla (Windows 7 version)

>and bad examples of collaboration in the type design process at any scale.

Deja Vu

[Jongseong]

I would be inclined to agree with Dave in that type design has historically been a collaborative process. Isn't it only thanks to the Digital Age that a single individual can hope to create a whole typeface from start to finish? Even now, I most CJK typefaces are produced through collaboration, as they require thousands of glyphs.

However, this needs to be a strictly controlled variety of collaboration. A single creative vision must be applied consistently throughout the design. This might be achieved by having a single individual make the creative decisions and leaving the rest to do mechanical work, or by having a small group of individuals closely discuss the creative decisions they make throughout the process. I believe the latter option describes many of the more recent collaborations, such as that for Meta Serif.

I think Thomas Phinney might have just wanted to make the point that Linux-style decentralized, democratic collaboration would not work for type design.

[Si_Daniels]

>I think Thomas Phinney might have just wanted to make the point that Linux-style decentralized, democratic collaboration would not work for type design.

But, it could work if there were a strong man / dictator / figurehead who could pass judgment, accepting or rejecting the submissions from the proletariat - however I doubt the people in the industry best suited to that role would be interested.

[Thomas Phinney]

I hope that my later comments made it clear that what I think is that with more people working on a typeface, more structure and central vision is needed. Type design and production is poorly suited to a free-for-all approach like wikipedia. I do think one *could* have a bunch of people collaborate to make something that is ultimately released in FOSS form, and have it be really well done.

My own Hypatia Sans had kerning done by Robert Slimbach and Miguel Sousa, major production assistance from Miguel, and is going to have the finishing touches on the italics, plus some character set expansion, from Paul Hunt.

Cheers,

T

[abattis]

@Sii and chrisherron: Could you describe how Avenir Next and Frutiger Serif and Sakkal Majalla were developed in more details, or links to articles on such? :-)

@sii: And what is unfortunate about Deja Vu's modifications to Bitstream Vera? :-)

@Jongseong: I'm not aware of any type designs that have come about through decentralized, democratic collaboration, so I'm not convinced it would not work at all. Deja Vu is an existing type design, so its a different animal, too.

If the first type designs that are done in this way turn out to be low quality, I look forward to thinking about and discussing the design of their design process. I note that before the mid 90s (now well over 15 years ago, a long time...) programmers used to say the same thing about incredibly complex programs like kernels, before the Linux kernel project proved them wrong.

[Si_Daniels]

>@sii: And what is unfortunate about Deja Vu’s modifications to Bitstream Vera? :-)

Quality control, fragmentaion, and lack of ongoing involvement from the original designer. So perhaps I should have said Vera instrad of Dejavu.

>@Sii and chrisherron: Could you describe how Avenir Next and Frutiger Serif and Sakkal Majalla

Nothing published on Majalla as far as I'm aware.

[abattis]

@Thomas Phinney: Thanks for the detail about Hypatia; I like the design :-) When you say Miguel did major production assistance, did he collaborate on the design of the outlines? And could you clarify if when you say kerning you mean only kerning, or the generic metrics too? :-)

And I must apologise if you feel quoted out of context; thanks for your clarification and encouragement - I was happy to see that you're open to consulting on these kinds of projects, and I hope one day a "Free Font Foundation" might be able to take people up on that kind of offer :-)

Type design and production is poorly suited to a free-for-all approach like wikipedia.

Since wikipedia is a collection of many pages, like the open font library is a collection of many fonts, IMO a better comparison is between a type design and a wikipedia page.

Wikipedia pages tend to have maintainers who patrol for poor quality additions, and trim them out. This means sometimes people come across pages before they are trimmed, and end up writing in their newspaper that "This football club wears hats of old shoes" ;-)

Free programs are not developed "live" like this, though. A free program has a life cycle from an cutting edge, experimental sideline source code version, to a "mainline" source code version, to an experimental "alpha" pre-compiled binary version, to a testing "beta" binary version, to a stable "release" binary version, to being obsolete.

With Wikipedia pages, there is only the cutting edge version, and this is why the Wikimedia Foundation has discussed publishing a 'stable' version akin to the way free programs are released.

For programs, the life cycle before the pre-compiled binary versions is not linear like the part that follows, though: Wikipedia's is faily simple - no 2 people can edit the same page at the same time, for example.

But with distributed version control, there is an official/golden/master or 'trunk' copy of the source code, and each developer makes a complete copy of this, a 'branch.' They change their branch however they want to, and then they publish the branch for others to compare with the trunk. Another developer might maintain a branch that collates a number of different, non-overlapping branches with some theme. The maintainers of the master copy can choose to integrate any set of branches as they like.

If someone makes changes that aren't accepted into the 'trunk,' they are already publishing their own version. So if the maintainers misjudged it, and that version is actually more useful for people, its already available, and so it comes into use quickly - and likely causes the maintainers to re-evaluate it.

To make this visual, http://oandrieu.nerim.net/monotone-viz/Screenshot-git-viz.png shows two branches, the column on the left being the 'master' trunk, the right side col being the 'experimental' branch, and the trunk twice merging in the branch, that continues to develop in parallel.

This is how Sii's comment about a maintainer who "passes judgment" works in practice.

@Sii: Yes, people whose business models depend on the source code being secret probably won't participate. But people with business models that depend on source code being public probably will. I certainly hope that when those business models are proven, we'll see people change from one way of doing business to another :-)

[Si_Daniels]

>@Sii: Yes, people whose business models depend on the source code being secret probably won’t participate.

Actually no, I wasn't thinking of those folks. I was thinking of people who have a proven record of coordinating large projects using paid type designers, engineers, and hinters. And who probably wouldn't work for free themselves (not to say they don't give to the community in other ways), wouldn't expect others to work for free, and wouldn't have the patience to work with a group of amateurs or even professional volunteers.

[abattis]

@Sii: Work for free? Who is suggesting this? I'm not :-)

[Si_Daniels]

>@Sii: Work for free? Who is suggesting this? I’m not :-)

Perhaps, but no one is suggesting a framework that would include paying people.

[Thomas Phinney]

Sii: I think you're making an assumption about the background for the question. This isn't the thread solely about open source fonts. :)

Dave regarding Hypatia Sans: To the best of my memory, With the exception of the "hook" accent for Vietnamese, for which Robert did the outlines, I did all the outline work, and all the sidebearings (but with a *lot* of verbal input from Robert on both). Miguel did a lot of work setting up scripts, revised my feature coding, did actual builds using scripts plus the AFDKO, and generally patrolled my work to make sure I didn't miss anything. Plus the "small matter" of kerning, which Robert and Miguel collaborated on and I pretty much didn't touch, except to suggest a couple of additional things that needed to be covered.

Regarding the free-for-all development approach....

I am not sure whether a single Wikipedia page is a good analogy for a font (or font family) either. Maybe a set of related pages? But in any case, speaking as somebody who does both writing and font work for money: I am pretty sure that an open free-for-all model is a crappy model for developing high-quality fonts; even though I enjoy participating in Wikipedia, I am pretty sure I would be frustrated by that same model for font development.

One major problem with that model for fonts is that it's harder to judge the quality of an edit/contribution in just a few seconds, the way one can on Wikipedia. How do you "diff" the changes? If what has been changed is a sidebearing, you need to see it in context of other sidebearings. If it's an outline, you need to both see the previous outline *and* in many cases compare against other outlines.

Then there's the ripple-through problem. If somebody changes the design of the cap "R" in the regular, it probably needs to be changed in all the other weights and the italics too... and maybe have kerning adjusted as well.

I think it would be an interesting open-source project to devise a set of tools/scripts or what-not just to better *enable* type design collaboration by addressing those two issues.

Cheers,

T

[Si_Daniels]

>This isn’t the thread solely about open source fonts. :)

Sorry I was specifically responding to questions about Linux-style decentralized, democratic collaboration which by definition means unpaid volunteers are involved at some levels of the effort.

[abattis]

@Sii: Unpaid volunteers are involved at some levels of the effort to write the Linux kernel, yes. Off the top of your head, what would you guess the percentage is? :-)

@Thomas Phinney: That's interesting details indeed about how the collaboration in Hypatia actually breaks down :-) I 100% agree with you that font development tools with collaboration-specific features are required - this is what I meant when I said "the design of the design process" earlier.

Its too bad that these features aren't seen as desirable by mainstream type designers, and there is no existing practice to examine.

Your concept of the 'ripple through' problem is a great insight - I wonder if you think the ideas behind font synthesis tools like Ares Font Chameleon would help? I saw [[http://www.thomasphinney.com/about/about-long-version/on your new blog you mentioned you held some software idea patents about "glyph synthesis". Are those patents published online anywhere? :-)

Has anyone got access to Ares Font Chameleon and could post some screencasts? Or is (going to be) in Europe, as I'd love (to hang out and) see it in action :-)

[abattis]

@sii: Thousands of companies' profits are based on things that are freely sharable and modifiable, so perhaps no one needs to suggest a framework that would include paying people, when plenty of frameworks are visible to anyone who cares to look? :-)

[Si_Daniels]

I'm not sure why you're giving me a hard time. :-)

I was disagreeing with an interpretation of Tom's claim…

"I think Thomas Phinney might have just wanted to make the point that Linux-style decentralized, democratic collaboration would not work for type design."

By stating that it could work with a "strong man" in charge.

I still stand by my claim that the people best suited to the strong man role have no interest in it, and would likely have no interest even if they personally were paid. However, this is all academic as no one is stepping forward to pay them.

I'm completely happy to be proved wrong. I'd love to see funded projects, and I'd love to see the leaders in type community run them. It would be extremely fun and entertaining to watch.

[abattis]

@Sii: Sorry I seem to be giving you a hard time, that's certainly not my intention! :-) I agree with your 'strong man in charge' idea - free software projects work like that anyway, such as the Linux kernel and Linus Torvalds, or Python and Guido van Rossum, or the Ubuntu GNU/Linux distribution and Mark Shuttleworth.

Although, I do think that this phrasing of the idea gives the wrong impression; the free software community uses the term 'package maintainer,' which implies a more accurate picture of consensus and harmony rather than conflict and force.

And I agree this is academic and speculative topic, which is why I hoped to discuss examples of collaboration in some detail :-)

My question about your guess at the ratio of paid to unpaid work in the Linux kernel relates to your point about type professionals not wanting to work as maintainers even if they were paid, which I don't understand, and hope you can clarify.

I would have estimated it was 20%, but after spending the last while researching it, it seems its actually 10%. So I think thats a good ballpark figure to suggest that a paid-up, collaborative, libre font project would involve "a group of amateurs or even professional volunteers ... involved at some level of the effort" - say, 10-20% of the effort.

Since type design is a patient activity, I wonder if you could explain why you think the patience of working at a type design on your own is less frustrating/needing-patience than working collaboratively? :-)

I would agree that the unsuitability of current font development tools means it is frustrating. But since I'm familiar with working collaboratively with plain-text tools, and that process isn't frustrating - though surely different to writing alone - I see no reason collaborative type design would require unreasonable levels of patience if the tools facilitated it.

Since you say it would be extremely fun and entertaining to watch such projects develop, do you agree that its the available tools that are the problem? Or is there something else inherent in the process of type design that I'm missing?

I'm very much a beginner at type design, so I can't tell :-)

[Jongseong]

Since type design is a patient activity, I wonder if you could explain why you think the patience of working at a type design on your own is less frustrating/needing-patience than working collaboratively? :-)

I would venture that people who care enough about type design to put in the huge amount of time and effort are also more likely to seek creative control over their work. I don't know much about the free software community, but I suspect the contributors wouldn't be quite as hung up on maintaining their own creative vision.

Earlier, you said you weren't convinced that type designs that have come about through decentralized, democratic collaboration would not work at all, as you haven't seen any examples. I'm not sure such designs can even exist, since competing creative visions will be hard to reconcile without central direction, and the result will hardly be coherent enough to stand as a typeface design.

I'm still trying to understand how you picture this would work. Perhaps A designs some of the letters, B comes and contributes a couple, C comes and tweaks some of the existing letters done by A and B, D comes and fills out the remaining letters, A comes back and retweaks the letters... How would design consistency be maintained over this whole process when A, B, C, and D will have differing creative visions? Unless the collaboration process takes place at a different, well-defined level (i.e. someone designs the basic glyphs, another adds diacritics, yet another takes care of the naming and production), I just don't see a coherent typeface coming about as a result.

Just so you understand, I would love to see a workable collaborative model for type design set up, as it would make type design more approachable for people who are intimidated by the prospect of taking on the entire process by themselves. I am just trying to point out how it might not work, as I'm not convinced the open software or Wikipedia models of collaboration will translate to the type design process.

I see a modular approach as being necessary for successful collaboration. It could go like this:

A designs the basic lowercase and uppercase alphabet.
B designs the numerals to harmonize with the alphabet.
C and D design punctuation and diacritics to fill out the basic character set.

Throughout, the designers give each other feedback, but rather than freely editing one another's designs, allow the original designer to incorporate the others' suggestions in modifying his or her design. A sort of creative director over the entire project may come handy if there are disagreements over creative direction. Constant cooperation would be required just in order to maintain consistent spacing and design detail for the characters.

Later on, teams consisting of the same members or new ones could add italics, different weights, expand into different writing systems, etc. using this modular approach.

In practice, it would be more efficient were these modules to be combined where possible; it is easier to get a consistent result with a single designer working on all the glyphs of the basic character set rather than with multiple designers. But then people might be more willing to contribute if the workload is less. The trouble would be to determine which contributors are competent enough and to maintain a high standard of design throughout the modules. This doesn't look to be at all easy.

[bemerx25]

Here's something that was done collaboratively - letters were designed by the crowd and submitted via email:
http://www.bittbox.com/freebies/bb-free-font-conglomerfont/

In any case, a benevolent dictator (read "manager") is needed to ensure a final, serviceable product. Although I suppose a team of managers would also work as long as there was an overarching and agreed upon vision.

[Si_Daniels]

>Since you say it would be extremely fun and entertaining to watch such projects develop, do you agree that its the available tools that are the problem? Or is there something else inherent in the process of type design that I’m missing?

No I don’t think it’s a matter of tools. Managing large collaborative font development projects is hard for a variety of reasons, even when everyone involved is employed by a single company, with a clear spec, with set milestones and deliverables. I think adding the prospect of including many unpaid, part-time resources to such a project would make it even more difficult, and unappealing, and somewhat outside the comfort zone of the people best suited to running such projects.

One alternative option might be to have a trinity of strong-men run the project… “the father” an upstanding leader from the type world as the figurehead, “the son” the person who does all the actual co-ordination passing the work to the father to be blessed, and the “holy ghost” someone from the OSS world who can ensure all the OSS religious rites are adhered to.

[dberlowgone]

"Isn’t it only thanks to the Digital Age that a single individual can hope to create a whole typeface from start to finish?"
I don't think so, as both metal and film fonts were created individually for decades. Manufacture changed in the digital age and distribution changed in the internet age. Specification has apparently changed in the idiot age.

"It could go like this: A designs the basic lowercase and uppercase alphabet. B designs the numerals to harmonize with the alphabet.
C and D design punctuation and diacritics to fill out the basic character set."
Geeeeeze. Can three women have a baby in 3 months now because of technology?

Cheers!

[Reed Reibstein]

Collaboration in action thanks to Typophile, apparently: Open Baskerville.

[Thomas Phinney]

Two things:

I think that lack of good tools/workflow for collaborative type design is a problem, but absolutely not the *only* problem for such an effort.

I think I disagree with Si that none of the people who could reasonably be master architect of such an effort would be interested, even for pay. However, I'll believe that perhaps *most* of the people who could do so would not be interested.

Cheers,

T

[minombresbond]

I know 'proyectodemo'

http://www.proyectodemo.cl/blog/

This is not 'open source type design' project at all, but is a collaborative 'game' when many Argentines and Chileans recognized typographers worked in a font design, the 'football typo match' lasted 8 weeks

Probably these designers never heard about 'open source / collaborative font design', but I do not think that is an eccentricity suggests the possibility of collaborative projects like this in the FLOSS context if some typographers are interested, the internet promote spontaneous collaborative projects all the time..

proyecto demo team

Árbitro Andreu Balius

Chile
Francisco Gálvez (DT)
Rodrigo Ramírez
Tono Rojas
Kote Soto
Luciano Vergara
Felipe Cáceres

Argentina
Alejandro Paul (DT)
Eduardo Tunni
Alejandro lo Celso
Eduardo Manso
José Scaglione
Pablo Cosgaya

http://www.proyectodemo.cl/blog/?page_id=3

¿por qué demo? (why Demo?)
[...]
3.- Demo, de demostrar que es posible juntar a un grupo de amigos, ¡simplemente para pasarlo bien, haciendo algo que nos gusta!

(3- Demo, from 'demostrate' that is possible to gather a group of friends, Just for fun, doing something we love!)

many open source projects started as fun and ended up as business...

saludos!