osp blog - conversations

Up Pen Down — Huppe plume tonne

2015-08-07T18:54:00+02:00

Announcing Up Pen Down — Huppe plume tonne

a workshop and preformance during the Quinzaine Numérique 2015:

specifics of the workshop are on their way, but for now, here is the introduction text:

En 2012, OSP (Open Source Publishing) construit un workshop de plusieurs mois avec des étudiants de l'École Supérieure d’Art et Design de Valence. La proposition au centre des tables s'intéresse en détail au «trait», dans le sens de «chemin» (path en anglais) par opposition et en dialogue avec la notion de forme. Si ce point de départ offre plusieurs perspectives — celles du dessin, de la typographie, de la cartographie — ce «chemin» pose aussi la question des outils et en particulier des outils numériques, et de leur relation avec le langage visuel.

Il y a trois ans donc, des étudiants en design graphique, en typographie et nous-mêmes sont amenés par le trait à la performance. Aujourd'hui, nous allons réitérer l'expérience en modifiant le chemin de l'apprentissage. Nous proposons un workshop d'expérimentation permettant deux approches :
– pour les participants avec une expérience graphique, s'intéresser à produire du lettrage par des mouvements à échelle du corps;
– pour les participants avec une expérience chorégraphique, s'intéresser à la manière spécifique par lequel le dessin (down) et le non-dessin (up) questionne le mouvement et ses différentes échelles;

Nous chercherons à nous intéresser spécifiquement à une série de questions, et aux spécificités qui y répondent.

La chorégraphe et danseuse Adva Zakaï nous accompagnera dans ce travail de débroussaillage. Son travail de recherche fondé sur l'hypothèse que le corps mute progressivement en texte numérique, et que le numérique mute en retour au contact intime des corps.

OSP @ Princesse!

2014-09-29T15:56:00+02:00

Since the early days, OSP has changed form over and over, from asking simple questions right through to organizing week-long workshops to share answers its members have found.

There have been a fair amount of turning points in the past, and some of the biggest ones have happened over the last few years. The Variable residency was certainly an interesting step, it brought in means to extend and collaborate in an environment that called for growth on the personal and group level. The three years in Variable were key in making OSP what it is today, but not only OSP, all of the Constant research experiments have taken from the shared house and gone forth.

Variable went out on a big bang with Relearn 2014 but all good things come to an end. We were all extremely happy, and we left with as many plans as questions for what the next steps would be. Even before leaving Variable, we knew of the forthcoming F-LAT project and other ideas regarding the maintenance of the Brussels (whatever that means) FLOSS network of people. It's going to be yet another exciting year!

For OSP, it was clear that we enjoyed the idea of a studio space and wanted to follow up on that, so after a few weeks of searching we found a perfect fit in the old Hackbase.be working space. Hackbase is still moving into a new directions, but thanks to them, we're equally happy with the space and its history (and its unremovable shelves filled with old computer gear from all eras!). OSP has a new home.

There certainly is still a lot of work to do there, but we're very happy. The added bonus is that it's only a few streets away from the re-purposed Variable building, so we're not too nostalgic.

The caravan is also in the process of setting up its own fully fledged legal structure (in its own name) as a non profit organisation, or ASBL as they say in French. As soon as we're up and running, we'll have you all over for a studio-warming (even though we can't, at this point guarantee the room temperature) party, Loop events, and any other reason too!

Av. Princesse Elisabeth 46

Schaerbeek Brussels

Welcome!

Visual Culture and Médor at Europe Refresh

2014-09-29T15:51:00+02:00

Once again Les Halles are housing the 2014 edition of «Le salon du financement participatif» called Europe Refresh and it looks like it's going to be a couple of exciting weekends!

This year, to maximize the chances of fully funding the projects, the Salon will be set up for a weekend in Brussels then a weekend in Paris.

We're very happy to be attempting two big projects this year: Visual Culture and Médor.

Visual Culture

is the name we've given to the tool that we're building to share and publish any (design) project with the possibility to see and retrieve any previous version. Its current form is what constitutes OSP website's home page, and it makes up the exploratory system enabling navigation into each repository OSP uses.

http://osp.kitchen/tools/visualculture/

Médor

is not a dog! It's a trimestrial, Belgian magazine of inquiries and stories, 128 pages long. Médor contains long-term investigations, reports and portraits focused on Belgium. Médor digs the heart of issues. It inquires and it is persistent. It takes the time needed to be further, beyond appearances. It seeks to understand the facts and to give opinions about uncovered truths. Médor launched this week and is planning several methods to get the project fully financed. See the current progress on the website:

https://medor.coop/

See you there?

Médor

2014-09-29T12:49:00+02:00

Medor is not a dog !

It's a trimestrial, Belgian magazine of inquiries and stories, 128 pages long. Médor contains long-term investigations, reports and portraits focused on Belgium.

Médor digs the heart of issues. It inquires and it is persistent. It takes the time needed to be further, beyond appearances. It seeks to understand the facts and to give opinions about uncovered truths.

Médor intends to cultivate the pleasure of reading and to inform while entertaining. Médor's journalists make sense of current events and are proud and passionate about their work. Today the profession of journalism is threatened by job pressures that erode the search for meaning and by small news items that jostle the priorities of the press.

So Médor aims to reinvent the mechanisms which produce information. Médor is innovative and differentiates itself through its creative process as well as its editorial line. It invents its own, suited ecosystem : original, free style graphics ; teams of journalists and graphic designers or photographers who work together in pairs ; collective decision-making ; rotating chief editors ; readers organized in a co-op ; and decent salaries for all.

It functions with a horizontal structure and open-source software, pays everyone, print on FSC (ecolabel), guarantees transparency, independence, etc.

Join Médor on the full website: medor.coop

étapes 220

2014-09-29T12:44:00+02:00

étapes magazine issue 220 focused on Co-Working, so we were pleased to be asked for an interview for the Portrait section of the publication.

In proper OSP fashion, after an initial set of questions from Caroline Bouige, the interviewer, we answered collaboratively, both to the questions and to each other.

You can read the full Q&A up on http://osp.constantvzw.org:9999/p/etapes

For the full article: http://etapes.com/etapes-220

Our friends from Libre Objet were also featured in this issue, so grab yourself a copy!

Meaningful Transformations

2012-01-12T12:20:00+01:00

A conversation with Tom Lechner

We discovered the work of Tom Lechner at the Libre Graphics Meeting 2010 in Brussels. Tom has traveled from Portland, US to present Laidout, an amazing tool that he made to produce his own comic books and also to work on three dimensional mathematical objects. His software interests us for several reasons. We are excited about how it represents the gesture of folding, love his bold interface decisions plus are impressed by the fact that Tom has decided to write his own programming framework for it. A year later, we meet again in Montreal, Canada for the 2011 Libre Graphics Meeting where he presents a follow-up. With Ludivine Loiseau (amateur bookbinder and graphiste) and Pierre Marchand (artist/developer, contributing amongst others to podofoimpose and Scribus) we finally find time to sit down and talk.

Read the interview: http://blogs.lgru.net/ft/conversations/meaningful-transformations

Just ask and that will be that

2011-08-19T09:23:00+02:00

A conversation with Asheesh Laroia

Our conversation took place at the last day of the Libre Graphics Meeting 2011 in Montreal, a day after the panel 'How to keep and make productive libre graphics projects?'. Asheesh had responded rather sharply to someone in the audience who remarked that only a very small number of women was present at LGM: "Bringing the problem back to gender is avoiding the general problem that F/LOSS has with social inclusion". This statement asked for an explanation.
Another good reason to talk to him are the intriguing 'Interactive training missions' that he has been developing as part of the OpenHatch.org project. I wanted to know more about the tutorials he develops; why he decided to work on 'story manuals' that explain how to report a bug or how to work with version control.

Asheesh Laroia is someone who realizes that most of the work that makes projects successful is hidden underneath the surface. He volunteered his technical skills for the UN in Uganda, the EFF, and Students for Free Culture, and is a Developer in Debian. Today, he lives in Somerville, MA, working on OpenHatch.org. He speaks about his ideas to audiences at international F/LOSS conferences.

Also available at Future Tools.

Bending culture
Asheesh Laroia (AL): The Interactive training missions are really linked to the background of the Open Hatch project itself. I started working on it because to my mind, one of the biggest reasons that people do not participate in free software projects, is that they either don't know how or don't feel included.
There is a lot you have to know to be a meaningful contributor to free software and I think that one of the major obstacle for getting that knowledge, and I am being a bit sloppy with the use of the term maybe, is how to understand a conversation on a bug-tracker for example. This is not something you run into in college, learning computer science or any other discipline. In fact, it is an almost anti-academic type of knowledge. Bug tracker conversations are 'just people talking', a combination of a comment thread on a blog and actual planning documents. There's also tools like version control, where close to no one learns about in college. There is something like the culture of participating in mailing-lists and chatting on IRC... what people will expect to hear and what people are expecting from you.

For people like me that have been doing all these things for years, it feels very natural and it is very easy to forget all the advantages I have in this regard. But a lot of the ways people get to the point where I am now involves having friends that help out, like "Hey, I asked what I thought was a reasonable question on this mailing list and I did not get any answer or what they said wasn't very helpful". At this stage, if you are lucky, you have a friend that helps you stay in the community. If you don't, you fall away and think "I'm not going to deal with this, I don't understand".
So, the training missions are designed to give you the cultural experience and the tool familiarity
in an automated way. You can stay in the community even when you don't have a friend, because the robot will explain you what is going on.

Femke Snelting (FS): So how do you 'harvest' this cultural information? And how do you bring it into your tool?

AL: There is some creative process in what I call 'writing the plot'; this is very linear. Each training mission is usually between three and fifteen minutes long so it is OK to have them be linear. In writing the plot, you just imagine what would it take a new contributor to understand not only what to do, but also what a 'normal community member' would know to do. The different training missions get this right to different extents.

FS: How does this type of knowledge form, you think? Did you need to become a kind of anthropologist of free software? How do you know you teach the right thing?

AL: I spend a lot of time both working with and thinking about new contributions to free software. Last September I organized a workshop to teach computer science students how to get involved in Open Source. And I have also been teaching inter-personally, in small groups, for ten or eleven years. So I use the workshops to test the missions and than I simply ask what works. But it is tough to evaluate the training missions through workshops because the workshops are intended to be more interpersonal. I definitely had positive feedback, but we need more, especially from people that have been two or three years involved in the free software community, because they understand what it feels like to be part of a community but they may still feel somewhat unsure about whether they have everything and still remember what was confusing to learn.

FS: I wasn't actually asking about how successful the missions are in teaching the culture free software ... I wanted to know how the missions learn from this culture?

AL: So far the plots are really written by me, in collaboration with others. We had one more recent contribution on git written by someone called Mark Freeman who is involved in the OpenHatch project. It did not have so much community discussion but it was also pretty good from the start. So I basically try to dump what is in my head?

FS: I am asking you about this, thinking about a session we once organized at Samedies, a woman-and-free-software group from Brussels. We had invited someone to come talk to us about using IRC on the command-line and she was discussing etiquette. She said: "On IRC you should never ask permission before asking a question". This was the kind of cultural knowledge she was teaching us and I was a bit puzzled ... you could also say that this lack of social interfacing on IRC is a problem. So why replicate that?

AL: In Debian we have a big effort to check the quality of packages and maintaining that quality, even if the developer goes away. It is called the 'Debian QA project' and there's an IRC channel linked to that called #debian-qa. Some of the people on that channel like to say hello to each other and pay attention when other people are speaking, and others said "stop with all the noise". So finally, the people that liked saying hello moved to another channel: #debian-sayhi.

FS: Meaning the community has made explicit how it wants to be spoken to?

AL: The point I am trying to make here, is that I am agreeing to part of what you are saying, that these norms are actually flexible. But what I am further saying, is that these norms are actually being bent.

Things that could be reasonable
FS: I would like to talk about the new mission on bug reporting you said you were working on, and how that is going. I find bug reports interesting because if they're good, they mix observation and narration, which asks a lot from the imagination of both the writer and the reader of the report; they need to think themselves in each others place: What did I expect that would happen? What should have happened? What could have gone wrong? Would you say your interactive training missions are a continuation of this collective imaginary work?

AL: A big part of that sort of imagination is understanding the kinds of things that could be reasonable. So this is where cultural knowledge comes in. If you program in C or even if you just read about C, you understand that there is something called 'pointers' and something called 'segfaults' and if your program ends in that way, that is not a good thing and you should report a bug. This requires an imagination on the side of the person filing the bug.
The training missions give people practice in seeing these sorts of things and understand how they could work. To build a mental model, even if it is fuzzy, that has enough of the right components so they can enter in discussion and imagine what happened.

Mixed feelings
AL: I have mixed feelings about using 'gender' as an important characteristic when considering how to grow our communities. It is not a bad idea maybe, and I am working on projects that are related to this as well, but I think it permits a misunderstanding of the problem and puts things in an awkward space, especially when the issue is addressed in a room primarily filled by men and only a few woman. Is what the men say sort of judge-able by the few women in the room? Are they speaking to the women that are not in the room? It becomes all very tenuous and confusing what you can or should say or do. We can skip this by understanding the real issue, which is community inclusiveness.

Of course when there are real issues such as groping at conferences, or making people feel unwelcome because they are shown slides of half-naked people that look like them ... that is actually a gender issue and that needs to be addressed. But the example I gave was: "Where are the Indians, where are the Asians in our community?" This is still a confusing question, but not awkward.

FS: Why is it not awkward?

AL: (laughs) As I am an Indian person ... you might not be able to tell from the transcription?

It is an easy thing to do, to make generalizations of categories of people based on visible characteristics. Even worse, is to make generalizations about all individual people in that class. It is really easy for people in the free software community to subconsciously think there are no women in the room "because women don't like to program", while we know that is really not true. I like to bring up the Indian people as an example because there are obviously a bunch of programmers in India ... the impression that they can't program, can't be the reason they are excluded.

FS: But in a way that is even more awkward?

AL: Well, maybe I don't feel it is that awkward because I see how to fix it, and I even see how to fix both problems at the same time.

AL: In free software we are not hungry for people in the same way that corporate hiring departments are. We limp along and sometimes one or two or three people join our project per year as if by magic and we don't know how and we don't try to understand how. Sometimes external entities such as Google Summer of Code cause many many more show up at the doorstep of our projects, but because they are so many they don't get any skills for how to grow.
When I co-ran this workshop at the computer science department at the University of Pennsylvania on how to get involved in open source, we were flooded with applicants. They were basically all feeling enthusiastically about open source but confused about how to get involved. 35% of the attendees were women, and if you look at the photos you'll see that it wasn't just women we were diverse on, there were lots of types of people.
That's a kind of diversity-neutral outreach we need. It is a self-empowerment outreach: 'you will be cooler after this, we teach you how to do stuff' and not 'we need you to do what we want you to do', which is the hiring-kind of outreach.

FS: And why do you think free software doesn't usually reach out in this way? Why does the F/LOSS community have such a hard time becoming more diverse?

AL: The F/LOSS community has problems getting more people AND being more diverse. To me, those are the same problems. If we would hand out flyers to people with a clear message saying for example: here is this nice vector drawings program called Inkscape. Try it out and if you want to make it even better, come to this session and we'll show you how. If you send out this invitation to lots of people, you'll reach more of them and you'll reach more diverse people. But the way we do things right now, is that we leave notes on bug trackers saying: “help wanted”. The people that read bug trackers, also know how to read mailing lists. To get to that point, they most likely had help from their friends. Their friends probably looked like them, and there you have a second or third degree diversity reinforcement problem.
But leaving gender diversity and race diversity aside, it is such a small number of people!

The How-To-Contribute page
FS: So, to break that cycle you say there is a need to externalize knowledge … like you are doing with the Open Hatch project and with your project Debian for Shy People? To not only explain how things technically work, but also how they function socially?

AL: I don't know about externalizing ... I think I just want to grow our community. But when I feel more radical, I'd say we should just not write “How to contribute” pages anymore. Put a giant banner there instead saying: “This is such a fun project, come hang out with us on IRC... every Sunday at 3PM”. Five or ten people might show up, and you will be able to have an individual conversation. Quickly you'll cross a boundary … where you are no longer externalizing knowledge, but simply treat them as part of your group.

The Fedora Design Bounties are a big shining example for me. Maírín Duffy has been writing blog posts about three times a year: “We want you to join our community and here is something specific we want you to do. If you get it right, the prize is that you are part of our community.” The person that you get this way will stick around because he or she came to join the community.

FS: And not because you sent a chocolate cake?

AL: Not for the chocolate cake, and also not for the 5000\$ that you get over the course of a Google summer of code project. So, I question whether it is worth spending any time on a wiki-page explaining “How to- contribute” when instead you could attract people one by one, with a 100% success-rate.

FS: Writing a 'How to contribute' page does force teams to reflect on what it takes to become part of their community?

AL: Of course that is true. But compared to standing at a job-fair talking to people about their resume, 'How to contribute' pages are like anonymous, impersonal walls of text that are not meant to create communication necessarily. If we keep focusing on communicating at this scale, we miss out on the opportunity to make the situation better for individual people that are likely to help us.

Patience is valuable
FS: I feel that the free software community is quite busy with efficiency. When you emphasize the importance of individual dialogue, it sounds like you propose a different angle, even when this in the end has the desired effect of attracting more loyal and reliable contributors.
AL: It is amazing how valuable patience is.
FS: You talked about Paul, the guy that stuck around on the IRC channel saying hi to people and than only later started contributing patches after having seen two or three people going through the process. You said: "If we had implied that this person would only be welcome when he was useful ... we would have lost someone that would be useful in the future".

AL: The obsession with usefulness is a kind of elitism. The Debian project leader once made this sort of half-joke where he said: "Debian developers expect new Debian contributors to appear as fully formed, completely capable Debian developers". That is the same kind of elitism that speaks from "You can't be here until you are useful". By the way, the fact that this guy was some kind of cheerleader was awesome. The number of patches we got because he was standing there being friendly, was meaningful to other contributors, I am sure of it. The truth is ... he was always useful, even before he started submitting patches. Borrowing the word 'useful' from the most extreme code-only definition, in the end he was even useful by that definition. He had always been useful.

FS: So it is an obsession with a certain kind of usefulness?

AL: Yes.

FS: It is nice to hear you bring up the value of patience. OSP uses the image of a frog as their logo, a reference to the frog from the fairy tale 'The frog and the princess'. Engaging with free software is a bit like kissing a frog; you never know whether it will turn into a prince before you have dared to love it! To OSP it is important not to expect that things will go the way you are used to ... A suspension of disbelief?

A: Or hopefulness! I had a couple of magic moments ... one of the biggest magic moments for me was when I as a high school student e-mailed the Linux kernel list and than I got a response! My file system was broken, and fsck-tools were crashing. So I was at the end of what I could do and I thought: let's ask these amazing people. I ended up in a discussion with a maintainer who told me to submit this bug-report, and use these dump tools ... I did all these things and compiled the latest version from version control because we just submitted a patch to it. By the end of the process I had a working file system again. From that moment on I thought: these magic moments will definitely happen again.

Just ask and that will be that

FS: If you want magic moments, than streamlining the communication with your community might not be your best approach?

A: What do you mean by that?

FS: I was happy to find a panel on the program of LGM that addressed how this community could grow. But than I felt a bit frustrated by the way people were talking about it. I think the user- and developer communities around Libre Graphics are relatively small, and all people actually ask for, is dialogue. There seems to be lots of concern about how to connect, and what tools to use for that. The discussion easily drifts into self-deprecating statements such as: "our website is not up-to-date" or "we should have a better logo" or "if only our documentation would be better". But all of this seems more about putting off or even avoiding the conversation.

AL: Yes, in a way it is. I think that 'conversations' are the best, biggest thing that F/LOSS has to offer its users, in comparison with proprietary software. But a lot of the behavioral habits we have within F/LOSS and also as people living in North America, is derived from what we see corporations doing. We accept this as our personal strategies because we do not know any alternatives. The more I say about this, the more I sound like a hippie but I think I'll have to take the risk (laughs).

If you go to the Flash website, it tells you the important things you need to know about Flash, and than you click download. Maybe there is a link to a complex survey that tries to gather data en masse of untold millions of users. I think that any randomly chosen website of a Libre Graphics project will look similar. But instead it could say when you click download or run the software ... "we're a bunch of people ... why don't you come talk to us on IRC?"

There are a lot people that are not in the conversation because nobody ever invited them. This is why I think about diversity in terms of outreach, not in terms of criticizing existing figures. If in some alternate reality we would want to build a F/LOSS community that exists out of 90% women and 10% men, I bet we could do it. You just start with finding a college student at a school that has a good Computer Science program ... she develops a program with a bunch of her friends ... she puts up flyers in other colleges ... You could do this because there are relatively so little programmers in the world busy with developing F/LOSS that you can almost handpick the diversity content of your community. Between one and a thousand ... you could do that. There are 6 million thousand people on this planet and the amount of people NOT doing F/LOSS is enormous. Don't wring your hands about "where are the women". Just ask them to join and that will be that!

Listen to F/LOSS

2010-09-16T09:38:00+02:00

At FLOSS-weekly you can find a collection of 130+ longer interviews with Free Software developers, including some involved in our favourite projects:

#11: Python (Guido van Rossum: "If you give the same task to different programmers, they'll come up with different solutions. When programmer B at some point has to maintain the code of programmer A, it is tempting to rewrite the code instead, because it would not be the same solution programmer B would have chosen")
#52: Processing (Ben Fry: "Working in code, changes the type of things I can look at")
#76: Inkscape (Jon Cruz: "Vector graphics are the shapes themselves")
#81: OpenStreetmap (Steve Coast: "Maps are never complete. They are always changing" )

GML

2010-07-23T10:41:00+02:00

Yesterday Constant met with Evan Roth to discuss gestures and standards, confessions and F/LOSS, archiving and collaboration.

More soon.

We will get to know the machine and we will understand

2009-08-26T14:37:00+02:00

Before starting a fresh new OSP-season, first a post long due:

This conversation with Juliane de Moerlooze was recorded March 2009 in the context of Female Icons, a project by De Geuzen but I think OSP-readers might like to read it as well?

“when you hear people talk about women having more sense for the global, intuitive and empathic… and men are more logic… even if it is true… it seems quite a good thing to have when you are doing math or software?"

Juliane is a Brussels based computer scientist, feminist and Linux user of the first hour. She studied math, programming and system administration and participates in the Samedies (a group of women maintaining their own server). In February 2009, she was voted president of the Brussels Linux user group.

Download interview: juliane.odt

Opening the blackbox of printing

2009-06-27T21:30:00+02:00

When we began to think about how to establish a more rich and warm collaboration with printers after the cold alerts we experienced during OSP production, Georges Charlier's appetite for research and openness to exotic solutions reappeared in Pierre's mind. And since we are preparing some new books, it was time for an update on his approach.

Georges Charlier is the passionate owner of pre-press, printing and publishing house Salto. He lives and works in Ulbeek, Limburg (B) where he restores a former brewery, and transforms it into a platform for the production and conception of extraordinary publications.

Every printed book is an original
On this mornings' motorway road to Campine, Pierre remembers for Femke his first (and only) meeting with Georges Charlier, around 10 years earlier. Thierry Van Hasselt, comics author and publisher, had spot books outputted by a fantastic printer, that built a model printshop on the border of Belgium and the Netherlands, near the Meuse, in a haunted park. This man would be able to provide extraordinary color separation and printing quality, maybe the best in the world... Thierry and me felt they needed this kind of quality in order to reproduce the subtle greasy drawings in Gloria Lopez, Thierry's book they were working on at the time. Follows a fever meeting and tour by former photographer Georges through the whole chain he has built: a repro-table with natural light and Nasa photo sensor, to avoid the brutal lighting of hi-res scanners (too high contrast); ultra high care color separation with in-house software recipes; exotic screening with an optimised solution of half 600 lpi and half stochastic rasterization and luxurious printing, combining warm grey, transparent and an opaque black 'skeleton' to match the matte quality of a litho crayon.

Far from the kind of glitter fireworks printers usually send us as new year's eve auto-promotion, this exceptional person was convinced that every book, even in large scale print run, is an original, the original. And that every stage in the process is a step to achieve the final and best result in the hands of the viewer, or user. A statement we 100% shared for the contemporary comics like Fréon was publishing. A few weeks after, Thierry literally lived there on the machine and an impressive volume was produced.

The tunnel of production
Today Georges Charlier explains how he felt frustrated by the tunnel view approach to much contemporary printing workflows. The effect of ISO-standardization might be that overall printing quality has increased, but often there is not much space for experimentation and above all specific quality. "In the United States, color specialist became known as agitators, as troublemakers. In the interest of survival, the printing business tries to streamline the process from digital file to a printed product as much as possible"

Printer without printshop
It might be the result of very practical and economical constraints, but it does not come as a surprise that Georges habitually uses the presses of his colleagues rather than his own printshop. Out of necessity, he has learned how to practice high quality printing without attaching himself to his own machine park. The experience of traveling between materials and setups has made him aware of the differences between presses of various makes. As a way to enforce a serious conversation with press manufacturers, he eventually made up his own 'acid test'. A collection of seemingly simple black and white images enables the analyses of radical shifts in quality between machines. We imagined the tense silence in the Heidelberg boardroom when he unfolded his test sheets, the complete management had gathered for the occasion. He printed the same sheet not only on the respectable German presses but also on a Roland, a Mitshibishu, a Komori and a KBA. Afterwards, in the corridor, the staff of engineers thanked him for pointing out to their bosses that even at Heidelberg there was room for improvement.

Material knowledge
On multiple levels, our conversation touches on the way material and knowledge, objects and software are intimately interwoven. It has motivated Georges to develop his own tools, and also his own paper. After an intense collaboration with the technical staff of a small paper factory in The Netherlands, he managed to develop a paper fit to his needs: a slightly ivory, matte but silky surface which supports the reproduction of a series of photographs by Bauhaus photographer Moï Ver. But the company went bankrupt, and although he still has access to the recipe, without their expertise and equipment he will not be able to produce the same quality paper ever again.

Spectral colors
"I met likeminded people like in the Netherlands, and we said to each other: let’s drop the old Lab color system, and try instead to build a new spectral system". Georges is busy developing color systems that are not limited to the traditional 3, 4, 6 or 7 values, but that are based on various separation operations that depend on what we want to store and retrieve on paper.

When the CIE Commission internationale de l'éclairage begin to build the RGB color models in the 1920's, it made sense (and fit with the mathematical computation power available at the time), to simulate the regular way our eyes simplify, with the help of three kinds of cones, infinite physical color wavelengths into three color values, as an event, before they are quantified and evaluated by our brain. These models were developped using some statistical averaging between samples of observers. And these subjective observations were than normalized to build a model that pinpoints specific and measurable wavelengths.

So the perception of these observers ended up in two overlapping simulations at work when we look at printed pictures: the one their cones have provided, and the result of the combination of three different inks chosen for their direct relation with the wavelengths that please these same cones. This synchronized simplification helped further models based on RGB (notably XYZ and Lab) and paved the way for the current ISO separation model used widely for most of the quadrichromatic printed images nowadays.

But we lost a diversity of color events in that double reduction: mostly all saturated colors in between, and colors that look the same under certain conditions but not under others (a phenomenon linked to metamerism). And if we experience everyday marvelous and rich color events in our brains, all different depending on our sex and origin, we have also progressively standardised the way we perceive printed color separation and the amount of colorised experiences we've acknowledged not to find in there.

Georges' openness to rethink the color model will not only benefit color reproduction, but also in another field of his activity, the archiving of sensible material. And it's use can even be enlarged with the archiving of information about actual pigments in the file format that stores the full spectral data of an image.

Explorations
He is finishing a special edition of images from the archives of the Scott Polar Research Institute. He puts on white gloves and shows us 5 cahiers of photographs taken by Herbert Ponting. The images document the catastrophic Terra Nova expedition undertaken by Robert Falcon Scott in 1912. Duplicates rather than reproductions, these contemporary platinotypes are meant to survive their originals (assumed life span ca. 1000 years). Their exceptionally refined quality is accentuated by the bristle character of their subject matter. Scott and their party never returned from the Terra Nova expedition. But the penetrating gaze of those adventurous men, dressed in layers of self repaired clothes, will miraculously survive after being photographed, archived, scanned, digitized, described, retouched and finally printed in three monochromes on acid free paper.

Captain Scott in his cabin

Gestes Numériques

2009-06-01T16:14:00+02:00

[](http://gallery.constantvzw.org/main.php?g2_itemId=25728)

Our colleagues from Open Source Video published a video-registration of the discussion that took place at the yearly Journées du Libre.
Enjoy Loic Vanderstichelen, Stéphane Noël, Michel Cleempoel and Marc Wathieu as they present with humour and enthusiasm why F/LOSS is relevant for art- and design education (in French).

http://osvideo.constantvzw.org/journees-du-libre-09/

Even when you are done, you are not done

2009-04-17T08:30:00+02:00

A conversation with Chris Lilley

Almost a year ago at the Libre Graphics Meeting 2008, OSP sat down with Chris Lilley on a small patch of grass in front of the Technical University in Wroclaw, Poland. Warmed up by the early May sun, we talked about the way standards are made, how 'specs' influence the work of designers, programmers and managers and how this process is opening up to voices from outside the W3C.

Chris Lilley (top row, right) on the 2008 W3C team photo.

Chris Lilley is trained as a biochemist, and specialised in the application of biological computing. He has been involved with the World Wide Web Consortium since the 1990's, headed the Scalable Vector Graphics (SVG) working group and currently looks after two W3C activity areas: graphics, including PNG, CGM, graphical quality, and fonts, including font formats, delivery, and availability of font software.

Download: chris_lilley_osp.odt

Femke Snelting (FS): I would like to ask you about the way standards are made... I think there's a relation between the way Free, Libre and Open Source Software works, and how standards work. But I am particularly interested in your announcement in your talk today that you want to make the process of defining the SVG standard a public process?

Chris Lilley (CL): Right. So, there's a famous quote that says that standards are like sausages. Your enjoyment of them is improved by not knowing how they're made ((“Laws are like sausages. It's better not to see them being made.” Otto von Bismarck, 1815 - 1898)). And to some extent, depending on the standards body and depending on what you're trying to standardize, the process can be very messy. If you were to describe W3C as a business proposition, it has got to fail. You're taking companies who all have commercial interests, who are competing and you're putting them in the same room and getting them to talk together and agree on something. Oddly, sometimes that works! You can sell them the idea that growing the market is more important and is going to get them more money.

The other way... is that you just make sure that you get the managers to sign, so that their engineers can come and discuss standards, and then you get the engineers to talk and the managers are out of the way. Engineers are much more forthcoming, because they are more interested in sharing stuff because engineers like to share what they're doing, and talk on a technical level. The worst thing is to get the managers involved, and even worse is to get lawyers involved. W3C does actually have all those three in the process. “Shall we do this work or not” is a managerial level that's handled by the W3C advisory committee, and that's where some people say “No, don't work on that area” or “We have patents” or “This is a bad idea” or whatever. But often it goes through and then the engineers basically talk about it.

Occasionally there will be patents disclosed, so the W3C also has a process for that. The first things are done are the 'charters'. The charter says what the group is going to work on a broad scope. As soon as you've got your first draft, that further defines the scope, but it also triggers what it's called an exclusion opportunity, which basically gives the companies I think ninety days to either declare that they have a specific patent and say what it's number is and say that they exclude it, or not. And if they don't, they've just given a royalty-free license to whatever is needed to implement that spec. The interesting thing is that if they give the royalty-free license they don't have to say which patents they're licensing. Other standards organizations build up a patent portfolio, and they list all these patents and they say what you have to license. W3C doesn't do that, unless they've excluded it which means you have to work around it or something like that. Based on what the spec says, all the patents that have been given, are given. The engineers don't have to care. That's the nice thing. The engineers can just work away, and unless someone waves a red flag, you just get on with it, and at the end of the day, it's a royalty-free specification.

FS: But if you look at the SVG standard, you could say that it's been quite a bumpy road ((http://ospublish.constantvzw.org/news/whos-afraid-of-adobe-not-me-says-the-mozilla-foundation)) ... What kind of work do you need to do to make a successful standard?

CL: Firstly, you need to agree on what you're building, which isn't always firm and sometimes it can change. For example, when SVG was started the idea was that it would be just static graphics. And also that it would be animated using scripts, because with dynamic HTML and whatever, this was '98, we were like: “OK, we're going to use scripting to do this.” But when we put it out for a first round of feedback, people were like “No! No, this is not good enough. We want to have something declarative. We don't want to have to write a script every time we want something to move or change color.” Some of the feedback, from Macromedia for example was like “No, we don't think it should have this facility,” but it quickly became clear why they were saying that and what technology they would rather use instead for anything that moved or did anything useful... We basically said “That's not a technical comment, that's a marketing comment, and thank you very much.”

FS: Wait a second. How do you make a clear distinction between marketing and technical comments?

CL: People can make proposals that say “We shouldn't work on this, we shouldn't work on that”, but they're evaluated at a technical level. If it's “Don't do it like that because it's going to break as follows, here I demonstrate it” then that's fine. If they're like “Don't do it because that competes with my proprietary product” then it's like “Thanks for the information, but we don't actually care.” It's not our problem to care about that. It's your problem to care about that.

Part of it is sharing with the working group and getting the group to work together, which requires constant effort, but it's no different from any sort of managerial or trust company type thing. There's this sort of encouragement in it that at the end of the day you're making the world a better place. You're building a new thing and people will use it and whatever. And that is quite motivating. You need the motivation because it takes a lot longer than you think. You build the first spec and it looks pretty good and you publish it and you smooth it out a bit, put it out for comments and you get a ton of comments back. People say “If you combine this with this with this then that's not going to work.” And you go “Is anyone really going to do that?” But you still have to say what happens. The computer still has to know what happens even if they do that.
Ninety percent of the work is after the first draft, and it's really polishing it down. In the W3C process, once you get to a certain level, you take it to what is euphemistically called the 'last call'. This is a term we got from the IETF ((The Internet Engineering Task Force, http://www.ietf.org/)). It actually means 'first call' because you never have just one. It's basically a formal round of comments. You log every single comment that's been made, you respond to them all, people can make an official objection if you haven't responded to the comment correctly etcetera. Then you publish a list of what changes you've made as a basis of that.

FS: What part of the SVG standardization process would you like to make public?

CL: The part that I just said has always been public. W3C publishes specifications on a regular basis, and these are always public and are freely available. The comments are made in public and responded to in public. What hasn't been public has been the internal discussions of the group. Sometimes it can take a long time if you've got a lot of comments to process or if there's a lot of argumentation in the group: people not agreeing on the direction to go, it can take a while. From the outside it looks like nothing is happening. Some people like to follow this at a very detailed level, and blog about it, and blablabla. Overtime, more and more working groups have become public. The SVG group just recently got re-charted and it's now a public group. All of its minutes are public. We meet for ninety minutes twice a week on a telephone call. There's an IRC log of that and the minutes are published from that, and that's all public now ((Scalable Vector Graphics (SVG) Feedback Page: http://www.w3.org/Graphics/SVG/feedback.html))

FS: Could you describe such a ninety minute meeting for us?

CL: There are two chairs. I used to be the chair for eight years or so, and then I stepped down. We've got two new chairs. One of them is Erik Dahlström from Opera, and one of them is Andrew Emmons from Bitflash. Both are SVG implementing companies. Opera on the desktop and mobile, and Bitflash is just on mobile. They will set out an agenda ahead of time and say “We will talk about the following issues.” We have an issue tracker, we have an action tracker which is also now public. They will be going through the actions of people saying “I'm done” and discussing whether they're actually done or not. Particular issues will be listed on the agenda to talk about and to have to agree on, and then if we agree on it and you have to change the spec as a result, someone will get an action to change that back to the spec. The spec is held into CVS so anyone in the working group can edit it and there is a commit log of changes. When anyone accidentally broke something or trampled onto someone else's edit, or whatever -which does happen- or if it came as the result of a public comment, then there will be a response back saying we have changed the spec in the following way... “Is this acceptable? Does this answer your comment?”

FS: How many people do take part in such a meeting?

CL: In the working group itself there are about 20 members and about 8 or so who regularly turn up, every week for years. You know, you lose some people over time. They get all enthusiastic and after 2 years, when you are not done, they go off and do something else, which is human nature. But there have been people who have been going forever. That's what you need actually in a spec, you need a lot of stamina to see it through. It is a long term process. Even when you are done, you are not done because you've got errata, you've got revisions, you've got requests for new functionalities to make it into the next version and so on.

FS: On the one hand you could say every setting of a standard is a violent process, some organisation forcing a standard upon others, but the process you describe is entirely based on consensus.

CL: There's another good quote. Tim Berners Lee was asked why W3C works by consensus, rather than by voting and he said: “W3C is a consensus-based organisation because I say so, damn it” ((“Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public).” General Policies for W3C Groups: http://www.w3.org/2005/10/Process-20051014/policies#Consensus)) That's the Inventor of the Web, you know... (laughs) If you have something in a spec because 51% of the people thought it was a good idea, you don't end up with a design, you end up with a bureaucratic type decision thing. So yes, the idea is to work by consensus. But consensus is defined as: 'no articulated dissent' so someone can say “abstain” or whatever and that's fine. But we don't really do it on a voting basis, because if you do it like that, then you get people trying to make voting blocks and convince other people to vote their way... it is much better when it is done on the basis of a technical discussion, I mean... you either convince people or you don't.

FS: If you read about why this kind of work is done... you find different arguments. From enhancing global markets to: 'in this way, we will create a better world for everyone'. In Tim Berners-Lee's statements, these two are often mixed. If you for example look at the DIN standards, they are unambiguously put into the world as to help and support business. With Web Standards and SVG, what is your position?

CL: Yes. So, basically... the story we tell depends on who we are telling it to and who is listening and why we want to convince them. Which I hope is not as duplicitous as it may sound. Basically, if you try to convince a manager that you want 20% time of an engineer for the coming two years, you are telling them things to convince them. Which is not untrue necessarily, but that is the focus they want. If you are talking to designers, you are telling them how that is going to help them when this thing becomes a spec, and the fact that they can use this on multiple platforms, and whatever.

Remember: when the web came out, to exchange any document other than plain text was extremely difficult. It meant exchanging word processor formats, and you had to know on what platform you were on and in what version. The idea that you might get interoperability, and that the Mac and the PC could exchange characters that were outside ASCII was just pie in the sky stuff. When we started, the whole interoperability and cross-platform thing was pretty novel and an untested idea essentially. Now it has become pretty much solid.

We have got a lot of focus on disabled accessibility, and also internationalization which is if you like another type of accessibility. It would be very easy for an organisation like W3C, which is essentially funded by companies joining it, and therefore they come from technological countries... it would be very easy to focus on only those countries and then produce specifications that are completely unusable in other areas of the world. Which still does sometimes happen. This is one of the useful things of the W3C. There is the internationalization review, and an accessibility review and nowadays also a mobile accessible review to make sure it does not just work on desktops.

Some organisations make standards basically so they can make money. Some of the ISO ((“International Standards for Business, Government and Society” International Organization for Standardization (ISO), http://www.iso.org)) standards, in particular the MPEG group, their business model is that you contribute an engineer for a couple of years, you make a patent portfolio and you make a killing off licensing it. That is pretty much to keep out the people who were not involved in the standards process. Now, W3C takes quite an opposite view. The Royalty free license ((“Overview and Summary of W3C Patent Policy” http://www.w3.org/2004/02/05-patentsummary.html)) for example, explicitly says: royalty free to all. Not just the companies who were involved in making it, not just companies, but anyone. Individuals. Open Source Projects. So, the funding model of the W3C is that members pay money, and that pays our salaries, basically. We have a staff of 60 odd or so, and that's where our salaries come from, which actually makes us quite different from a lot of other organisations. IETF is completely volunteer based so you don't know how long something is going to take. It might be quick, it might be 20 years, you don't know. ISO is a national body largely, but the national bodies are in practice companies who represent that nation. But in W3C, it's companies who are paying to be members. And therefore, when it started there was this idea of secrecy. Basically, giving them something for their money. That's the trick, to make them believe they are getting something for their money. A lot of the ideas for W3C came from the X Consortium ((“The purpose of the X Consortium was to foster the development, evolution, and maintenance of the X Window System, a comprehensive set of vendor-neutral, system-architecture neutral, network-transparent windowing and user interface standards.” http://www.x.org/wiki/XConsortium)) actually, it is the same people who did it originally. And there, what the meat was... was the code. They would develop the code and give it to the members of the X Consortium three months before the public got it and that was their business benefit.
So that is actually where our 'three month rule' comes from. Each working group can work for three months but then they have to go public, have to publish. 'The heartbeat rule', we call it now. If you miss several heartbeats then you're dead. But at the same time if you're making a spec and you're growing the market then there's a need for it to be implemented. There's an implementation page where you encourage people to implement, you report back on the implementations, you make a test suite, you show that every feature in the spec that there's a test for... at least two implementations pass it. You're not showing that everyone can use it at that stage. You're showing that someone can read the spec and implement it. If you've been talking to a group of people for four years, you have a shared understanding with them and it could be that the spec isn't understandable without that. The implementation phase lets you find out that people can actually implement it just by reading the spec. And often there are changes and clarifications made at that point.

Obviously one of the good ways to get something implemented is to have Open Source people do it and often they're much more motivated to do it. For them it's cool when it is new, “If you give me this new feature it's great we'll do it” rather than: “Well that doesn't quite fit into our product plans until the next quarter” and all that sort of stuff. Up until now, there hasn't really been a good way for the open source people to get involved. They can comment on specs but they're not involved in the discussions. That's something we're trying to change by opening up the groups, to make it easier for an open source group to contribute on an ongoing basis if they want to. Right from the beginning part, to the end where you're polishing the tiny details in the corner.

FS: I think the story of web fonts shows how an involvement of the Open Source people could have made a difference.

CL: When web fonts were first designed, essentially you had Adobe and Apple pushing one way, Bitstream pushing the other way, both wanting W3C to make their format the one and only official web format, which is why you ended up with a mechanism to point to fonts without saying what format was required. And than you had the Netscape 4, which pointed off to a Bitstream format, and you had IE4 which pointed off to this Embedded Open Type (EOT) format. If you were a web designer, you had to have two different tools, one of which only worked on a Mac, and one of which only worked on PC, and make two different fonts for the same thing. Basically people wouldn't bother.

As Hakon ((Håkon Wium Lie proposed Cascading Style Sheets (CSS) in 1994. http://www.w3.org/People/howcome/)) mentioned the only people who do actually use that right now really, are countries where the local language is not well provided for by the Operating Systems. Even now, things like WindowsXP and MacOSX don't fully support some of the Indian languages. But they can get it into web pages by using these embedded fonts. Actually the other case where it has been used a lot, is SVG, not so much on the desktop though it does get used there but on mobiles. On the desktop you've typically got 10 or 20 fonts and you got a reasonable coverage. On a mobile phone, depending on how high or low ended it is, you might have a single font, and no bold, and it might even be a pixel-based font. And if you want to start doing text that skews and swirls, you just can't do that with a pixel-based based font. So you need to download the font with the content, or even put the font right there in the content just so that they can see something.

FS: I don't know how to talk about this, but... envisioning a standard before having any concrete sense of how it could be used and how it could change the way people work... means you also need to imagine how a standard might change, once people start implementing it?

CL: I wouldn't say that we have no idea of how it's going to work. It's more a case that there are obvious choices you can make, and then not so obvious choices. When work is started, there's always an idea of how it would fit in with a lot of things and what it could be used for. It's more the case that you later find that there are other things that you didn't think of that you can also use it for. Usually it is defined for a particular purpose and than find that it can also do these other things.

Pierre Huyghebaert (PH): Isn't it so that sometimes, in that way, something that is completely marginal, becomes the most important?

CL: It can happen, yes.

Nicolas Malevé (NM): For me, SVG is a good example of that. As I understood it, it was planned to be a format for the web. And as I see it today, it's more used on the desktop. I see that on the Linux desktop, for theming, most internals are using SVG. We are using Inkscape for SVG to make prints. On the other hand, browsers are really behind.

CL: Browsers are getting there. Safari has got reasonably good support. Opera has got very good support. It really has increased a lot in the last couple of years. Mozilla Firefox less so. It's getting there. They've been at it for longer, but it also seems to be going slower. The browsers are getting there. The implementations which I showed a couple of days ago, those were mobile implementations. I was showing them on a PC, but they were specially built demos. Because they're mobile, it tends to move faster.

NM: But you still have this problem that Internet Explorer is a slow adopter.

CL: Yes, Internet Explorer has not adopted a lot of things. It's been very slow to do CSS. It hasn't yet done XHTML, although it has shipped with an XML parser since IE4. It hasn't done SVG. Now they've got their own thing... Silverlight. It has been very hard to get Microsoft on board and getting them doing things. Microsoft were involved in the early part of SVG but getting things into IE has always been difficult. What amazes me to some extent, is the fact that it's still used by about 60-70% of people. You look at what IE can do, and you look at what all the other browsers can do, and you wonder why. The thing is... it is still a break and some technologies don't get used because people want to make sure that everyone can see them. So they go down to the lowest common denominator. Or they double-implement. Implement something for all the other browsers, and implement something separate for IE, and than have to maintain two different things in parallel, and tracking revisions and whatever. It's a nightmare. It's a huge economic cost because one browser doesn't implement the right web stuff.

[laughing, sighing]

NM: My question would be: what could you give us as a kind of advice? How could we push this adoption where we are working? Even if it only is the people of Firefox to adopt SVG?

CL: Bear in mind that Firefox has this thing of Trunk builds and Branch builds and so on. For example when Firefox 3 came out, well the Beta is there. Suddenly there's a big jump in the SVG stuff because all the Firefox 2 was on the same branch as 1.5, and the SVG was basically frozen at that point. The development was ongoing but you only saw it when 3 came out. There were a bunch of improvements there. The main missing features are the animation and the web fonts and both of those are being worked on. It's interesting because both of those were on Acid 3. Often I see an acceleration of interest in getting something done because there's a good test.

The Acid Test ((The Acid 3 test: http://acid3.acidtests.org is comprehensive in comparison to more detailed, but fragmented SVG tests: http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview#W3C_Scalable_Vector_Graphics_.28SVG.29_Test_Suite_Overview)) is interesting because it's a single test for a huge slew of things all at once. One person can look at it, and it's either right or it's wrong, whereas the tests that W3C normally produces are very much like unit tests. You test one thing and there's like five hundred of them. And you have to go through, one after another. There's a certain type of person who can sit through five hundred test on four browsers without getting bored but most people don't. There's a need for this sort of aggregative test. The whole thing is all one. If anything is wrong, it breaks. That's what Acid is designed to do. If you get one thing wrong, everything is all over the place. Acid 3 was a submission-based process and like a competition, the SVG working group was there, and put in several proposals for what should be in Acid 3, many of which were actually adopted. So there's SVG stuff in Acid 3.

FS: So... who started the Acid Test?

CL: Todd Fahrner designed the original Acid 1 test, which was meant to exercise the tricky bits of the box-model in CSS. It ended like a sort Mondrian diagram ((“Acid Test Gallery” http://moonbase.rydia.net/mental/writings/box-acid-test/)), red squares, and blue lines and stuff. But there was a big scope for the whole thing to fall apart into a train wreck if you got anything wrong. The thing is, a lot of web documents are pretty simple. They got paragraphs, and headings and stuff. They weren't exercising very much the model. Once you got tables in there, they were doing it a little bit more. But it was really when you had stuff floated to one side, and things going around or whatever, and that had something floated as well. It was in that sort of case where it was all breaking, where people wouldn't get interoperability.

FS: It was... The Web Standards Project ((“The Web Standards Project is a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all” http://www.webstandards.org/)) who proposed this?

CL: Yes, that's right.

FS: It didn't come from a standards body.

CL: No, it didn't come from W3C. The same for Acid 2, Håkon Wium Lie was involved in that one. He didn't blow his own trumpet this morning, but he was very much involved there. Acid 3 was Ian Hickson, who put that together. It's a bit different because a lot of it is DOM scripting stuff. It does something, and then it inquires in the DOM to see if it has been done correctly, and it puts that value back as a visual representation so you can see. It's all very good because apparently it motivates the implementors to do something. It's also marketable. You can have a blog posting saying we do 80% of Acid Test. The public can understand that. The people who are interested can go “Oh, that's good”.

FS: It becomes a mark of quality.

CL: Yes, it's marketing. It's like processor speed in PCs and things. There are so much technology in computers, so than what do you market it on? Well it's got that clock speed and it's got this much memory. OK, great, cool. This one is better than that one because this one's got 4 gigs and that one's got 2 gigs. It's a lot of other things as well, but that's something that the public can in general look at and say “That one is better”.

When I mentioned the W3C process, I was talking about the engineers, managers. I didn't talk about the lawyers, but we do have a process for that as well. We have a patent advisory group conformed. If someone has made a claim, and it's disputed then we can have lawyers talking among themselves. What we really don't have in that is designers, end-users, artists. The trick is to find out how to represent them.

The CSS working group tried to do that. They brought in a number of designers, Jeff Veen ((Jeff Veen was a designer at Wired magazine, in those days. http://adaptivepath.com/aboutus/veen.php)) and these sort of people were involved early on. The trouble is that you're speaking a different language, you're not speaking their language. When you're having weekly calls... Reading a spec is not bedtime reading, and if you're arguing over the fine details of a sentence... (laughing) well, it will put you to sleep straight away. Some of the designers are like: “I don't care about this. I only want to use it. Here's what I want to be able to do. Make it that I can do that, but get back to me when it's done.”

NM: That's why the idea of the Acid Test is a nice breed between the spec and the designer. When I was seeing the test this morning, I was thinking that it could be a really interesting work to do, not to really implement it but to think about with the students. How would you conceive a visual test? I think that this could be a really nice workshop to do in a university or in a design academy...

FS: It's the kind of reverse-reverse engineering of a standard which could help you understand it on different levels. You have to imagine how wild you can go with something. I talk about standards, and read them -not before going to bed- because I think that it's interesting to see that while they're quite pragmatic in how they're put together, but they have an effect on the practice of, for example, designers. Something that I have been following with interest is the concept of separating form and content has become extremely influential in design, especially in web design. Trained as a pre-web designer, I'm sometimes a bit shocked by the ease with which this separation is made.

CL: That's interesting. Usually people say that it's hard or impossible, that you can't ever do it. The fact that you're saying that it's easy or that it comes naturally is interesting to me.

FS: It has been appropriated by designers as something they want. That's why it's interesting to look at the Web Standards Project where designers really fight for a separation of content and form. I think that this is somehow making the work of designers quite... boring. Could you talk a bit about how this is done?

CL: It's a continuum. You can't say that something is exactly form or exactly presentation because there are gradations. If you take a table, you've already decided that you want to display the material in a tabular way. If it's a real table, you should be able to transpose it. If you take the rows and columns, and the numbers in the middle then it should still work. If you've got 'sales' here and if you've got 'regions' there, then you should still be able to transpose that table. If you're just flipping it 90 degrees then you are using it as a layout grid, and not as a table. That's one obvious thing. Even then, deciding to display it as a tabular thing means that it probably came from a much bigger dataset, and you've just chosen to sum all of the sales data over one year. Another one: you have again the sales data, you could have it as pie chart, but you could also have it as a bar chart, you could have it in various other ways. You can imagine that what you would do is ship some XML that has that data, and then you would have a script or something which would turn it into an SVG pie chart. And you could have a bar chart, or you could also say show me only February. That interaction is one of the things that one can do, and arguably you're giving it a different presentational form.

It's still very much a gradation. It's how much re-styleability remains. You can't ever have complete separation. If I'm describing a company, and [1] I want to do a marketing brochure, and [2] I want to do an annual report for the shareholders, and [3] I want to do an internal document for the engineering team. I can't have the same content all over those three and just put styling on it. The type of thing I'm doing is going to vary for those audiences, as will the presentation. There's a limit. You can't say: here's the überdocument, and it can be styled to be anything. It can't be. The trick is to not mingle the style of the presentation when you don't need to. When you do need to, you're already halfway down the gradient. Keep them as far apart as you can, delay it as late as possible. At some point they have to be combined. A design will have to go into the crafting of the wording, how much wording, what voice is used, how it's going to fit with the graphics and so on. You can't just slap random things together and call it design, it looks like a train wreck. It's a case of deferment. It's not ever a case of complete separation. It's a case of deferring it and not tripping yourself up.

Just simple things like bolds and italics and whatever. Putting those in as emphasis and whatever because you might choose to have your emphasized words done differently. You might have a different font, you might have a different way of doing it, you might use letter-spacing, etc. Whereas if you tag that in as italics then you've only got italics, right? It's a simple example but at the end of the day you're going to have to decide how that is displayed. You mentioned print. In print no one sees the intermediate result. You see ink on paper. If I have some Greek in there and if I've done that by actually typing in Latin letters on the keyboard and putting a Greek font on it and out comes Greek, nobody knows. If it's a book that's being translated, there might be some problems. The more you're shipping the electronic version around, the more it actually matters that you put in the Greek letters as Greek because you will want to revise it. It matters that you have flowing text rather than text that has been hand-ragged because when you put in the revisions you're going to have to re-rag the entire thing or you can just say re-flow and fix it up later. Things like that.

PH: The idea of time, and the question of delay is interesting. Not how, but when you enter to fine-tune things manually. As a designer of books, you're always facing the question: when to edit, what, and on what level. For example, we saw this morning ((Andy Fitsimon: Publican, the new Open Source publishing tool-chain (LGM 2008)http://media.river-valley.tv/conferences/lgm2008/quicktime/0201-Andy_Fitzsimon.html)) that the idea of having multiple skins is really entering the publishing business, as an idea of creativity. But that's not the point, or not the complete point. When is it possible to enter the process? That's something that I think we have to develop, to think about.

NM: The other day there was a presentation by Michael Dominic Kostrzewa ((Michael Dominic Kostrzewa. Programmers hell: working with the UI designer (LGM 2008))) that shocked me. He is now working for Nokia, after working for Novell and he was explaining how designers and programmers were fighting each other instead of fighting the 'real villain', as he said, who were the managers. What was really interesting was how this division between content and style was also recouping a kind of political or socio-organizational divide within companies where you need to assign roles, borders, responsibilities to different people. What was really frightening from the talk was that you understood that this division was encouraging people not to try and learn from each other's practice. At some point, the designer would come to the programmer and say: “In the spec, this is supposed to be like this and I don't want to hear anything about what kind of technical problems you face.”

PH: Designers as lawyers!

NM: Yes... and the programmer would say: “OK, we respect the spec, but then we don't expect anything else from us.” This kind of behaviour in the end, blocks a lot of exchange, instead of making a more creative approach possible.

CL: I read about (and this is before skinning became more common) designers doing some multimedia things at Microsoft. You had designers and then there were coders. Each of them hated the other ones. The coders thought the designers were idiots who lived in lofts and had found objects in their ears. The designers thought that the programmers were a bunch of socially inept nerds who had no clue and never got out in sunlight and slept in their offices. And since they had that dynamic, they would never explain to each other (...)

(policeman arrives)

POLICEMAN: Do you speak English?

PH: Yes.

POLICEMAN: You must go from this place because there's a conference.

CL: Yes, we know. We are part of this conference (shows LGM badge).

POLICEMAN: We had a phone call that here's a picnic. I don't really see a picnic...

PH: We're doing an interview.

POLICEMAN: It looks like a picnic, and professors are getting nervous. You must go sit somewhere else. Sorry, it is the rules.

Have a nice day!

Transcription: Ivan + Femke

GRRRR - objectivity of the unperfect,

2009-02-24T10:35:00+01:00

During an internet wandering, and thanks to excellent K-SET website, I found the link to swiss drawing artist GRRRR website I was looking for a long time. Though I'm fan for a long time of his work, from Maika 2 (www.noraduester.net => music) record sleeve to Vitra 2006 catalogue, I hardly found traces of his activity. (GRRRR - 4 Rs - is not an easy keyword for google search! ).

Impressive urban landscapes, where structure, destruction and chaos are harmoniously gathered through organic black lines. Between meditative observation, and witnessing nervous and versatile urban activity, GRRRR works oscillate between ligne claire and expressionism, linking harmony and defaults...

Drawings also express a web cultural background infused with squats, human photocamera and alternative comics. Those images are the humble wanderer and patient retranscription of unspectacular scenes, half molded by human hands, half by traces of complexity of nature.

If drawings shows industrial objects, it is with the defaults of the human hand. If they show human construction, it is with long and patient observation and retranscription of its activity.

I was surprised to find digital version of his illustrations, where crude pixelated treatment to drawing emphases radicaly and harmoniously his drawing style. Moreover, animated movies and music videos testimonates of a serious activity, out of the boundaries of inked paper.

The GRRRR link page was also a good surprise. Among others, there are links to few open source applications we're used to play with, such as Gimp, Inkscape and so on... Curiosity convinced me to go over shyness, and contact him, though I'm not use to such intrusive behavior...

After an exchange of few emails, GRRRR kindly accepted to give a little interview.
Here it is.

= = = = = =

- May you introduce your work?

i do drawings:

i start my work with pen, paper and a nice spot for a little rest and to have a seat... then my goal is to fill the very last corner of that sheet of paper with observations my surroundings, these drawings later evolve into murals, picturebooks, animations and other media.

i started with comics which lead me into drawing on the street to have any backgrounds for the stories, this than turned into a large collection of "urban-landscape"-drawings from where i started a research in density/patterns/"bildrauschen" which will lead into...?
...and very soon after i self-published comics i began to put my work on the internet (see www.GRRRR.net), i really like the anarchistic, self-expressive and low-cost aspect of this worldwide network and update my website regularly.

- What is the background you're coming from?

i have been raised lowerclass by my single mother but in switzerland - quite a rich country, so im more like from the middleclass... and then came comics, squats, artschool, internet, extensive travelling, artmarket...

right now im high on books ;)...

How did you get into open source softwares?*

out of curiosity, because open-source belongs to everyone and the best things in life are free... :)

- Did the use of open source softwares changed the way you work?

Not directly, but its generally better to work with open structures, when i started publishing on the net i also thought about using (at that time still proprietary) flash-graphics, but vectors didn't fit my drawings, i much prefered the pixelated gifs and pngs, and the HTML-structure proofed to be much more extendable, cross-platform-friendly and able to stand the time...

i was about to learn linux but then mac went unix too and i got lazy ;)...
i work on mac os x, with programs like:
gimp
cyberduck
firefox
vlc
mpeg streamclip
scribus
neooffice
burn
pure data extended
gawker
copernikus
posterazor

- Why do you consider FLOSS softwares more appropriate to your practice than commercial ones?

1. free of charge, you pay what you want/can...
2. it is public property, i love public space in general...

- Is it a problem to use those softwares compared to print workflow or standards?

yes and no; as artist i try to do things differently, some disadvantages can turn out to be inputs for new ideas...
but till now i haven't found an opensource-program for my animation-work, so I still have to this with an old apple-software...

- Do you know other artists or designers working with FLOSS?

just a few, generally its only those creative people that come from the conceptual, the computer-programing side who are into linux and opensource... visual designers working on macs don't care, for example they're too lazy to install first x11 and then the gimp etc... though its really not that complicated: i just managed to install scribus with fink :) (though my first attempt, installing it
through macports failed...)

all you need is an internet-connection, a little time but most important: curiosity!

Data analysis as a discourse

2008-10-08T08:06:00+02:00

An interview with Michael Terry (ingimp)

At the Libre Graphics Meeting 2008 in Wroclaw, just before Michael Terry presents ingimp to an audience of curious Gimp developers and users, we meet up to talk more about 'instrumenting The Gimp' and about the way Terry thinks data analysis could be done as a form of discourse.

Michael Terry is a computer scientist working at the Human Computer Interaction Lab of the University of Waterloo, Canada and his main research focus is on improving usability in open source software. We speak about ingimp, a clone of the popular image manipulation programme Gimp, but with an important difference: ingimp allows users to record data about their usage in to a central database, and subsequently makes this data available to anyone.

(This conversation will also be included in the forthcoming Constant publication Tracks in electronic fields)

Femke Snelting [FS] Maybe we could start this conversation with a description of the ingimp project you are developing and why you chose to work on usability for Gimp?

Michael Terry [MT] So the project is ‘ingimp’, which is an instrumented version of Gimp, it collects information about how the software is used in practice. The idea is you download it, you install it, and then with the exception of an additional start up screen, you use it just like regular Gimp. So, our goal is to be as unobtrusive as possible to make it really easy to get going with it, and then to just forget about it. We want to get it into the hands of as many people as possible, so that we can understand how the software is actually used in practice. There are plenty of forums where people can express their opinions about how GIMP should be designed, or what’s wrong with it, there are plenty of bug reports that have been filed, there are plenty of usability issues that have been identified, but what we really lack is some information about how people actually apply this tool on a day to day basis. What we want to do is elevate discussion above just anecdote and gut feelings, and to say, well, there is this group of people who appear to be using it in this way, these are the characteristics of their environment, these are the sets of tools they work with, these are the types of images they work with and so on, so that we have some real data to ground discussions about how the software is actually used by people.

You asked me now why Gimp? I actually used Gimp extensively for my PhD work. I had these little cousins come down and hang out with me in my apartment after school, and I would set them up with Gimp, and quite often they would always start off with one picture, they would create a sphere, a blue sphere, and then they played with filters until they got something really different. I would turn to them looking at what they had been doing for the past twenty minutes, and would be completely amazed at the results they were getting just by fooling around with it. And so I thought, this application has lots and lots of power, I'd like to use that power to prototype new types of interface mechanisms. So I created JGimp, which is a Java based extension for the 1.0 G imp series, that I can use as a back-end for prototyping novel user interfaces. I think that it is a great application, there is a lot of power to it, and I had already an investment in its code base so it made sense to use that as a platform for testing out ideas of open instrumentation.

FS What is special about ingimp, is the fact that the data you generate is made as open part as the software you are studying itself. Could you describe how that works?

MT Every bit of data we collect, we make available: you can go to the website, you can download every log file that we have collected. The intent really is for us to build tools and infrastructure so that the community itself can sustain this analysis, can sustain this form of usability. We don’t want to create a situation where we are creating new dependencies on people, or where we are imposing new tasks on existing project members. We want to create tools that follow the same ethos as open source development, where anyone can look at the source code, where anyone can make contributions, from filing a bug to doing something as simple as writing a patch, where they don’t even have to have access to the source code repository, to make valuable contributions. So importantly, we want to have a really low barrier to participation. At the same time, we want to increase the signal-to-noise ratio. Yesterday I talked with Peter Sikking, an information architect working for Gimp, and he and I both had this experience where we work with user interfaces, and since everybody uses an interface, everybody feels they are an expert, so there can be a lot of noise. So, not only did we want to create an open environment for collecting this data, and analysing it, but we also want to increase the chance that we are making valuable contributions, and that the community itself can make valuable contributions. Like I said, there is enough opinion out there. What we really need to do is to better understand how the software is being used. So, we have made a point from the start to try to be as open as possible with everything, so that anyone can really contribute to the project.

FS ingimp has been running for a year now. What are you finding?

MT I have started analysing the data, and I think one of the things that we realised early on is that it is a very rich data set; we have lots and lots of data. So, after a year we’ve had over 800 installations, and we’ve collected about 5000 log files, representing over half a million commands, representing thousands of hours of the application being used. And one of the things you have to realise is that when you have a data set of that size, there are so many different ways to look at it that my particular perspective might not be enough. Even if you sit someone down, and you have him or her use the software for twenty minutes, and you videotape it, then you can spend hours analysing just that twenty minutes of videotape. And so, I think that one of the things we realised is that we have to open up the process so that anyone could easily participate. We have the log files available, but they really didn’t have an infrastructure for analysing them. So, we created this new piece of software called “StatsJam”, an extension to MediaWiki, which allows anyone to go to the website and embed SQL-queries against the ingimp data set and then visualise those results within the Wiki text. So, I’ll be announcing that today and demonstrating that, but I have been using that tool now for a week to complement the existing data analysis we have done.
One of the first things that we realized is that we have over 800 installations, but then you have to ask, how many of those are really serious users? A lot of people probably just were curious, they downloaded it and installed it, found that it didn’t really do much for them and so maybe they don't use it anymore. So, the first thing we had to do is figure out which data points should we really pay attention too. We decided that a person should have saved an image, and they should have used ingimp on two different occasions, preferably at least a day apart, where they’d saved an image on both of the instances. We used that as an indication of what a serious user is. So with that filter in place, then the “800 installations” drops down to about 200 people. So we had about 200 people using ingimp, and looking at the data this represents about 800 hours of use, about 4000 log files, and again still about half a million commands. So, it’s still a very significant group of people. 200 people is still a lot, and that’s a lot of data, representing about 11000 images they have been working on, there's just a lot.

From that group, what we found is that use of ingimp is really short and versatile. So, most sessions are about fifteen minutes or less, on average. There are outliers, there are some people who use it for longer periods of time, but really it boils down to them using it for about fifteen minutes, and they are applying fewer than a hundred operations when they are working on the image. I should probably be looking at my data analysis as I say this, but they are very quick, short, versatile sessions, and when they use it, they use less than 10 different tools, or they apply less than 10 different commands when they are using it.
What else did we find? We found that the two most popular monitor resolutions are 1280 by 1024 and 1024 by 768. So, those represent collectively 60% of the resolutions, and really 1280 by 1024 represents pretty much the maximum for most people, although you have some higher resolutions. so one of the things that’s always contentious about gimp, is its window management scheme and the fact that it has multiple windows, right? And some people say, well you know this works fine if you have two monitors, because you can throw out the tools on one monitor and then your images are on another monitor. Well, about 10 to 15% of ingimp users have two monitors, so that design decision is not working out for most of the people, if that is the best way to work. These are things I think that people have been aware of, it’s just now we have some actual concrete numbers where you can turn to and say, now this is how people are using it.
There is a wide range of tasks that people are performing with the tool, but they are really short, bursty tasks.

FS Every time you start up ingimp, a screen comes up asking you to describe what you are planning to do and I am interested in the kind of language users invent to describe this, even when they sometimes don’t know exactly what it is they are going to do. So inventing language for possible actions with the software, has in a way become a creative process that is now shared between interface designer, developer and user. If you look at the 'activity tags' you are collecting, do you find a new vocabulary developing?

MT I think there are 300 to 600 different activity tags that people register within that group of 'significant users'. I didn’t have time to look at all of them, but it is interesting to see how people are using that as a medium for communicating to us. Some people will say, “Just testing out, ignore this!” Or, people are trying to do things like insert html code, to do like a cross-site scripting attack, because, you have all the data on the website, so they will try to play with that. Some people are very sparse and they say 'image manipulation' or 'graphic design' or something like that, but then some people are much more verbose, and they give more of a plan, “This is what I expect to be doing”. So, I think it has been interesting to see how people have adopted that and what’s nice about it, is that it adds a really nice human element to all this empirical data.

Ivan Monroy Lopez [IM]: I wanted to ask you about the data, without getting too technical, could you explain how these data are structured, what do the log files look like?

MT So the log files are all in XML, and generally we compress them, because they can get rather large. And the reason that they are rather large is that we are very verbose in our logging. We want to be completely transparent with respect to everything, so that if you have some doubts or if you have some questions about what kind of data has been collected, you should be able to look at the log file, and figure out a lot about what that data is. That’s how we designed the xml log files, and it was really driven by privacy concerns and by the desire to be transparent and open. On the server side we take that log file and we parse it out, and then we throw it into a database, so that we can query the data set.

FS Now we are talking about privacy… I was impressed by the work you have done on this; the project is unusually clear about why certain things are logged, and other things not; mainly to prevent the possibility of 'playing back' actions so that one could identify individual users from the data set. So, while I understand there are privacy issues at stake I was wondering... what if you could look at the collected data as a kind of scripting for use? Writing a choreography that might be replayed later?

MT Yes, we have been fairly conservative with the type of information that we collect, because this really is the first instance where anyone has captured such rich data about how people are using software on a day to day basis, and then made it all that data publicly available. When a company does this, they will keep the data internally, so you don’t have this risk of someone outside figuring something out about a user that wasn’t intended to be discovered. We have to deal with that risk, because we are trying to go about this in a very open and transparent way, which means that people may be able to subject our data to analysis or data mining techniques that we haven’t thought of and extract information that we didn’t intent to be recording in our file, but which is still there. So there are fairly sophisticated techniques where you can do things like look at audio recordings of typing and the timings between keystrokes, and then work backwards with the sounds made to figure out the keys that people are likely pressing. So, just with keyboard audio and keystroke timings alone you can often give enough information to be able to reconstruct what people are actually typing. So we are always sort of weary about how much information is in there.
While it might be nice to be able to do something like record people’s actions and then share that script, I don’t think that that is really a good use of ingimp. That said, I think it is interesting to ask, could we characterize people’s use enough, so that we can start clustering groups of people together and then providing a forum for these people to meet and learn from one another? That’s something we haven’t worked out. I think we have enough work cut out for us right now just to characterize how the community is using it.

FS It was not meant as a feature request, but as a way to imagine how usability research could flip around and also become productive work.

MT Yes, totally. I think one of the things that we found when bringing people into to assess the basic usability of the ingimp software and ingimp website, is that people like looking at things like what commands other people are using, what the most frequently used commands are, and part of the reason that they like that, is because of what it teaches them about the application. So they might see a command they were unaware of. So we have toyed with the idea of then providing not only the command name, but then a link from that command name to the documentation – but I didn’t have time to implement it, but certainly there are possibilities like that, you can imagine.

FS Maybe another group can figure something out like that? That’s the beauty of opening up your software plus data set of course.
Well, just a bit more on what is logged and what not... Maybe you could explain where and why you put the limit and what kind of use you might miss out on as a result?

MT I think it is important to keep in mind that whatever instrument you use to study people, you are going to have some kind of bias, you are going to get some information at the cost of other information. So if you do a video taped observation of a user and you just set up a camera, then you are not going to find details about the monitor maybe, or maybe you are not really seeing what their hands are doing. No matter what instrument you use, you are always getting a particular slice.
I think you have to work backwards and ask what kind of things do you want to learn. And so the data that we collect right now, was really driven by what people have done in the past in the area of instrumentation, but also by us bringing people into the lab, observing them as they are using the application, and noticing particular behaviours and saying, hey, that seems to be interesting, so what kind of data could we collect to help us identify those kind of phenomena, or that kind of performance, or that kind of activity? So again, the data that we were collecting was driven by watching people, and figuring out what information will help us to identify these types of activities.
As I’ve said, this is really the first project that is doing this, and we really need to make sure we don’t poison the well. So if it happens that we collect some bit of information, that then someone can later say, “Oh my gosh, here is the person’s file system, here are the names they are using for the files” or whatever, then it’s going to make the normal user population weary of downloading this type of instrumented application. This is the thing that concerns me most about open source developers jumping into this domain, is that they might not be thinking about how you could potentially impact privacy.

IM I don’t know, I don’t want to get paranoid. But if you are doing it, then there is a possibility someone else will do it in a less considerate way.

MT I think it is only a matter of time before people start doing this, because there are a lot of grumblings about, “we should be doing instrumentation, someone just needs to sit down and do it.” Now there is an extension out for Firefox that will collect this kind of data as well, so you know…

IM Maybe users could talk with each other, and if they are aware that this type of monitoring could happen, then that would add a different social dimension…

MT It could. I think it is a matter of awareness, really, so when we bring people into the lab and have them go to the ingimp website, download and install it and use it, and go check out the stats on the website, and then we ask questions like, what kind of data are we collecting?
We have a lengthy concern agreement that details the type of information we are collecting and the ways your privacy could be impacted, but people don’t read it.

FS So concretely... what information are you recording, and what information are you not recording?

MT We record every command name that is applied to a document, to an image. Where your privacy is at risk with that, is that if you write a custom script, then that custom script’s name is going to be inserted into a log file. And so if you are working for example for Lucas or DreamWorks, or something like that, or ILM, in some Hollywood movie studio and you are using ingimp and you are writing scripts, then you could have a script like “fixing Shrek’s beard”, and then that is getting put into the log file and then people are going to know that the studio uses ingimp.
We collect command names, we collect things like what windows are on the screen, their positions, their sizes, we take hashes of layer names and file names. We take a string and then we create a hash code for it, and we also collect information about how long is this string, how many alphabetical characters, numbers, things like that, to get a sense of whether people are using the same files, the same layer names time and time again, and so on. But this is an instance where our first pass at this, actually left open the possibility of people taking those hashes and then reconstructing the original strings from that. Because we have the hash code, we have the length of the string, all you have to do is generate all possible strings of that length, take the hash codes and figure out which hashes match. And so we had to go back and create a new scheme for recording this type of information where we create a hash and we create a random number, we pair those up on the client machine but we only log the random number. So, from log to log then, we can track if people use the same image names, but we have no idea of what the original string was.
There are these little gotches (“gotchas” – that means “things to look out for”) like that, that I don’t think most people are aware of, and this is why I get really concerned about instrumentation efforts right now, because there isn’t this body of experience of what kind of data should we collect, and what shouldn’t we collect.

FS As we are talking about this, I am already more aware of what data I would allow to be collected. Do you think by opening up this data set and the transparent process of collecting and not collecting, this will help educate users about these kinds of risks?

MT It might, but honestly I think probably the thing that will educate people the most is if there was a really large privacy error and that it got a lot of news, because then people would become more aware of it because right now – and this is not to say that we want that to happen with ingimp – but when we bring people in and we ask them about privacy, “Are you concerned about privacy?”, and they say “No”, and we say “Why?” Well, they inherently trust us, but the fact is that open source also lends a certain amount of trust to it, because they expect that since it is open source, the community will in some sense police it and identify potential flaws with it.

FS Is that happening? Are you in dialogue with the Open Source community about this?

MT No, I think probably five to ten people have looked at the ingimp code – realistically speaking I don’t think a lot of people looked at it. Some of the Gimp developers took a gander at it to see how could we put this upstream, but I don’t want it upstream, because I want it to always be an opt-in, so that it can’t be turned on by mistake.

FS You mean you have to download ingimp and use it as a separate program? It functions in the same way as Gimp, but it makes the fact that it is a different tool very clear.

MT Right. You are more aware, because you are making that choice to download that, compared to the regular version. There is this awareness about that.
We have this lengthy text based consent agreement that talks about the data we collect, but less than two percent of the population reads license agreements. And, most of our users are actually non-native English speakers, so there are all these things that are working against us. So, for the past year we have really been focussing on privacy, not only in terms of how we collect the data, but how we make people aware of what the software does.
We have been developing wordless diagrams to illustrate how the software functions, so that we don’t have to worry about localisation errors as much. And so we have these illustrations that show someone downloading ingimp, starting it up, a graph appears, there is a little icon of a mouse and a keyboard on the graph, and they type and you see the keyboard bar go up, and then at the end when they close the application, you see the data being sent to a web server. And then we show snapshots of them doing different things in the software, and then show a corresponding graph change. So, we developed these by bringing in both native and non-native speakers, having them look at the diagrams and then tell us what they meant. We had to go through about fifteen people and continual redesign until most people could understand and tell us what they meant, without giving them any help or prompts. So, this is an ongoing research effort, to come up with techniques that not only work for ingimp but also for other instrumentation efforts, so that people can become more aware of the implications.

FS Can you say something about how this type of research relates to classic usability research and in particular to the usability work that is happening in Gimp?

MT Instrumentation is not new, commercial software companies and researchers have been doing instrumentation for at least ten years, probably ten to twenty years. So, the idea is not new but what is new, in terms of the research aspects of this, is how do we do this in a way where we can make all the data open? The fact that you make the data open, really impacts your decision about the type of data you collect and how you are representing it. And you need to really inform people about what the software does.
But I think your question is... how does it impact the Gimp’s usability process? Not at all, right now. But that is because we have intentionally been laying off to the side, until we got to the point where we had an infrastructure, where the entire community could really participate with the data analysis. We really want to have this to be a self-sustaining infrastructure, we don’t want to create a system where you have to rely on just one other person for this to work.

IM What approach did you take in order to make this project self-sustainable?

MT Collecting data is not hard. The challenge is to understand the data, and I don’t want to create a situation where the community is relying on only one person to do that kind of analysis, because this is dangerous for a number of reasons. First of all, you are creating a dependency on an external party, and that party might have other obligations and commitments, and might have to leave at some point. If that is the case, then you need to be able to pass the baton to someone else, even if that could take a considerate amount of time and so on.
You also don’t want to have this external dependency, because of the richness in the data, you really need to have multiple people looking at it, and trying to understand and analyse it. So how are we addressing this? It is through this Stats Jam extension to the MediaWiki that I will introduce today. Our hope is that this type of tool will lower the barrier for the entire community to participate in the data analysis process, whether they are simply commenting on the analysis we made or taking the existing analysis, tweaking it to their own needs, or doing something brand new.

In talking with members of the Gimp project here at the Libre Graphics Meeting, they started asking questions like, “So how many people are doing this, how many people are doing this and how many this?” They’ll ask me while we are sitting in a café, and I will be able to pop the database open and say, “A certain number of people have done this, or, “no one has actually used this tool at all.”
The danger is that this data is very rich and nuanced, and you can’t really reduce these kind of questions to an answer of “N people do this”, you have to understand the larger context. You have to understand why they are doing it, why they are not doing it. So, the data helps to answer some questions, but it generates new questions. They give you some understanding of how the people are using it, but then it generates new questions of, Why is this the case? Is this because these are just the people using ingimp, or is this some more widespread phenomenon?
They asked me yesterday how many people are using this colour picker tool – I can’t remember the exact name – so I looked and there was no record of it being used at all in my data set. So I asked them when did this come out, and they said, “Well it has been there at least since 2.4.” And then you look at my data set, and you notice that most of my users are in the 2.2 series, so that could be part of the reasons. Another reason could be, that they just don’t know that it is there, they don’t know how to use it and so on. So, I can answer the question, but then you have to sort of dig a bit deeper.

FS You mean you can’t say that because it is not used, it doesn’t deserve any attention?

MT Yes, you just can’t jump to conclusions like that, which is again why we want to have this community website, which shows the reasoning behind the analysis. Here are the steps we had to go through to get this result, so you can understand what that means, what the context means, because if you don’t have that context, then it’s sort of meaningless. It’s like asking, what are the most frequently used commands? This is something that people like to ask about. Well really, how do you interpret that? Is it the numbers of times it has been used across all log files? Is it the number of people that have used it? Is it the number of log files where it has been used at least once? There are lots and lots of ways in which you can interpret this question. So, you really need to approach this data analysis as a discourse, where you are saying, here are my assumptions, here is how I am getting to this conclusion, and this is what it means for this particular group of people. So again, I think it is dangerous if one person does that and you become to rely on that one person. We really want to have lots of people looking at it, and considering it, and thinking about the implications.

FS Do you expect that this will impact the kind of interfaces that can be done for Gimp?

MT I don’t necessarily think it is going to impact interface design, I see it really as a sort of reality check: this is how communities are using the software and now you can take that information and ask, do we want to better support these people or do we…For example on my data set, most people are working on relatively small images for short periods of time, the images typically have one or two layers, so they are not really complex images. So regarding your question, one of the things you can ask is, should we be creating a simple tool to meet these people’s needs? All the people are is just doing cropping and resizing, fairly common operations, so should we create a tool that strips away the rest of the stuff? Or, should we figure out why people are not using any other functionality, and then try to improve the usability of that?
There are so many ways to use data I don’t really know how it is going to be used, but I know it doesn’t drive design. Design happens from a really good understanding of the users, the types of tasks they perform, the range of possible interface designs that are out there, lots of prototyping, evaluating those prototypes and so on. Our data set really is a small potential part of that process. You can say, well according to this data set, it doesn’t look like many people are using this feature, let’s not much focus too on that, let’s focus on these other features or conversely, let’s figure out why they are not using them…Or you might even look at things like how big their monitor resolutions are, and say well, given the size of the monitor resolution, maybe this particular design idea is not feasible. But I think it is going to complement the existing practices, in the best case.

FS And do you see a difference in how interface design is done in free software projects, and in proprietary software?

MT Well, I have been mostly involved in the research community, so I don’t have a lot of exposure to design projects. I mean, in my community we are always trying to look at generating new knowledge, and not necessarily at how to get a product out the door. So, the goals or objectives are certainly different.
I think one of the dangers in your question is that you sort of lump a lot of different projects and project styles into one category of “Open Source”. “Open source” ranges from volunteer driven projects to corporate projects, where they are actually trying to make money out of it. There is a huge diversity of projects that are out there; there is a wide diversity of styles, there is as much diversity in the Open Source world as there is in the proprietary world.
One thing you can probably say, is that for some projects that are completely volunteer driven like Gimp, they are resource strapped. There is more work than they can possibly tackle with the number of resources they have. That makes it very challenging to do interface design, I mean, when you look at interface code, it costs you 50 or 75 percent of a code base. That is not insignificant, it is very difficult to hack and you need to have lots of time and manpower to be able to do significant things. And that’s probably one of the biggest differences you see for the volunteer driven projects, it is really a labour of love for these people and so very often the new things interest them, whereas with a commercial software company developers are going to have to do things sometimes they don’t like, because that is what is going to sell the product.

Interview avec Denis

2008-09-18T19:00:00+02:00

L'ATypI 08 est en route à St Petersburg. Denis Moyogo Jacquerye, co-leader du projet DejaVu y a présenté ce matin le projet sur lequel il travaille actuellement.

C'est l'occasion pour nous de publier une interview OSP de Denis, rencontré en mai dernier aux Libre Graphics Meeting 2008 de Wrocław.

[caption id="attachment_916" align="alignnone" width="300" caption="OSP avec Denis et Dave Crossland à FOSDEM 2008, Bruxelles"][/caption]

Ludi : Hello Denis. Peux-tu nous raconter comment tu es entré dans le projet DejaVu?

Denis : [...manquant...] une des langues du Congo, et j'ai commencé à m'intéresser à savoir comment est-ce qu'on l'écrivait. Je me suis rendu compte qu'il y avait un orthographe avec des caractères spéciaux et des accents, qui sont plus ou moins les mêmes que ceux utilisés pour l'alphabet phonétique. Donc un jour j'ai décidé de me mettre au travail. J'ai regardé les polices qu'il était possible d'améliorer. Pour DejaVu il y avait déjà un certain nombre de gens qui avait l'air assez actifs, donc j'ai téléchargé les sources, j'ai ouvert FontForge et j'ai commencé à chipoter toute une après-midi et puis le lendemain j'ai envoyé un patch. On m'a dit « Oui c'est bien, mais il faudra aussi dessiner la version bold, l'italic et le bold italic » (rires) Donc, comme c'était les vacances, j'ai passé toute la semaine à faire ça. J'ai envoyé le patch et puis c'est entré dans les sources, les gens ont pu l'avoir un mois après, dans la distribution. Puis j'ai commencé à ajouter des choses nécessaires pour d'autres langues. J'ai commencé à corriger un peu ce que j'avais fait. De fil en aiguille, je suis plus ou moins resté très actif dans le projet. Et un jour, le leader principal du projet a annoncé qu'il ne pouvait plus s'en occuper à plein temps...

Pierre : Du projet DejaVu?

Denis : Oui. Il a demandé si les gens étaient prêts à reprendre sa place. Personne n'a vraiment répondu. Donc une semaine après il a dit « Bon eh bien, les trois personnes les plus actives sont nommées d'office. Et c'était Ben Laenen et moi et une troisième personne pour maintenir la liste de courriels.

Pierre : Et le projet DejaVu, son histoire avant toi?

Denis : Le projet DejaVu, à la base c'est lorsque Bitstream a vendu Vera au projet Gnome. Ils ont fait une licence libre.

Pierre : Est ce qu'ils en ont tiré du cash?

Denis : Oui. Donc plusieurs personnes, un peu chacune de leur côté ont commencé à compléter cette police de caractère, en rajoutant les deux trois caractères qui manquaient pour leur langue. Il y avait plus ou moins une quinzaine de versions différentes. Štěpán Roh a mis tout ça ensemble et a créé le projet DejaVu. C'est comme ça que c'est devenu le plus gros projet de police dérivée de Bitstream.

Pierre : Vous avez encore des contacts avec Bitstream?

Denis : Non. On a pas de contacts directs. Il y a plus ou moins un an, des gens de la fondation Gnome avaient pris contact avec eux pour essayer de voir si Bitstream serait intéressé de rajouter d'autres caractères et donc de continuer à améliorer les polices mais pour l'instant...
Ils seraient prêts à le faire s'il y avait différents payements.

Ludi : À chaque fois, il y a eu des ajouts de glyphes. Mais le dessin de base, reste inchangé par rapport à la Vera ou il a été modifié?

Denis : Oui. Le dessin de base est inchangé. Les seules choses qui ont peut être changé c'est quelques bugs, un ou deux glyphes qui n'étaient pas bons, enfin pas exactement ce que les gens s'attendaient à avoir dans leur langue. On a aussi modifié deux trois choses dans l'espacement de certains caractères. En dehors de ça c'est exactement la même chose. Pour tous les caractères qu'on a créé ou rajouté par nous-même, soit on est parti des caractères de Vera ― par exemple pour certaines langues africaines, il y a beaucoup de caractères avec des crochets en plus, un b avec un crochet au dessus ou un d avec un crochet ― donc là c'est assez simple, il suffit de prendre le b et de lui ajouter un crochet.
Aussi, la police Bitstream Vera a été optimisée pour la lecture à l'écran. Donc chaque caractère a un petit programme, un petit logiciel, le hinting qui permet de rentrer le caractère dans les pixels selon la taille, donc ça aussi on est en train de l'ajouter pour les caractères qu'on a fait.

Pierre : Tu as fait une après-midi sur le regular mais lequel? La version sans empattements, la version serif?

Denis : Sans serif.

Pierre : Et donc on t'a demandé la version bold, italic et bold italic, on te les a demandé aussi pour la serif et la mono?

Denis : Non. Ça c'est moi par après. Parce qu'en fait je comptais faire toutes les versions, c'est juste que j'ai commencé par la sans serif.

Ludi : Actuellement ce sont des TrueType, des OpenType?

Denis ; On génère des fichiers .ttf mais avec des tables OpenType. On a des ligatures, on a les positionnements de caractères et d'accents.

Pierre : Vous vous conformé le plus possible à l'Unicode? Ou entièrement?

Denis : On suit le standard Unicode donc on évite de mettre des caractères dans des glyphes non spécifiés. On en a quelques-uns mais c'est juste parce qu'on sait qu'ils vont bientôt être implémentés dans Unicode.

Pierre : Oui, peut-être. On peut poser la question dans l'autre sens : Est-ce qu'Unicode vous suffit?

Denis : Oui, il y a des gens qui ont proposé d'ajouter des caractères qui n'étaient pas encore dans Unicode et qui ne sont pas encore planifiés. Par exemple les caractères médiévaux pour lesquels il y a un standard parallèle à Unicode qui a des caractères en plus et donc ça c'est dans le PUA (Private Usage Agreement).

Pierre : Mais qui peuvent être élus potentiellement pour être ensuite intégrés à Unicode?

Denis : Oui.

Ludi : Comment ça se passe? Vous avez beaucoup de participants? Il y a beaucoup de demandes?

Denis : On a plus ou moins 5 personnes qui sont très actives. Et puis 5 autres qui aident de temps en temps.

Ludi : Peut-être que ça va augmenter après ces rencontres. [NDLR : à Wroklaw]

Denis : Oui, j'espère aussi.

Pierre : Tu avais un intérêt dans la typographie au départ en tant que développeur et linguiste?

Denis : Moi, au départ l'intérêt est juste venu par le besoin. J'avais besoin d'une police de caractères. Donc j'ai commencé à regarder comment la faire et je me suis rendu compte que c'était assez compliqué et assez intéressant aussi.

Ludi : Pour quelle langue tu en avais besoin?

Denis : Le lingala et aussi la phonétique.

Pierre : Phonétique, ça existait déjà, non?

Denis : Oui mais c'est juste parce que en fait... à la base quand je lisait les pages web, ça utilisait la police de caractère par défaut, donc Bitstream et les caractères phonétiques étaient substitués d'une autre police de caractères. C'était pas uniforme. Pour moi c'est juste plus simple si tout est dans une seule police de caractères, avec le même style. C'est juste plus agréable à lire.

Ludi : Et maintenant, est-ce qu'en dehors du projet DejaVu, tu t'es mis à dessiner d'autres fontes?

Denis : Oui. J'avais aussi commencé à ajouter des caractères au projet Free Fonts. J'ai ajouté pas mal de caractères à Nimbus. Mais là depuis un an, on a commencé à planifier un projet, avec le CRDI (Centre de Recherches et de Développement International). C'est l'aide au développement canadienne. Ils veulent financer des projets de localisation de logiciels informatiques en langues africaines. Et donc, une partie du projet, c'est de produire plus de polices de caractères qui supportent les langues africaines. Là, je vais partir de plusieurs polices de caractères et ajouter les caractères africains.

Pierre : Peut-être pour être plus précis : DejaVu a un axe très clair en terme typographique, de rester sur les 3 polices de base de Vera?

Denis : Oui.

Pierre : Donc l'extension se fait dans le sens de l'ajout de glyphes des tables Unicode mais pas dans le sens de rajouts typographiques.

Denis : Non. On a les 3 familles : sans, serif et sans mono. Si quelqu'un veut rajouter un caractère dans une police, il peut juste le faire dans Sans par exemple, mais s'il le fait pour DejaVu Sans il doit aussi le faire pour Sans Bold, Sans Italic et Sans Bold Italic. C'est le minimum demandé. Le problème est que certains systèmes d'écriture n'ont pas la notion d'italique. L'écriture arabe par exemple a juste le regular et le gras. Aussi, certaines écritures qui n'ont pas ces notions de sans et de serif. Mais ils ont peut être un style plus traditionnel et un style plus coupé.

Pierre : Oui. Quels sont les rapports avec le modèle typographique occidental dominant et les modèles d'écritures dont certains doivent... Moi je connais assez mal, même quasi rien des scripts africains, je vois un petit peu l'ancien éthiopien, des choses qui... strictement rien à voir.

Ludi : Par rapport aux participants, est ce qu'il y a quelqu'un qui contrôle ce qui est fait, qui valide?

Denis : Il y a des gens qui ont déjà accès aux sources, pour les autres c'est assez simple, il suffit de soumettre les modifications à la liste public, et donc généralement on jette un œil dessus, on voit si c'est correct ou pas, on donne un commentaire ou on dit directement que c'est bon et on l'inclut. Une fois que la personne a fait ça quatre ou cinq fois sans trop de problèmes, on lui donne accès directement aux sources.

Nicolas : Donc oui il y a un petit temps de test.

Denis : Oui parce que généralement, enfin moi par exemple, chaque fois que j'envoyais un patch au début il y avait toujours des erreurs...

Pierre : Vous donnez aussi une espèce de mini formation? Par mail ou...?

Denis : Oui, par mail. Les gens posent des questions soit par mail ou bien sur IRC.

Ludi : C'est des gens qui viennent d'où par exemple?

Denis : D'un peu partout : États-Unis, Europe, Russie.

Harrisson : Est ce qu'il y a des chinois?

Denis : Dans le projet, non. On a un français qui a des origines du Laos. C'est lui qui a ajouté le laotien dans la DejaVu Sans.

Harrisson : Y a-t-il des glyphes chinois dans DejaVu?

Denis : Non. En fait on a très peur du chinois parce que c'est quand même beaucoup de caractères.

OSP : (rires)

Yi : Faut pas avoir peur.

Denis : Mais on a déjà eu pas mal de gens qui demandaient pour qu'on puisse avoir les caractères chinois. Moi personnellement je serais prêt à le faire mais il me faudrait le temps et les connaissances surtout. Dans notre équipe actuellement il n'y a personne avec les connaissances nécessaires pour pouvoir dessiner les caractères.

Nicolas : La question qui se pose pour moi quand je vois l'étendu de ces fontes c'est : quel sens ça a de garder une sorte d'identité de la fonte sur tous ces langages? Comment est-ce qu'on peut dire que ça reste une Courier, je sais pas, une Vera Sans... en arabe et en chinois aussi? Est-ce-qu'il y a des guidelines, quelque chose qui permet de...

Denis : Ce qu'on essaye de faire, si par exemple on écrit un texte bilingue, c'est que ça s'affiche correctement et qu'il n'y ait pas de différences de contraste dans le gris des textes.

Pierre : Oui, par comparaison, par juxtaposition.

Denis : Mais parfois on se rend compte que c'est quasiment impossible. Par exemple il y a des systèmes d'écriture qui peuvent avoir des lignes assez courtes et il y en a qui ont vraiment besoin d'espace, qui ont certains caractères qui montent très haut ou descendent très bas ou qui ont plusieurs diacritiques au dessus. C'est assez complexe parce qu'en plus Bitstream Vera à la base est faite pour être lue à petites tailles et donc par économies ils sauvent beaucoup d'espace entre les lignes. En arabe on a du raccourcir les caractères en bas. C'est un problème qu'on aimerait résoudre parce que c'est assez important pour la lecture.

Ludi : C'est pas possible d'encoder à l'intérieur d'une même fonte, des hauteurs différentes?

Denis : Si c'est possible. OpenType définit une table base qui permet de définir ça, même par langues. Par exemple le latin en français avec une certaine hauteur de ligne et le latin en vietnamien avec une hauteur de ligne différente.

Pierre : Mais la difficulté c'est quand tu mélanges les deux. Tu dois quand même trouver une certaine harmonie. Par exemple j'ai un petit peu composé de l'arabe et c'est chaque fois «wao!»... Ça ne marche pas quoi.

Denis : Personnellement si c'était à refaire je crois que je me limiterais simplement au latin au cyrillique et au grec, et peut-être les autres systèmes d'écriture qui sont compatible.

Pierre : Oui, un critère stylistique.

Denis : Parce que ce sont des systèmes qui supportent vraiment tout Unicode. Pour beaucoup de systèmes d'écriture c'est vraiment difficile de trouver le juste milieu.

Pierre : Donc il y a quand même beaucoup de critères typographiques. Est-ce que sur la liste s'il y a un caractère en éthiopien qui apparaît, est-ce qu'il y a des discussions sur des critères typographiques, genre «Non là vraiment le contraste est trop faible, ici l'empattement est décalé»?

Denis : Non, malheureusement. On en parle beaucoup sur IRC mais il n'y pas d'archives là dessus. Parce que des fois on est assez méchants. (rires OSP) On est là «Mais c'est quoi ce truc? Ah mais c'est moi qui l'ai fait? Non.» Mais c'est vrai que parfois, quand je regarde certains caractères, je vois que certaines courbes ne sont pas belles, que le contraste est faux à certains endroits. Il faudrait qu'on passe plus de temps aussi pour l'espacement.

Pierre : Oui c'est le parent pauvre. C'est le plus laborieux.

Denis : Oui, parce qu'au début on se dit qu'il faut juste dessiner les caractères puis après on commence à se documenter un peu et on se rend compte du travail que c'est.

Pierre: 50% du travail, non?

Denis : Ce qui est intéressant aussi ce sont les technologies avancées avec OpenType.
À partir d'un moment on peut avoir un caractère différent selon le contexte, selon la langue.
Depuis que nous sommes devenu une police par défaut sur différentes distributions Linux, on peut commencer à pousser un peu la technologie parce que il y a beaucoup de choses qui ne sont pas supportées, parce qu'il n'y a pas de polices de caractères qui le font en fait. Là, comme nous on peut dire, voilà, nous on a une police qui intègre ces spécificités et ça serait bien si l'utilisateur pouvait y avoir accès. Ce qu'on a commence à faire c'était le positionnement et la substitution de caractères pour le latin, le cyrillique et le grec, donc ça c'était partiellement supporté avec Pango par exemple. Et donc depuis qu'on s'y est intéressé ça a un peu fait bouger les choses. Il y aussi la substitution selon la langue. Là on a mis un peu la pression pour que ça soit implémenté. Maintenant on va commencer à se mettre au système où on peut avoir différentes hauteur de ligne selon le système d'écriture ou la langue. Aussi, avec les noms de polices de caractères. Parce que dans les vieux systèmes informatiques il y avait juste une police de caractères avec 4 styles : normal, gras, italique et gras italique, ensuite OpenType est arrivé et a ajouté tout un système pour avoir une dizaine de gras différents et différentes chasses. On a ajouté ça et ça a créé pas mal de bugs dans pas mal d'applications. Par exemple OpenOffice substituait le condensé au lieu de prendre le regular et donc il y des gens qui se plaignaient chez nous. On leur disait «C'est pas notre faute, nous on suit les spécifications Opentype».

Pierre : Vous produisez aussi des largeurs, des chasses différentes?

Denis : Oui ça c'est parce que quelqu'un a proposé l'idée et donc on a fait un petit hack rapide ou c'est automatiquement généré à partir d'une version régulière. Une réduction de 90% ça passe encore bien à l'œil. Personnellement, je préférerais si c'était fait manuellement à partir des dessins originaux mais...

Harrisson : Oui, le condensé est particulièrement difficile.

Pierre : il y a aussi des systèmes semi-automatiques qui condensent en gardant le contraste, en ne faisant pas un stretch.

Denis : Oui, FontForge a une fonction pour faire ça. Parfois ça marche très bien et parfois ça passe pas. À un moment je me suis amusé à faire DejaVu Sans extra light et c'était assez intéressant comme expérience. Enfin c'est pas super beau mais c'est utilisable.

Harrisson : Est-ce qu'il y a des serif, sans serif dans des systèmes comme l'arabe? Des systèmes ou justement c'est un peu plus difficile pour nous de voir s'il y a des spécificités du genre.

Denis : Dans ces cas là, on s'inspire de ce qui existe déjà, comme par exemple le Tahoma. On a essayé de suivre le même style. Pour le sans serif on a pas encore commencé. Je sais que pour le projet de localisation à Farsi ils ont fait une police de caractères basée sur Bitstream Vera en arabe et ils l'ont fait pour le serif et le sans serif. On est en contact avec une des personnes qui a travaillé là-dessus. On aimerait aussi pouvoir l'avoir en serif .

Harrisson : Tu es aussi impliqué avec le projet Nimbus?

Denis : Non pas directement.

Harrisson : Parce qu'on a travaillé sur une police Nimbus, sur la mono. Et c'est pas très clair au niveau des licences, au niveau du dessin. Ça ressemble très fort à d'autres. On aurait voulu savoir si tu avais quelques infos à ce sujet?

Denis : Les polices Nimbus, si je me souviens bien, elle sont sous licence GPL. Elles ont été données ou achetées pour Ghostscript. Nimbus Serif et Nimbus Mono sont en GPL. Parce que justement le projet Free Fonts les a utilisé comme base.

Pierre : À propos de cette base, vous connaissez le nom de la personne qui a dessiné le Vera chez Bitstream? C'est crédité?

Denis : Oui c'est crédité oui. J'ai un nom en tête mais je suis pas sûr alors... Je devrais le savoir effectivement.

Pierre : Non, non, mais je pose la question parce qu'elle est quand même assez spécifique. Je veux dire que c'est quand même la typo la plus anonyme.

Denis : Mais le dessin est aussi assez proche de Frutiger.

Pierre : Et tu as mentionné ton autre activité dans l'association panafricaine? Ça consiste en quoi? C'est relié?

Denis : Je vais plus ou moins refaire le même travail pour les langues africaines. Dans les deux mois qui viennent, je vais prendre les polices Liberation et je vais ajouter ce qu'il faut pour les gras des langues africaines, les langues officielles.

Pierre : Et ça c'est du boulot qui est financé par l'extérieur?

Denis : Oui là c'est le projet avec le CRDI.

Pierre : Est-ce que tu as des contacts avec des utilisateurs, proches ou lointains du travail que vous faites? Est ce que par exemple vous le voyez dans le domaine académique être utilisé, mais aussi chez un coiffeur quelque part au Congo ou...

Denis : Le problème c'est justement qu'en Afrique, il y a des standard qui ont été publiés par les académiciens ou parfois par le gouvernement, mais il y très peu de gens qui les utilisent en fait. C'est à dire que les standards ne sont pas bien diffusés, publiés. Par exemple, dans le cas du Zaïre, dans les années 70, ils ont travaillé sur un standard pour uniformiser l'orthographe dans toutes les langues officielles du Congo.

Pierre : Parce qu'il y avait quand même l'idée politique de zaïrisation.

Denis : Depuis, seuls les universitaires l'utilisent. Les gens utilisent encore l'alphabet qu'ils ont appris à l'école primaire. Certains manuels scolaires sont publiés avec l'orthographe standard mais ça n'est pas utilisé largement. Dans les autres pays africains ça dépend aussi. Souvent il y a différents orthographes possibles dans la même langue. Malheureusement il n'y a pas assez de culture littéraire où il y aurait un gros corpus écrit dans un même orthographe.

Nicolas : Une autre question. On s'intéresse aussi beaucoup par ailleurs aux questions de cartographie et justement par rapport aux polices de caractères, quand on voit le projet OpenStreetMap ou des projets similaires, on a déjà eu pas mal de discussions sur quelles types de polices, qu'est ce que serait une police pour ce genre d'activités et Femke me disait qu'elle t'as vu éditer OpenStreetMap, donc on s'est dit qu'on pouvait te poser la question si tu avais des idées ou si dans le type de recherches que tu as fais, il y aurait des polices intéressantes à apporter dans ce genre de projet et aussi à partir du moment où on a des cartes qui commencent à devenir multilingues, qu'est-ce que ça veut dire au niveau de la gestion?
Parce qu'il y a une idée très occidentale de la carte et je vois très bien comment nous par défaut on place les caractères à partir du moment où on les lit autrement, etc. Je pense que ça pose des questions. Pas juste «est-ce que la fonte est disponible?» mais aussi quel est son lien avec une sorte de lecture de l'image, de lecture de direction, de l'espace.

Denis : Oui, je suis aussi actif sur le projet OpenStreetMap. Pour les polices de caractères, avant ils utilisaient Arial. Quelques personnes se sont plaintes et maintenant ils utilisent DejaVu. Ce n'est pas moi ni Ben qui avons poussé pour ça, mais c'était assez marrants parce qu'on se disait «Ah ça serait cool si ils utilisaient DejVu» et le lendemain ils utilisaient Deja Vu. «Ah, cool !». Personnellement je ne sais pas si DejaVu est la meilleure police pour les cartes en fait parce que c'est plus une police pour l'écran en petite taille. Comme les cartes sont générées à l'avance, je pense qu'il mieux de prendre des caractères moins larges parce que ça prend beaucoup de place. Je pense que pour la lecture, elle se fait bien avec un police plus fine (condensée).

Pierre : Oui, il y a différentes discussions à ce sujet. Entre le rapport de réduire le corps et espacer plus les caractères pour arriver en fait à la même longueur qu'une version condensée qui est plus grande mais qui est pas forcément plus lisible. Il y des écoles qui s'opposent sur la question. Mais je ne suis pas sûr que DejaVu soit une si mauvaise candidate.

Denis : C'est vrai que d'un point de vue international, multilingue c'est quand même assez important d'avoir un style en commun. Pour l'instant dans OpenStreetMap, il y a deux engins qui génèrent les cartes, il y a Mapnic et Osmarender, les deux utilisent DejaVu mais Mapnic ne fait pas de substitution. Pour tout ce qui est écrit en chinois, coréen, japonais et autre langues asiatiques, il n'a pas de caractères, il place juste des carrés. Tandis qu'Osmarender substitue avec des polices qui ont ces caractères là.

Pierre : Par contre ce que tu disais au sujet du foisonnement vertical (différentes hauteurs de glyphes selon les langues), ça oui c'est important que ça soit limité. C'est difficile de placer des objets texte qui ont des proportions...

Denis : Oui sans pour autant cacher la carte. Moi ce que je trouve intéressant c'est le problème, justement avec la Belgique, surtout Bruxelles, étant bilingue. Bon déjà il y a des noms kilométriques comme Molenbeek Saint Jean et donc en plus si on les met dans les deux langues et si en plus la police de caractère est grasse et/ou large. (Rires) Oui, il faudrait plus de souplesse dans leurs engins de rendu pour qu'ils puissent sélectionner différentes polices de caractères selon la longueur du texte.

Pierre : En cartographie manuelle il y a cette espèce de paradigme de couper le nom en morceaux, des systèmes pour éviter les obstacles mais c'est très compliqué à programmer en automatique.

Yi : Sur logiciels libres, il y a les fontes Open Source mais aussi les fontes comme Arial ou Times qui cohabitent. Comment ça se passe?

Denis : Arial, Times et Courier font partie des des core fonts? C'est Microsoft qui avait décidé de rendre disponible un paquet de polices de caractères comme ça elles pouvaient être utilisées sur les pages web.

Pierre : Quelle est la licence exacte? J'ai jamais regardé.

Denis : Non c'est une licence classique, tu peux juste utiliser la police de caractère, tu peux pas la modifier, la redistribuer. Le problème c'est que c'est limité à une version fixe, c'est figé dans le temps.

Pierre : Il n'y a pas de contradiction formelle à l'utiliser sauf que si on l'intègre dans un logiciel qui a un autre type de licence et où ça va rentrer en conflit.

Denis : Le problème aussi c'est qu'il n'y a pas moyen de rentrer en contact, de communiquer avec les personnes qui l'ont conçu. Parce que si c'était possible, moi à la limite ça me dérange pas d'avoir une licence fermée mais si on pouvait communiquer pour que la prochaine version soit bien faite.

Pierre : Mais il y a un autre problème avec l'Arial c'est qu'elle est moche. C'est un rip-off mal fait.

Harrisson : En parlant de dérivés, est ce qu'il y a des dérivés de la DejaVu? Des personnes qui se la sont approprié et que en ont fait d'autres?

Denis : De DejaVu même non. Mais il y a des gens qui ont pris Bitstream et qui ont plus ou moins le même niveau que DejaVu. Il y Arev. Lui a rajouté un certain nombre de caractères pour les mathématiques. Donc, à un moment on s'en est rendu compte et on en a repris quelques uns. Et quelques personnes qui ont travaillé pour faire une serif mono.

Harrisson : Nous, lors d'un workshop, on avait montré les possibilités de faire des changements à l'intérieur d'une fonte. On avait juste changé le a par exemple. On a fait un autre a sur la DejaVu Serif. Mais je sais pas si vous avez des feedback sur ce genre de jeux.

Denis : Non, pas de DejaVu. Mais Bitstream Vera il y en a beaucoup. Enfin moins qu'avant puisqu'on les a reprise ensemble mais dérivées de Deja Vu même, non. Généralement si les gens veulent faire des modifications ils nous les envoie directement. Il y a un grec qui a refait le grec pour DejaVu. Il nous avait envoyé un pdf avec ce qu'il avait fait. Ça avait relancé un peu la discussion sur notre travail à nous et on a commencé à refaire des modifications.

Harrisson : Mais vous avez toujours un dessin par glyphe? Vous n'avez pas plusieurs...

Denis : Si on a quelques variantes, par besoin linguistiques. Pour le a on peut choisir le a scolaire et le a typographique. Il y aussi le g à double contre-poinçon et le ŋ. Le n avec un crochet utilisé dans les pays nordiques, en sami puis dans quelques langue africaines mais le problème c'est que la forme majuscule est différente. Pour le sami c'est un N majuscule normal avec le crochet tandis qu'en Afrique c'est souvent un n minuscule agrandi avec le crochet. Et certains ont le crochet sous la ligne de base, d'autre au dessus. On a trois variantes.

Pierre : Qui existent dans Unicode? Déjà référencés comme des choses séparées?

Denis : Non, pour Unicode c'est un seul caractère. Donc on a un caractère et 3 glyphes pour ce même caractère, qui sont référencés selon la langue, selon l'interface aussi si elle le permet.

Yi : J'ai encore une question. Par exemple si on ouvre une page internet en chinois, parfois il y a des problèmes d'affichage. Les caractères manquant ne sont pas substitué par des carrés mais il manque carrément des caractères et même en changeant le codage, rien ne change. Et d'autre fois il n'y a pas de problèmes d'affichages. Je veux dire sur un même site, le même jour.

Denis : C'est bizarre. Là le problème peut venir du navigateur utilisé, la librairie qui gère Unicode ou les polices de caractères. Ce qu'il faut savoir avec le codage c'est qu'une page html peut être définit par un codage, mais ce que le navigateur va d'abord lire c'est ce que le serveur lit. Dons si le serveur dit que j'utilise le codage x et que la page html dit codage y, c'est le codage x qui est pris en compte.

Pierre : Ce qui n'est pas toujours idéal.

Nicolas : Ça veut dire que si tu veux une page en chinois sur un serveur américain, il faut que le serveur ai détecté à l'origine que ta page est en chinois.

Denis : Je sais pas si tous les navigateurs suivent ça à la ligne.

Nicolas : Mais le problème que tu décris est plus étrange, parce qu'il y a des trous.

Yi : Oui, c'est même pas une erreur d'affichage, il manque des signes.

Ludi : Mais peut être bientôt le DejaVu chinois?

Harrisson : Ou reprendre ça d'ailleurs?

Denis : Oui, il y a Arne Götje qui travaille sur une Sans Serif qui serait compatible avec DejaVu, il a accès à une base de donnée avec les traits et il aimerait faire une police de caractères qui soit compatible avec DejaVu. En parlant de caractères asiatiques, il y a une police de caractères pour le japonais qui est assez bien, c'est M+. Avec un licence spécifique, mais une licence libre. Ce qui est intéressant c'est qu'ils font 4 gras différents.

Yi : Oui il y en a une en chinois aussi qui vient de sortir il n'y a pas très longtemps mais avec une seule version pour l'instant qui correspond à la base chinoise.

Denis : Ce qui pourrait aussi être intéressant c'est Droid. Apparemment c'est une licence libre. Ils ont une police fallback avec des caractères chinois en regular.

Yi : J'ai même essayé dans Scribus de comparer avec les typos classiques de Microsoft pour voir la différence et c'est vrai que... enfin l'auteur lui-même précise que ce n'est pas encore au point, il reste des choses à améliorer.

Denis : Ce qui vraiment intéressant aussi c'est dans Pango, il y a un an et demi, ils ont implémenté pour qu'on puisse travailler en lignes verticales.

Ludi : Moi j'ai une dernière question, pour revenir à la base du fonctionnement de DejaVu, au niveau de l'organisation, comment ça se passe? Est-ce que vous travaillez parfois ensemble dans un même lieu ou c'est toujours à distance?

Denis : Pour l'instant c'est toujours à distance. On est quasiment toujours sur IRC, quand il fait jour. (rires) Il y a aussi des gens sur différents fuseaux horaires. Mais donc oui assez souvent on travaille sur IRC. On fait des modifications et puis on fait une capture d'écran, on la met sur un serveur temporaire et on passe le lien sur IRC et on a des commentaires ou bien directement on met ça dans les sources et puis on voit les commentaires.

Pierre : Donc vous avez un mode de communication, un mode humoristique uniquement verbal?

Denis : Oui, on a déjà pensé à as se rencontrer mais ça c'est jamais concrétisé. Avec Ben, on s'est déjà vu plusieurs fois.

Pierre : Ben était à Fosdem aussi non? (Free and Open Source Software Developers' European Meeting )

Denis : Oui.

Pierre : Donc il y a eu un moment où vous étiez ensemble.

Denis : Mais c'est vrai que nous deux on est pas loin, 40 mn... mais toujours par IRC.

OSP : OK. Merci beaucoup Denis.

Denis : C'était un plaisir.

OSP : À bientôt.

What’s the thinking here?

2008-05-30T17:00:00+02:00

Matthew Fuller: One of the things that is notable about OSP is that the problems that you encounter are also described, appearing on your blog. This is something unusual for a company attempting to produce the impression of an efficient ’solution’. Obviously the readers of the blog only get a formatted version of this, as a performed work? What’s the thinking here?

Read the interview: http://www.spc.org/fuller/interviews/open-source-publishing-interview

Matthew Fuller writes about software culture and has a contagious interest in technologies that exceed easy fit solutions. He is David Gee reader in Digital Media at the Centre for Cultural Studies, Goldsmiths College, University of London, edited Software Studies, A Lexicon (MIT Press, 2007), wrote Media Ecologies: Materialist Energies in Art and Technoculture (MIT Press, 2005) and Behind the Blip: Essays on the Culture of Software.

Many of his essays are available on line: http://www.spc.org/fuller

Why you should own the beer company you design for

2007-12-21T01:26:00+01:00

Interview with Dmytri Kleiner

OSP met Venture Communist Dmytri Kleiner late night (thank you Le Coq for the soundtrack!) after his talk InfoEnclosure-2.0, in a bar. We wanted to ask him what his ideas about peer production could mean for the practice of designers and typographers.

Referring to Benjamin Tucker, Yochai Benkler and Marcel Mauss, Kleiner explains how to prevent leakage at the point of scarcity through operating within a total system of worker owned companies. Between fundamentals of media- and information economy, we talk about free typography and what it has to do with nuts and bolts, the problem of working with estimates and why the people that develop Scribus should own all the magazines it enables.

Also speaking is his wife Franziska Kleiner, editor for a German publishing company.

→ kleiner.mp3 [29.10" | 16.7MB]

http://www.telekommunisten.net/

To be continued: meeting Dave Crossland

2007-11-18T23:13:00+01:00

We nearly missed our train back to Brussels while meeting Dave Crossland. At the station we talked about the history of font editing software, about the 'free font movement' and everything that could become possible once fonts and font editing software are free. We were also excited about how (and why!) Dave wants to open up the fine art of typography to a larger public. To be continued with an interview hopefully soon. In the mean time, here you can read his weblog: http://understandinglimited.com/archives/

I think the ideas behind it are beautiful in my mind

2007-07-08T10:42:00+02:00

Interview with George Williams, Fontforge developer

(...) I think the ideas behind it are beautiful in my mind -- and in some sense I find the user interface beautiful. I'm not sure that anyone else in the world does, because it's what I want, but I think it's beautiful. (George Williams, May 2007)

For those who prefer reading over listening, enjoy this text version of the audio interview with George Williams (developer of FontForge) we published earlier.

OSP: We're doing these interviews, as we're working as designers on OpenSource

G: OK

OSP: With OpenSource tools, as typographers, but often when we speak to developers they say "well, tell me what you want," or they see our interest in what they are doing as a kind of feature request or bug report

G: (laughs) Yes

OSP: Of course it's clear that that's the way it often works, but for us it's also interesting to think about these tools as really tools, as ways of shaping work, to try and understand how they are made or who is making them. It can help us make other things. So this is actually what we want to talk about. To try and understand a bit about how you've been working on FontForge. Because that's the project you're working on.

G: OK

OSP: And how that connects to other ideas of tools or tools' shape that you make. These kind of things. So maybe first it's good to talk about what it is that you make.

G: OK. Well... FontForge is a font editor.

I started playing with fonts when I bought my first Macintosh, back in the early 80s (actually it was the mid-80s) and my father studied textual bibliography and looked at the ways the printing technology of the Renaissance affected the publication of Shakespeare's works. And what that meant about the errors in the compositions we see in the copies we have left from the Renaissance. So my father was very interested in Renaissance printing (and has written books on this subject) and somehow that meant that I was interested in fonts.

I'm not quite sure how that connection happened, but it did. So I was interested in fonts. And there was this program that came out in the 80s called Fontographer which allowed you to create PostScript and later TrueType fonts. And I loved it. And I made lots of calligraphic fonts with it.

OSP: You were... like 20?

G: I was 20\~30. Lets see, I was born in 1959, so in the 80s I was in my 20s mostly. And then Fontographer was bought up by MacroMedia who had no interest in it. They wanted FreeHand which was done by the same company. So they dropped Fon... well they continued to sell Fontographer but they didn't update it. And then OpenType came out and Unicode came out and it (Fontographer) didn't do this right and it didn't do that right... And I started making my own fonts, and I used Fontographer to provide the basis, and I started writing scripts that would add accents to latin letters and so on. And figured out the Type1 format so that I could decompose it -- decompose the Fontographer output so that I could add my own things to it. And then Fontographer didn't do Type0 PostScript fonts, so I figured that out.

And about this time, the little company I was working for, a tiny little startup -- we wrote a web html editor -- where you could sit at your desk and edit pages on the web -- it was before FrontPage, but similar to FrontPage. And we were bought by AOL and then we were destroyed by AOL, but we had stock options from AOL and they went through the roof. So... in the late 90s I quit.

And I didn't have to work.

And I went off to Madagascar for a while to see if I wanted to be a primatologist. And... I didn't. There were too many leaches in the rainforest.

OSP: (laughs)

G: So I came back, and I wrote a font editor instead.

And I put it up on the web and in 'late 99, and within a month someone gave me a bug report and was using it.

OSP: (laughs) So it took a month

G: Well, you know, there was no advertisement, it was just there, and someone found it and that was neat!

OSP: (laughs)

G: And that was called PfaEdit (because when it began it only did PostScript) and I... it just grew. And then -- I don't know -- three, four, five years ago someone pointed out that PfaEdit wasn't really appropriate any more, so I asked various users what would be a good name and a French guy said "How 'bout FontForge?" So. It became FontForge then. -- That's a much better name than PfaEdit.

OSP: (laughs)

G: Used it ever since.

OSP: But your background... you talked about your father studying...

G: I grew up in a household where Shakespeare was quoted at me every day, and he was an English teacher, still is an English teacher, well, obviously retired but he still occasionally teaches, and has been working for about 30 years on one of those versions of Shakespeare where you have two lines of Shakespeare text at the top and the rest of the page is footnotes.

And I went completely differently and became a mathematician and computer scientist and worked in those areas for almost 20 years and then went off and tried to do my own things.

OSP: So how did you become a mathematician?

G: (pause) I just liked it.

OSP: (laughs) "just liked it"

G: I was good at it. I got pushed ahead in high school. It just never occurred to me that I'd do anything else -- until I met a computer. And then I still did maths because I didn't think computers were -- appropriate -- or -- I was a snob. How about that.

OSP: (laughs)

G: But I spent all my time working on computers as I went through university. And then got my first job at JPL (Jet Propulsion Laboratory) and shortly thereafter the shuttle blew up and we had some (JPL is part of NASA) -- some of our experiments -- my little group -- flew on the shuttle and some of them flew on an airplane which went over the US took special radar pictures of the US. We also took special radar pictures of the world from the shuttle (SIR-A, SIR-B, SIR-C). And then our airplane burned up. And JPL was not a very happy place to work after that.

So then I went to a little company with some college friends of mine, that they'd started, created compilers and debuggers -- do you know what those are?

OSP: Mm-hmm.

G: And I worked a long time on that, and then the internet came out and found another little company with some friends -- and worked on HTML.

OSP: So when, before we moved, I was curious about, I wanted you to talk about a Shakespearian influence on your interest in fonts. But on the other hand you talk about working in a company where you did HTML editors at the time you actually started, I think. So do you think that is somehow present... the web is somehow present in your -- in how FontForge works? or how fonts work or how you think about fonts?

G: I don't think the web had much to do with my -- well, that's not true. OK, when I was working on the HTML editor, at the time, mid-90s, there weren't any Unicode fonts, and so part of the reason I was writing all these scripts to add accents and get Type0 support in PostScript (which is what you need for a Unicode font) was because I needed a Unicode font for our HTML product.

To that extent -- yes-s-s-s.

It had an effect. Aside from that, not really.

The web has certainly allowed me to distribute it. Without the web I doubt anyone would know -- I wouldn't have any idea how to "market" it. If that's the right word for something that doesn't get paid for. And certainly the web has provided a convenient infrastructure to do the documentation in.

But -- as for font design itself -- that (the web) has certainly not affected me.

Maybe with this creative commons talk that Jon Phillips was giving, there may be, at some point, a button that you can press to upload your fonts to the Open Font Library -- but I haven't gotten there yet, so I don't want to promise that.

OSP: (laughs) But no, indeed there was-- hearing you speak about cchost, that's the--

G: Mm-hmm.

OSP: software we are talking about?

G: That's what the Open Font Library uses, yes.

OSP: Yeah. And a connection to FontForge could change the way, not only how you distribute fonts, but also how you design fonts.

G: It -- it might. I don't know ... I don't have a view of the future.

I guess to some extent, obviously font design has been affected by requiring it (the font) to be displayed on a small screen with a low resolution display. And there are all kinds of hacks in modern fonts formats for dealing with low resolution stuff. PostScript calls them hints and TrueType calls them instructions. They are different approaches to the same thing. But that, that certainly has affected font design in the last -- well since PostScript came out.

The web itself? I don't think that has yet been a significant influence on font design, but then -- I'm no longer a designer. I discovered I was much better at designing font editors than at designing fonts.

So I've given up on that aspect of things.

OSP: Mm-K, because I'm curious about your making a division about being a designer, or being a font-editor-maker, because for me that same definition of maker, these two things might be very related.

G: Well they are. And I only got in to doing it because the tools that were available to me were not adequate. But I have found since -- that I'm not adequate at doing the design, there are many people who are better at designing -- designing fonts, than I am. And I like to design fonts, but I have made some very ugly ones at times.

And so I think I will -- I'll do that occasionally, but that's not where I'm going to make a mark.

Mostly now --

I just don't have the --

The font editor itself takes up so much of time that I don't have the energy, the enthusiasm, or anything like that to devote to another major creative project. And designing a font is a major creative project.

OSP: Well, can we talk about the major creative project of designing a font editor? I mean, because I'm curious how -- how that is a creative project for you -- how you look at that.

G: I look at it as a puzzle. And someone comes up to me with a problem, and I try and figure out how to solve it. And sometimes I don't want to figure out how to solve it. But I feel I should anyway. And sometimes I don't want to figure out how to solve it and I don't.

That's one of the glories of being one's own boss, you don't have to do everything that you are asked.

But -- to me -- it's just a problem. And it's a fascinating problem. But why is it fascinating? -- That's just me. No one else, probably, finds it fascinating. Or -- the guys who design FontLab probably also find it fascinating, there are two or three other font design programs in the world. And they would also find it fascinating.

OSP: Can you give an example of something you would find fascinating?

G: Well. Dave Crossland who was sitting behind me at the end was talking to me today -- he sat down -- we started talking after lunch but on the way up the stairs -- at first he was complaining that FontForge isn't written with a standard widget set. So it looks different from everything else. And yes, it does. And I don't care. Because this isn't something which interests me.

On the other hand he was saying that what he also wanted was a paragraph level display of the font. So that as he made changes in the font he could see a ripple effect in the paragraph.

Now I have a thing which does a word level display, but it doesn't do multi-lines. (or it does multi-lines if you are doing Japanese (vertical writing mode) but it doesn't do multi-columns then. So it's either one vertical row or one horizontal row of glyphs.

And I do also have a paragraph level display, but it is static. You bring it up and it takes the current snapshot of the font and it generates a real truetype font and pass it off to the X windows rasterizer -- passes it off to the standard linux toolchain (freetype) as that static font and asks that toolchain to display text.

So what he's saying is "OK, do that, but update the font that you pass off every now and then." And "Yeah, that'd be interesting to do. That's an interesting project to work on." Much more interesting than changing my widget set which is just a lot of work and tedious. Because there is nothing to think about. It's just "OK, I've got to use this widget instead of my widget." My widget does exactly what I want -- because I designed it that way -- how do I make this thing, which I didn't design, which I don't know anything about, do exactly what I want?

And -- that's dull.

For me.

OSP: Yeah, well.

G: Dave, on the other hand, is very hopeful that he'll find some poor fool who'll take that on as a wonderful opportunity. And if he does, that would be great, because not having a standard widget set is one of the biggest complaints people have. Because FontForge doesn't look like anything else. And people say "Well the grey background --" It used to have a grey background, now it has a white background "is very scary."

I thought it was normal to have a grey background, but uh... that's why we now have a white background. A white background may be equally scary, but no one has complained about it yet.

OSP: Try red.

G: I tried light blue and cream. One of them I was told gave people migraines -- I don't remember specifically what the comment was about the light blue, but

(someone from InkScape): Make it configurable.

G: Oh, it is configurable, but no one configures it.

(InkScaper): Yeah, I know.

G: So...

OSP: So, you talked about spending a lot of time on this project, how does that work, you get up in the morning and start working on FontForge? or...

G: Well, I do many things. Some mornings, yes, I get up in the morning and I start working on FontForge and I cook breakfast in the background and eat breakfast and work on FontForge. Some mornings I get up at 4 in the morning and go out running for a couple of hours and come back home and sort of collapse and eat a little bit and go off to yoga class and do a pilates class and do another yoga class and then go to my pottery class, and go to the farmers' market and come home and I haven't worked on FontForge at all.

So it varies according to the day.

But yes I...

There was a period where I was spending 40, 50 hours a week working on FontForge, I don't spend that much time on it now, it's more like 20 hours, though the last month I got all excited about the release that I put out last Tuesday -- today is Sunday. And so I was working really hard -- probably got up to -- oh -- 30 hours some of that time. I was really excited about the change. All kinds of things were different -- I put in python scripting, which people had been asking for -- well, I'm glad I've done it, but it was actually kind of boring, that bit -- the stuff that came before was -- fascinating.

OSP: Like?

G: I -- are you familiar with the OpenType spec? No. OK. The way you... the way you specify ligatures and kerning in OpenType can be looked at at several different levels. And the way OpenType wants you to look at it, I felt, was unnecessarily complicated. So I didn't look at it at that level. And then after about 5 years of looking at it that way I discovered that the reason I thought it was unnecessarily complicated was because I was only used to Latin or Cyrillic or Greek text, and for Latin, Cyrillic or Greek, it probably is unnecessarily complicated. But for Indic scripts it is not unnecessarily complicated, and you need all those things. So I ripped out all of the code for specifying strange glyph conversions. You know in Arabic a character looks different at the beginning of a word and so on? So that's also handled in this area. And I ripped all that stuff out and redid it in the way that OpenType wanted it to be done and not the somewhat simplified but not sufficiently powerful method that I'd been using up until then.

And that I found, quite fascinating.

And once I'd done that, it opened up all kinds of little things that I could change that made the font editor itself bettitor. Better. Bettitor?

OSP: (laughs) That's almost Dutch.

G: And so after I'd done that the display I talked about which could show a word -- I realized that I should redo that to take advantage of what I had done. And so I redid that, and it's now, it's now much more usable. It now shows -- at least I hope it shows -- more of what people want to see when they are working with these transformations that apply to the font, there's now a list of the various transformations, that can be enabled at any time and then it goes through and does them -- whereas before it just sort of -- well it did kerning, and if you asked it to it would substitute this glyph so you could see what it would look like -- but it was all sort of -- half-baked.

It wasn't very elegant.

And -- it's much better now, and I'm quite proud of that.

It may crash -- but it's much better.

OSP: So you bring up half-baked, and when we met we talked about bread baking.

G: Oh, yes.

OSP: And the pleasure of handling a material when you know it well. Maybe make reliable bread -- meaning that it comes out always the same way, but by your connection to the material you somehow -- well -- it's a pleasure to do that. So, since you've said that, and we then went on talking about pottery -- how clay might be of the same -- give the same kind of pleasure. I've been trying to think -- how does FontForge have that? Does it have that and where would you find it or how is the...

G: I like to make things. I like to make things that -- in some strange definition are beautiful. I'm not sure how that applies to making bread, but my pots -- I think I make beautiful pots. And I really like the glazing I put onto them.

It's harder to say that a font editor is beautiful. But I think the ideas behind it are beautiful in my mind -- and in some sense I find the user interface beautiful. I'm not sure that anyone else in the world does, because it's what I want, but I think it's beautiful.

And there's a satisfaction in making something -- in making something that's beautiful.

And there's a satisfaction too (as far as the bread goes) in making something I need. I eat my own bread -- that's all the bread I eat (except for those few days when I get lazy and don't get to make bread that day and have to put it off until the next day and have to eat something that day -- but that doesn't happen very often).

So it's just -- I like making beautiful things.

OSP: OK, thank you.

G: Mm-hmm.

OSP: That was very nice, thank you very much.

G: Thank you. I have pictures of my pots if you'd like to see them?

OSP: Yes, I would very much like to see them.

Transcription: George Williams :-)

Le grec, c'est du chinois

2007-05-25T14:56:00+02:00

Conversation avec Pierre-Luc Auclair (Déjàvu) et Nicolas Spalinger (OFL)

SIL_deja_vu.mp3 (27 mn - 25 Mb)

Extrait d'une conversation avec Pierre Luc Auclair, graphiste et collaborateur dans le projet de police Déjà vu, et Nicolas Spalinger, bénévole de la SIL, équipe fontes libres Debian et Ubuntu, OFLB.
En français dans le texte, avec quelques questions posées en anglais.
Ou l'on parle de polices de caractère libres, de travail typographique collaboratif, d'apprentissage et de licences & standarts.

Liens:
Déjà vu, SIL, OFL, Gentium font, Andika font, Typophile

Interview: Projet Dejavu et typographie libre et collaborative

P-L: Pierre-Luc Auclair (Typographe Dejavu, Graphiste)
N: Nicolas Spalinger (Bénévole de la SIL – Equipe fontes libres Debian & Ubuntu – Open Font Library)
H: Harrisson
F: Femke

H: Tu travailles sur la fonte Déjavu (http://dejavu.sf.net) c'est ça?

P-L: Oui c'est ça

H: Qui est un projet entièrement open source?

P-L: Oui, c'est ça.

H: Et ça fait déjà un moment que cette fonte existe, non?

P-L: Ca fait... Je ne pourrais pas dire depuis combien de temps exactement, ce qui est sûr c'est qu'avant c'était une fonte de Bitstream (http://www.bitstream.com) qui est sortie ou plutôt qu'ils ont donné au domaine du libre. Et depuis ce temps-là, des gens ont ajouté des fonctionnalités, des choses comme ça-là, plusieurs caractères, des nouveaux languages, ajusté le kerning (http://fr.wikipedia.org/wiki/Kerning), dans le fond ajouté des éléments à la police au complet pour la rendre utilisable.

H: OK donc rajouter des éléments?

P-L: Oui.

H: Chez Bitstream, quelle a été la motivation de lâcher des fontes?

P-L: Alors ça je ne sais pas.

Nicolas: Ca été un partenariat avec la fondation GNOME (http://foundation.gnome.org, http://www.gnome.org/press/releases/bitstreamfonts.html) si je peux m'immiscer dans la conversation.

H: Oui, oui, c'est bien.

P-L: Moi je ne suis pas au courant de ça.

N: Il y a des négociations qui ont été faites entre la fondation GNOME et Bitstream le fondeur, avec des gens comme Jim Gettys (http://en.wikipedia.org/wiki/Jim_Gettys) qui était membre du bureau de la fondation. L'idée c'est d'avoir une famille globale avec suffisamment de...

P-L: ...suffisamment de caractères pour supporter toutes les langues dans Linux avec une seule famille...

N: oui, avoir une famille suffisamment vaste, complète.

H: En faire une fonte système?

N: Enfin oui, système au sens où ça serait la fonte par défaut. Et donc ça a pris des mois quand même pour faire la négociation, entre les termes que la fonderie voulait et ce que la fondation GNOME essayait d'arracher comme droits, de modification notamment. Et donc moi j'ai suivi ça un petit peu. Parce que en même temps nous, dans le cadre de la SIL (http://scripts.sil.org), on réfléchissait aussi à la meilleure stratégie pour faire ça. L'idée c'était d'avoir quelque chose d'assez riche, de bonne qualité, avec du hinting - des instructions - qui soit dédié à un affichage correct sur le bureau.

H: Vous avez eu le choix entre différentes fontes ou bien c'est Bitstream qui vous a proposé juste celle-là?

N: Alors je sais pas vraiment, j'étais pas directement impliqué dans le cadre de la fondation GNOME, j'ai rejoint le projet après.

P-L: Ah oui, il connaît plus ça que moi.

N: Ha ha, non!

N: Je sais qu'ils ont approché d'autres fonderies, mais c'est Bitstream qui a offert ce qui était le plus intéressant.

H: Ah oui, donc il a eu une négociation?

N: Oui il y a eu une négociation qui a eu lieu. Donc il y a vraiment de la part du fondeur une stratégie... lls veulent s'acheter une bonne image, ce qui est légitime et ils veulent aussi protéger quelque part leur nom. Le coeur de la négociation c'était avoir des droits de modification, pour que les gens de la communauté, les typographes de la communauté puisse la modifier, l'étendre, mais que la réputation de Bitstream en tant que fonderie soit plus ou moins protégée. Donc il y a un espèce de point central, de « nexus », qui a été créé entre le droit de modification et le nom même attaché à la police, voilà.

H: Et quand on voit la license, c'est en effet toujours un copyright Bitstream avec droit de modification (http://www.gnome.org/fonts/)

N: Voilà, c'est un droit de modification, donc quand la modification a lieu, le faut que le nom soit changé, et dans le nom même de la police il y a le nom de la fonderie, ce qui est assez fréquent malgré tout. Donc le nom c'était Bitstream Vera et ensuite il y a les variantes. Il y a eu une grosse « press release » puisque c'est un gros pas en avant. Et donc ensuite, il y a toute une équipe qui s'est mis à travailler sur ça, il y a eu plusieurs branches de Vera et, au bout d'un certain temps, la branche la plus importante – Dejavu - a re-mergé les travaux qui ont été faits dans les autres branches. Sur le site de Dejavu il y a l'historique un petit peu des autres branches qui ont été faites (http://dejavu.sourceforge.net/wiki/index.php/Bitstream_Vera_derivatives). Il y a eu une branche par exemple pour les caractères en Gallois, et pour d'autres pays en d'Europe par exemple. Aussi du travail autour des capacités OpenType (http://en.wikipedia.org/wiki/OpenType)...

P-L: oui des capacités Opentype...

N: ...pour les polices intelligentes, ce genre de chose, etc. Ce qui était impressionnant, moi, j'ai observé un peu le projet Dejavu, j'ai pas vraiment contribué, mais c'est la rapidité avec laquelle le projet a avancé.

P-L: et dans le fond, c'est probablement aussi parce qu'il y a une release tous les mois.

N: Oui c'est basé sur un rythme de release actif, tout ce qui est prêt est disponible. Il y a aussi une roadmap bien définie, les outils sont là: outil de révision de contrôle, mailing-list, wiki. L'initiateur du projet c'était Stepan Roh (http://www.srnet.cz/~stepan/en/), et ensuite d'autres personnes.

P-L: Je pourrais pas vraiment donner de noms.

N: Au bout d'un moment il a un peu lâché le projet et a fait d'autres choses mais il a mis en place l'infrastructure, mais là, depuis quelques temps, il est revenu. Et les leaders actuels du projet c'est Denis Jacquerye (http://dejavu.sourceforge.net/wiki/index.php/Denis_Jacquerye) et Ben Laenen (http://dejavu.sourceforge.net/wiki/index.php/Ben_Laenen), je crois, mais il y a plein de monde, plein d'autres gens, la liste des contributeurs est assez vaste. Ben Laenen a d'ailleurs sorti une police musicale, c'est celle qu'on à montré hier. (Euterpe: http://www.openfontlibrary.org)

P-L: Ben moi je les connais avec leurs nicks IRC: lui c'est eimai.

N: Oui eimai et moyogo.

H: Elle est assez bien dessinée en plus, elle est assez jolie.

N: Ce qu'ils ont fait aussi c'est travailler sur un certain nombre de scripts de gestion des fichiers sources. Donc l'outil de base, c'est fontforge (http://fontforge.sourceforge.net), donc je ne pense pas qu'il y en ait qui utilisent des logiciels restreints, normalement tout le monde utilise fontforge.

P-L: Oui toute la source doit rester au format fontforge.

N: Pour faire la construction.

P-L: Quand il a y des modifications pour faire l'import dans la branche principale ça prend absolument le fichier source fontforge pour l'insérer dedans.

N: Il y a aussi du travail aussi sur les instructions, tout ce qui est du positionnement, les ligatures, ils sont assez en avance par rapport aux autres projects collaboratifs. Moi j'ai vu aussi qu'il y avait des scripts pour avoir les statistiques de la couverture Unicode (ttp://www.unicode.org) du SFD (http://fontforge.sourceforge.net/sfdformat.html) par exemple.

P-L: Ca aussi c'est sur le wiki

N: A chaque fois qu'il y a une release, dans le tarball il y a ce quiest couvert par bloc, donc il y a un pourcentage de couverture Unicode par bloc et on voit que ça monte vite, il y a ce qui est prévu par la suite, il y a un changelog. C'est assez riche au niveau descriptif et c'est très ouvert comme approche. Et donc l'utilisation de subversion (http://subversion.tigris.org/) comme dépôt de sources pour travailler en commun dessus. Donc il y a un canal IRC (http://fr.wikipedia.org/wiki/Internet_Relay_Chat) et plusieurs mailing-lists (http://dejavu.sourceforge.net/wiki/index.php/Dejavu-fonts_mailing_list).

P-L: Récemment il y avait quelqu'un qui essayait de refaire le script Grec, je ne sais pas vraiment ce que ça a donné, je ne me suis pas tenu au courant.

N: Alors ça j'ai pas suivi non plus.

P-L: Il avait beaucoup posté son travail sur Typophile, le site web (http://typophile.com/).

N: C'est un site web communitaire, vous connaissez peut-être oui?

P-L: Là-bas il y a beaucoup de gens, beaucoup de professionnels de la typographie, qui leur ont donné des exemples, des experts en typographie qui ont donné leur avis sur comment le projet avançait pour le script Grec. Il ont donné des conseils. Il y a eu un gros débat: est-ce qu'on va plus vers une esthétique du style romain ou alors est-ce qu'on va plus vraiment vers une esthétique grecque locale? Ca c'est toujours un problème, c'est la même chose aussi j'imagine pour les scripts chinois et les scripts japonais.

N: Connaître le degré de sensibilité culturelle pour un bloc particulier Unicode de la police, ça c'est très très dur. Même les meilleurs designers ne peuvent pas avoir une sensibilité suffisante. Plus la police est riche, plus elle couvre de blocs, plus c'est dur justement. Parce qu'il y aura forcément des tensions. Certains blocs sont communs à différents styles. C'est là où ça devient dur d'avoir dans la même police et mettons du cyrillique qui doit avoir un style pour une communauté linguistique qui parle une une langue dans laquelle il y une transcription cyrillique et les Russes qui préfèrent ça comme ça. C'est là où ça devient complexe pour une famille aussi riche comme Dejavu. Ce qui a été fait récemment, c'est une décision qui a été prise, c'est d'avoir une sous-famille Dejavu qui s'appelle LGC, pour Latin Grec Cyrillique pour éviter d'avoir tous les styles ensemble.

H: C'est d'enlever le latin des autres blocs.

N: Puisqu'ils sont quand même assez proches. Il y a du travail qui a été fait au niveau des blocs Arabe et Hébreu.

P-L: il y avait des problèmes avec la baseline qui était pas la même.

N: Il y a des problèmes techniques et aussi des problèmes d'expression de styles. L'avantage vraiment de Dejavu c'est que ça pousse le reste de la « pile » logicielle autour des polices de caractères. Il y a certains mainteneurs comme ceux de Pango (http://www.pango.org) ou de Firefox (http://www.mozilla.com/products/firefox/) qui se disent, « Woouah les typographes de Dejavu exposent encore nos bugs, ahh ».

P-L: Ca arrive assez assez fréquemment. Ha ha ha.

N: Ca prouve qu'il y a une activité assez formidable.

P-L: C'est vrai mais pour revenir aux locales (locl), j'avais beaucoup de difficultés à me mettre dans la peau d'un typographe designer en Grec, un typographe designer en Cyrillique, pour moi personnellement je ne le lis pas, c'est du Chinois, je sais pas du tout ce que c'est. Pour moi, c'est plus une icône qu'un caractère de texte.

N: C'est ça la difficulté en fait. Beaucoup de designers dans la SIL (http://scripts.sil.org/TypeDesign) doivent s'entourer de gens qui connaissent le script pour faire quelques chose de culturellement approprié.

P-L: Parce que si on n'est pas natif dans le script, c'est difficile de dire : est-ce que ça c'est une bonne légibilité dans le script ou est-ce que c'est vraiment merdique.

N: C'est sûr.

H: Est-ce que vous avez des collaborateurs justement Arabes, Chinois ou Japonais, des gens qui sont vraiment dans leur langue?

P-L: Des collaborateurs réguliers ou juste simplement des observateurs?

H: Les deux je dirais...

P-L: Probablement plus des observateurs.

N: Des gens qui rapportent des bugs sur la liste en disant «oh là! il faut pas que ça soit comme ça !»?

P-L: Mais des typographes japonais chinois, je pense pas.

N: Des gens qui envoient des patchs?

H: Des gens qui dessinent carrément des caractères et autres?

N: Sur le site de Dejavu c'est indiqué plus ou moins leur status, si leur travail a été repris via un merge ou s'il sont vraiment actifs. C'est aussi ce qu'on essaie d'encourager dans le cadre de la logique de l'Open Font licence (http://scripts.sil.org/OFL) avec le FONTLOG (http://scripts.sil.org/OFL-FAQ_web#00e3bd04), cet espèce de changelog dédié à la typographie et au design de polices, c'est vraiment de décrire les modifications parce que la plupart des polices propriétaires qu'on a, il y a pas de descriptions, c'est une release finale et voilà.

P-L: Tandis que dans Dejavu c'est un travail constant, mais ça crée aussi des problèmes, si quelqu'un crée un texte avec la police, si tu changes la taille des caractères, si tu changes l'espace entre les lettres, ça va nécessairement tout changer. Donc est-ce qu'on fait un changement pour le mieux dans un certain caractère ou on le garde pour garder le support antérieur?

N: Ca c'est la décision du changement. Ce que je voulais dire, c'est le fait que les changements soient décris très précisément c'est une bonne chose, parce que souvent dans les fontes propriétaires, on ne sait pas ce qui se passe. Voilà, c'est la nouvelle version si ça marche vous êtes content mais si ça marche pas venez nous voir, et donc le changelog est vraiment précis: c'est à dire que telle ou telle personne a ajouté tel bloc ou a fait ce changement-là.

F: (I will ask my questions in English otherwise it takes too long, And you speak French). This way of working is quite different than the way than historically typographers have worked. There seems to be a history of say a lonely man working on their internal piece, and the way you describe the process of designing Dejavu is completely opposite. So, how do you think this is visible or legible in the typeface itself or in the practise of doing typeface design?

N: Il y a un fait fondamental, je pense, c'est la vitesse à laquelle les modifications sont faites. Mais je sais qu'en discutant avec Victor Gaultney (http://www.sil.org/~gaultney), il y a des expérimentations qui ont été faites, en tous cas dans les écoles de dessin de polices, de typographies parfois ils mettent comme ça des étudiants ensemble en disant « travaillez sur une police et ce soir vous nous montrerez ce que vous avez fait ensemble ». Mais le fait d'utiliser ça de manière distribuée via un gestionnaire de révision de contrôle, un canal IRC ou une mailing-list c'est quelque chose qui se fait que depuis quelques mois, quelques années, avec Dejavu et puis d'autres projets que la SIL lance (http://scripts.sil.org/OFL_fonts). Mais c'est vrai qu'initialement c'est quand même un art personnel, élitiste.

P-L: Mais quand même, j'ai lu assez souvent que les typographes, il y a en plusieurs qui ne sont pas vraiment excellents pour faire l'espace entre les lettres, mais ils sont très bons pour faire le lettrage. Certains vont faire le lettrage, un autre va aider à faire l'espacement entre les lettres. Donc c'est souvent un travail collaboratif mais peut-être pas au même niveau que dans Dejavu.

N: Pas commun, c'est-à-dire, je fais mon truc, je te le passe et tu fais ton truc.

H: C'est pas une fragmentation des tâches?

P-L: C'est plus une ligne de montage que de la collaboration.

N: D'accord, je vois.

F: I'm also curious, because many type designers if you hear them speak about their typefaces, they link it - consciously or subconsciously to handwriting - to expression of let's say the style of a person, in a way, like the way something is drawn, which is a very individual expression, and then if you think about the way you work on a typeface, you completly blow that up in a way. Or not?

N: Je pense qu'on retrouverait les styles communs des différents contributeurs quand même, c'est un peu la transparence d'un système de gestion de sources, on peut rajouter quelque chose mais les autres peuvent aussi le modifier aussi donc il faut qu'il se crée une certaine culture des modifications. C'est pour ça qu'il y a ce concept de roadmap, je ne pense pas qu'on perde vraiment la partie style.

F: Non, ce n'est pas perdre, ce qui m'intéresse c'est le changement dans la pratique de faire une lettre, de faire une courbe ensemble.

P-L: Mais il y a quand même le style du caractère qui s'impose aussi quand tu fais ce que tu fais, tu peux pas dire moi je fais le caractère, un script d'une certaine façon, dans le fonds c'est un peu comme ce qu'on a vu dans le documentaire Helvetica (http://www.helveticafilm.com/) hier soir. Il y en avait un qui disait qu'il y avait une espèce de systèmisation du caractère, donc les courbes et toute les parties du lettrage vont avoir une connotation dans une autre lettre. Parce que sinon si tu ne fais pas ça comme ça évidemment, ça va avoir l'air dépareillé.

...

N: Ca serait intéressant de voir un fichier README d'une police libre comme Gentium (http://scripts.sil.org/Gentium), pour voir quels sont les conseils qui sont donnés à ceux qui veulent envoyer des patchs, en terme de formats, en terme de style, en terme de recherche, etc. Le designer quand même reste maître, même si c'est toujours un projet ouvert, il reste maître de la légitimité d'un patch.

F: Maître?

H: Et vous avez des formations de typographie ou de graphisme?

N: Non, pas vraiment, mais ça m'intéresse.

P-L: Je suis designer graphique moi-même, mais j'ai pas eu de formation académique, mais c'est sûr que je lis beaucoup, probablement plus que la majorité des étudiants de design. Dans le fond, c'est sûr que j'aimerais avoir une éducation en tant que telle mais en travaillant on en apprend aussi.

N: C'est quand même beaucoup de choses à apprendre...

P-L: Mais c'est dur d'apprendre seul et de s'établir soi-même un plan d'apprentissage, d'avoir d'autres personnes qui apprennent avec toi, il faut que tu trouves tout toi-même.

P-L: Mais dans un plan communautaire c'est plus facile d'évoluer.

N: C'est pour ça qu'on a comme projet avec Dave Crossland (http://understandingdesign.co.uk/) et d'autres de rendre public les compétences par rapport à la typographie, ce qui était enseigné dans quelques écoles très très prestigieuses par une poignée de gurus, il faudrait que ça soit disponible plus largement.

H: Est-ce qu'il y a une entraide comme ça entre les designers sur les techniques de dessin, sur la manière de procéder? Graphique, je dirais, spécialement graphique?

P-L: C'est sûr qu'actuellement tout le monde à sa façon de faire, son procédé, si vous allez sur Typophile, les gens sont très ouvert pour aider les débutants qui commencent en design typographique, si vous avez des questions sur n'importe quoi, eux ils sont là pour vous aider. Il y a des professionnels qui travaillent chez Adobe, qui ont travaillé sur la spécification OpenType eux-mêmes et qui peuvent vous dire exactement ce dont vous avez besoin.

N: Il faut juste savoir poser sa question de la bonne façon.

H: En respectant leur hiérarchie?

N: Non, non un peu de diplomatie, c'est normal.

P-L: Le domaine typographique est encore beaucoup dans l'espèce de mentalité apprenti/maître, donc c'est souvent l'apprenti qui essaye de se mettre au niveau du maître.

F: For me, as I look at open source projects, and the different ways collaboration is organised, I find this again, this contrast with this stark hierarchy of master and...

P-L: Mais je crois pas que ça soit une hiérarchie explicite, mais plutôt une hiérarchie implicite, souvent celui qui contribue le plus c'est aussi celui lui qui connaît le plus donc c'est lui qui va aider le plus.

N: C'est la méritocratie quelque part, c'est aussi un plaisir pour celui qui connaît les choses de les partager. Mais c'est vrai qu'il y aura toujours ceux qui sont très bons, qui connaissent bien leur domaine et qui ont beaucoup d'expérience et ceux qui commencent juste. Mais il y a un échange. Il y a un plaisir d'échanger les compétences et les connaissances.

H: Et si tu es dans une tradition humaniste, d'effacement de prétention graphique pour un intérêt commun...

N: Pour moi personnellement il y a un but: qu'il y ait plus de systèmes d'écriture qui soient disponibles, que la qualité soit là, que les barrières qui empêchent certaines personnes d'accéder à l'écrit et à ce que l'écrit peut donner comme indépendance, comme autodétermination, etc, que ces barrières puissent s'effondrer. Il y a des recherches qui ont été faites en terme de lisibilité, par rapport à ceux qui apprennent à lire et à écrire par exemple. Plus la fonte est agréable à lire, plus les gens ont envie d'apprendre à lire. Notamment dans les contextes ou c'est des adultes qui apprennent à lire quand il y a des campagnes d'alphabétisation par exemple dans les pays en voie de développement. Il y a vraiment une recherche, si on fait ça avec telle fonte, les résultat seront vraiment médiocres mais si on fait ça avec une autre fonte, il y aura un intérêt, il y aura une passion, il y aura beaucoup plus de gens qui réussiront l'examen d'alphabétisation. Un des projets de la SIL c'est une police dédiée justement à l'alphabétisation, qui s'appelle « Andika » (http://scripts.sil.org/Andika) c'est du Swahili et ça veut dire « écrire ». Il y a une vrai dissociation qui est faite entre certains caractères qui sont peut-être trop proches les uns des autres surtout quand on commence à lire et à écrire il faut qu'il y ait le moins d'ambiguïté possible. C'est un design original mais c'est vraiment une fonte avec une richesse suffisante pour que ça soit disponible dans des langues qui utilisent des scripts complexes, certaines langues africaines aussi où il y a ce type de glyphe. Donc les designers attendent des spécialistes en alphabétisation d'avoir des retours pour améliorer encore le tir. C'est aussi une fonte qui a des variantes, comme ce qui commence à être fait aussi je crois dans Dejavu pour avoir des variantes en fonction du contexte. Parce qu'il y a des gens qui préfèrent un certain type de « a » avec un certain style, etc.

P-L: Donc c'est des « alterns »

N: Double story a, single-story a. Les ligatures, la manière dont les chiffres sont affichés là. Vraiment dans un but d'alphabétisation initiale mais comme c'est un design original il y a beaucoup de gens qui commencent à l'utiliser aussi pour du design comme ça.

H: Comme fonte de travail?

N: Oui, c'est une Sans Serif (http://fr.wikipedia.org/wiki/Sans-serif) qui est un peu le pendant de Gentium, parce c'est fait par les mêmes designers. Il y a eu moins d'efforts par rapport aux inscructions pour l'écran. C'est plus directement pour l'impression mais bon si les linguistes peuvent trouver ça agréable aussi quand ils travaillent sur l'écran, c'est mieux. Mais ça prend plus d'énergie pour les instructions etc. Et puisque que c'est libre les gens peuvent y contributer s'il en ont besoin.

Je sais que certains leader de Déjavu réfléchissent aussi à la légitimité de passer à l'Open Font licence, mais ça ne s'est pas encore fait parce que en amont, Vera est encore sous ce copyright-là. Mais en fait on est en train de négocier, en tous cas il y a une réflexion qui se fait avec Bitstream et GNOME, pour qu'un nouvelle version de Vera sur laquelle ils ont travaillé sorte sour license OFL. Ensuite, comme Dejavu est un dérivé, les développeurs, les designers se rassembleront et voteront pour voir s'ils passent à l'OFL ou pas, parce que actuellement en terme de license il y a Vera et les dérivés de Vera sont licence Vera plus domaine public ou plus quelque chose d'autre. C'est pas vraiment défini quel est le statut des dérivés. Il y a vraiment une richesse sur laquelle on peut bâtir, mais on ne sait pas trop selon quelles règles. c'est un peu le flou. Donc l'idée de l'OFL c'est de clarifier la manière dont les dérivés fonctionnent. Le designer original de Vera s'appelle Jim Lyles (http://www.myfonts.com/person/lyles/jim/), on est en contact avec lui.

F: C'est donc c'est lui qui va décider?

N: Oui lui et sa boîte et ses directeurs. D'ailleurs dans la documentation qui est livrée avec chaque nouvelle release, chaque nouvelle sortie de Dejavu, on voit dans les statistiques de progression ce qui est original, ce qui a été fait par le designer de Bitstream et ce que les nouveaux designers ont ajouté. Donc on voit la progression.

H: Donc il y a un archivage à chaque fois?

N: Oui c'est vraiment décrit. Il y a peu de projets sont aussi décrits.

[...]

Là voilà le changelog, donc chronologiquement inversé. On voit, la première version qui a été donnée dans le cadre du travail à Reading, à l'Université de Reading, voilà quelques bugs qui sont réglés. C'est aussi la logique de dire « voilà les problèmes qui ont été réglés. Il existe des problèmes. » C'est pas comme beaucoup de logiciels propriétaires qui disent « il y a jamais eu de problèmes. Mais si vous achetez la version suivante il y aura plein de nouvelles fonctionnalités » et on vous dit pas tout ce qui a été corrigé. Et là, la source aussi qui est mise avec, ce qui est aussi important pour les polices libres. La définition d'une source pour une police c'est quelque chose d'assez vaste, ça peut être la base de donnée des glyphes, ça peut être les comportements contextuels, OpenType ou Graphite (http://graphite.sil.org), ça peut être les instructions, ça peut être un guide pour le design, c'est-à-dire voilà les choix qui ont été faits, ça peut être de la documentation des scripts pour la construction, pour les statistiques, etc. Voilà aussi « Fix some duplicates» etc. Voilà: « Anyone can create their own modified version ».

F: « using a different name »...

N: L'idée c'est de permettre le branchage: il y a le tronc commun, plein plein de branches peuvent pousser à partir de ce tronc-là, mais il ne faut pas que les branches se prennent pour le tronc. C'est possible qu'une branche puisse avoir plus de fonctionnalité que le tronc mais il ne faut pas que les choses se mélangent. Que les gens qui choisissent des fontes puissent bien identifier d'où ça vient. D'où l'intérêt aussi du changelog, c'est tout dans la description et dans la transparence.

F: Mais il y a déjà des branches?

N: Oui oui, il y a déjà plusieurs branches. Il y a des gens qui ont travaillé sur une version Hébreu, il y a des gens qui ont travaillé sur des langues du Népal je crois, des langues Indiennes aussi, en partant du design de Gentium.

F: So the original design remains but then other language sets are developped. Did you see say design versions, for example people that have adjusted all glyphs or decided to make it like Harrison did a Courrier or Sans-serif, a kind of style changes? C'est possible de faire ça?

N: Oui, c'est tout-à-fait possible, ça serait un changement plus complet, c'est-à-dire qu'on pourrait prendre quelque chose d'existant et repartir plus ou moins de zéro.

P-L: Tant qu'à y être, c'est aussi bien de redémarrer à partir de zéro mais avec une autre idée de ce qu'on peut faire avec cette police.

N: Si le style est vraiment différent c'est plus vraiment un dérivé. L'idée c'est aussi de pouvoir aussi peut-être réutiliser les scripts de statistiques et de construction, les choses qui font partie de cette source de fonte qui peuvent aussi être re-utilisées. Voilà les conseils qui sont donnés aux contributeurs, c'est dit que les branches peuvent exister et que le mainteneur original va continuer à travailler sur le tronc, « develop the canonical version », c'est un peu ça. « We warmly welcome contributions » voilà les conseils qui sont donnés, en terme de format, pour envoyer un patch, en terme de source, voilà qu'est-ce qui est recommandé. Pour les attributions aussi, ça c'est quelque chose qui va plus dans le coeur du mécanisme de license, on a le droit d'ajouter son copyright aux modifications que l'on fait. On hérite le copyright du tronc initial, on peut rajouter le bout qui couvre sa contribution personnelle, bien sûr on n'enlève pas le copyright ancien, mais si on veut reverser quelque chose au tronc ça se fait selon les règles de celui qui maintient le tronc. Dans le cas de Gentium, par exemple, le choix a été fait de remettre le copyright au nom de l'ONG en question. Bon les gens décident au coup par coup. Et donc voilà quand c'est dit là, c'est comme le fichier plans du projet Dejavu, quels sont les trucs sur lesquels on a déjà plus ou moins travaillé, si c'est déjà prêt c'est pas vraiment utile que vous y consacriez du temps puisque c'est déjà fait on va peut-être utiliser ce qu'on a déjà. Mais voilà ce sur quoi on n'a pas encore travaillé, voilà si ça vous intéresse, travaillez dessus, posez-nous vos questions, et on l'intégrera peut-être.

Ici on parle du travail sur le Cyrillique par exemple, un petit avertissement aussi: le format peut changer, le mécanisme de construction peut aussi changer. Il y a aussi la partie Acknowlegements, une espèce de liste qui peut grandir et qui est structurée. Savoir qui a fait quoi, qui a contribué et où et d'avoir les détails. C'est dans la même logique de ce qu'on disait hier dans la présentation pour les métadonnées, c'est utile pour un designer d'exposer ses données, de laisser un peu sa trace quoi. Ce qu'on veut faire c'est que pour les utilisateurs finaux on puisse aller facilement sur le site du designer, sur le site de son organisation peut-être, et de voir ce qu'il a fait dans ce cadre-là. Le fait d'apparaître c'est une bonne chose pour le designer, dans la logique de ne pas garder les choses secrètes et sous scellé, le fait de faire les choses en transparence c'est aussi bénéfique, c'est de la bonne pub, la construction d'une bonne réputation.

Transcrit par Nicolas Spalinger avec quelques corrections mineures pour clarifier les phrases et ajout des URLs pour un meilleur contexte et une meilleure compréhension du mouvement des fontes libres.
Merci à Harrisson et Femke pour leur intérêt pour la typographie libre et collaborative et leur travail de couverture du Libre Graphics Meeting 2007 à Montréal.
Cette transcription est © 2007 Nicolas Spalinger et placée sous licence CC-BY-SA.

A user should not be able to shoot himself in the foot

2007-05-19T08:05:00+02:00

Interview with Andreas Vox, Scribus-developer

While in the background participants to the Libre Graphics Meeting 2007 start saying goodbye to each other, Andreas Vox makes time to sit down with us in the hotel lounge. We want to talk to him about Scribus, the open-source application for professional page layout. Not only as users that do design with it, but also because Scribus helps us think about links between software, free culture and design.

Andreas is a mathematician with an interest in system dynamics, who lives and works in Lübeck, Germany. Together with Franz Schmid, Petr Vanek (subik), Riku Leino (Tsoots), Oleksandr Moskalenko (malex), Craig Bradney (MrB), Jean Ghali and Peter Linnel (mrdocs) he forms the core Scribus developer team. He has been working on Scribus since 2003 and is currently responsible for redesigning the internal workings of its text layout system.

Other interviews with the Scribus team:
http://dot.kde.org/1096453300/
http://www.kde.me.uk/index.php?page=fosdem-interview-scribus

OSP: This weekend Peter Linnel presented amongst many other new Scribus features [1], The Color Wheel, which at the click of a button visualises documents the way they would be perceived by a colour blind person. Can you explain how such a feature entered into Scribus? Did you for example speak to accessibility experts?

A: I don't think we did. The code was implemented by subik [Petr Vanek], a developer from the Czech Republic. As far as I know, he saw a feature somewhere else or he found an article about how to do this kind of stuff, and I don't know where he did it, but I would have to ask him. It was a logic extension of the colour wheel functionality, because if you pick different colours, they look different to all people. What looks like red and green to one person, might look like grey and yellow to other persons. Later on we just extended the code to apply to the whole canvas.

OSP: It is quite special to offer such a precise preview of different perspectives in your software. Do you think it it is particular to Scribus to pay attention to these kind of things?

A: Yeah, sure. Well, the interesting thing is... in Scribus we are not depending on money and time like other proprietary packages. We can ask ourselves: is this useful? Would I have fun implementing it? Am I interested in seeing how it works? So if there is something we would like to see, we implement it and look at it. And because we have a good contact with our user base, we can also pick up good ideas from them.

OSP: There clearly is a strong connection between Scribus and the world of pre-press and print. So, for us as users, it is an almost hallucinating experience that while on one side the software is very well developed when it comes to pdf-export for example, I would say even more developed than in other applications, but than still it is not possible to undo a text-edit. Could you maybe explain how such a discrepancy can happen, to make us understand better?

A: One reason is, that there are more developers working on the project, and even if there was only one developer, he or she would have her own interests. Remember what George Williams said about FontForge... [2] he is not that interested in nice Graphical User Interfaces, he just makes his own functionality... that is what interests him. So unless someone else comes up who compensates for this, he will stick to what he likes. I think that is the case with all open source applications. Only if you have someone interested and able to do just this certain thing, it will happen. And if it is something boring or something else... it will probably not happen. One way to balance this, is to keep in touch with real users, and to listen to the problems they have. At least for the Scribus team, if we see people complaining a lot about a certain feature missing... we will at some point say: “come on, let's do something about it”. We would implement a solution and when we get thanks from them and make them happy, that is always nice.

OSP: Can you tell us a bit more about the reasons for putting all this work into developing Scribus, because a layout application is quite a complex monster with all the elements that need to work together... Why is it important you find, to develop Scribus?

A: I use to joke about the special mental state you need to become a Scribus developer... and one part of it is probably megalomania! It is kind of mountain climbing. We just want to do it, to prove it can be done. That must have been also true for Franz Schmid, our founder, because at that time, when he started, it was very unlikely that he would succeed. And of course once you have some feedback, you start to think: “hey, I can do it... it works. People can use it, people can print with it, do things ... so why not make it even better?”
Now we are following InDesign and QuarkXpress, and we are playing the top league of page layout applications ... we're kind of in a competition with them. It is like climbing a mountain and than seeing the next, higher mountain from the top.

OSP: In what way is it important to you that Scribus is free software?

A: Well... it would not work with closed software. Open software allows you to get other people that also are interested in working on the project involved, so you can work together. With closed software you usually have to pay people; I would only work because someone else wants me to do it and we would not be as motivated. It is totally different. If it was closed, it would not be fun. In Germany they studied what motivates open source developers, and they usually list: 'fun'; they want to do something more challenging than at work, and some social stuff is mentioned as well. Of course it is not money.

OSP: One of the reasons the Scribus project seems so important to us, is that it might draw in other kinds of users, and open up the world of professional publishing to people who can otherwise not afford proprietary packages. Do you think Scribus will change the way publishing works? Does that motivate you, when you work on it?

A: I think the success of open source projects will also change the way people use software. But I do not think it is possible to foresee or plan, in what way this will change. We see right now that Scribus is adopted by all kinds of idealists, who think that is interesting, lets try how far we can go, and do it like that. There are other users that really just do not have the money to pay for a professional page layout application such as very small newspapers associations, sports groups, church groups. They use Scribus because otherwise they would have used a pirated copy of some other software, or another application which is not up to that task, such as a normal word processor. Or otherwise they would have used a deficient application like MS Publisher to do it. I think what Scribus will change, is that more people will be exposed to page layout, and that is a good thing, I think.

OSP: In another interview with the Scribus team [3], Craig Bradney speaks about the fact that the software is often compared with its proprietary competition. He brings up the 'Scribus way of doing things'. What do you think is 'The Scribus Way'?

A: I don't think Craig meant it that way. Our goal is to produce good output, and make that easy for users. If we are in doubt, we think for example: InDesign does this in quite an OK way, so we try to do it in a similar way; we do not have any problems with that. On the other hand... I told you a bit about climbing mountains... We cannot go from the one top to the next one just in one step. We have to move slowly, and have to find our ways and move through valleys and that sometimes also limits us. I can say: “I want it this way” but then it is not possible now, it might be on the roadmap, but we might have to do other things first.

OSP: When we use Scribus, we actually thought we were experiencing 'The Scribus Way' through how it differences from other layout packages. First of all, in Scribus there is a lot more attention for everything that happens after the layout is done, i.e. export, error checking etc. and second, working with the text editor is clearly the preferred way of doing layout. For us it links the software to a more classic ways of doing design: a strictly phased process where a designer starts with writing typographic instructions which are carried out by a typesetter, after which the designer pastes everything into the mock-up. In short: it seems easier to do a magazine in Scribus, than a poster. Do you recognize that image?

A: That is an interesting thought, I have never seen it that way before. My background is that I did do a newspaper, magazine for a student group, and we were using Pagemaker, and of course that influenced me. In a small group that just wants to bring out a magazine, you distribute the task of writing some articles, and usually you have only one or two persons who are capable of using a page layout application. They pull in the stories and make some corrections, and then do the layout. Of course that is a work flow I am familiar with, and I don't think we really have poster designers or graphic artists in the team. On the other hand... we do ask our users what they think should be possible with Scribus and if a functionality is not there, we ask them to put in a bug report so we do not forget it and some time later we will pick it up and implement it. Especially the possibility to edit from the canvas, this will approve in the upcoming versions.

Some things we just copied from other applications. I think Franz (Schmid) had no previous experience with Pagemaker, so when I came to Scribus, and saw how it handled text chains, I was totally dismayed and made some changes right away because I really wanted it to work the way it works in Pagemaker, that is really nice. So, previous experience and copying from another applications was one part of the development. Another thing is just technical problems. Scribus is at the moment internally not that well designed, so we first have to rewrite a lot of code to be able to reach some elements. The coding structure for drawing and layout was really cumbersome inside and it was difficult to improve. We worked with 2.500 lines of code, and there were no comments in between. So we broke it down in several elements, put some comments in and also asked Franz: “why did you did this or that”, so we could put some structure back into the code to understand how it works. There is still a lot of work to be done, and we hope we can reach a state where we can implement new stuff more easily.

OSP: it is interesting how the 2.500 lines of code are really tangible when you use Scribus old-style, even without actually seeing them. When Peter Linnel was explaining how to make the application comply to the conservative standards of the printing business, he used this term 'self-defensive code'...

A: At Scribus we have a value that a file should never break in a print shop. Any bug report we receive in this area, is treated with first priority.

OSP: We can speak from experience, that this is really true! But this robustness shifts out of sight when you use the inbuilt script function; then it is as if you come in to the software through the back-door. From self-defence to the heart of the application?

A: it is not really self-defence... programmers and software developers sometimes use the expression: 'a user should not shoot himself in the foot'. Scribus will not protect you from ugly layout, if that would be possible at all! Although I do sometimes take deliberate decisions to try and do it ... for example that for as long as I am around, I will not make an option to do 'automatic letter spacing', because I think it is just ugly. If you do it manually, that is your responsibility; I just do not feel like making anything like that work automatically. What we have no problems with, is to prevent you from making invalid output. If Scribus thinks a certain font is not OK, and it might break on one or two types of printers ... this is reason enough for us to make sure this font is not used. The font is not even used partially, it is gone. That is the kind of self-defence Peter was talking about. It is also how we build pdf-files and postscript. Some ways of building postscript take less storage, some of it would be easier to read for humans, but we always take an approach that would be the least problematic in a print shop. This meant for example, that you could not search in a pdf [OSP: because the fonts get outlined and/or reencoded]. I think you can do that now, but there are still limitations; it is on the roadmap to improve over time, to even add an option to output a web oriented pdf and a print oriented pdf ... but it is an important value in Scribus is to get the output right. To prevent people to really shoot themselves in the foot.

OSP: Our last question is about the relation between the content that is layed-out in Scribus, and the fact that it is an open source project. Just as an example, Microsoft Word will come out with an option to make it easy to save a document with a Creative Commons License [4]. Would this, or not, be an interesting option to add to Scribus? Would you be interested in making that connection, between software and content?

A: It could well be we would copy that, if it is not already been patented by Microsoft! To me it sounds a bit like a marketing trick ... because it is such an easy function to do. But, if someone from Creative Commons would ask for this function, I think someone would implement it for Scribus in a short time, and I think we would actually like it. Maybe we would generalize it a little, so that for example you could also add other licenses too. We already have support for some meta data, and in the future we might put some more function in to support license managing, for example also for fonts.

About the relation between content and OSS software in general... there are some groups who are using Scribus I politically do not really identify with. Or more or less not at all. If I meet those people on the IRC chat, I try to be very neutral, but I of course have my own thoughts in the back of my head.

OSP: Do you think using a tool like Scribus produces a certain kind of use?

A: No. preferences for work tools and political preference are really orthogonal, and we have both. For example when you have some right wing people they could also enjoy using Scribus and socialist groups as well. It is probably the best for Scribus to keep that stuff out of it. I am not even sure about the political conviction of the other developers. Usually we get along very well, but we don't talk about those kinds of things very much. In that sense I don't think that using Scribus will influence what is happening with it.

As a tool, because it makes creating good page layouts much easier, it will probably change the landscape because a lot of people get exposed to page layout and they learn and teach other people; and I think that is growing, and I hope it will be growing faster than if it is all left to big players like InDesign and Quark... I think this will improve and it will maybe also change the demands that users will make for our application. If you do page layout, you get into a new frame of mind... you look in a different way at publications. It is less content oriented, but more layout oriented. You will pick something up and it will spread. People by now have understood that it is not such a good idea to use 12 different fonts in one text... and I think that knowledge about better page layout will also spread.

[1] http://wiki.scribus.net/index.php/Version_1.3.4%2B_-_New_Features
[2] http://ospublish.constantvzw.org/?p=221
[3] http://www.kde.me.uk/index.php?page=fosdem-interview-scribus
[4] http://creativecommons.org/press-releases/entry/5947

How to catch Ukrainian TV in Moscow

2007-05-15T14:46:00+02:00

Conversation with Igor Novikov and Valek Philippov (SK1)

Excerpts from a conversation with Igor Novikov (Ukraine) and Valek Philippov (Russia) about how and why they are involved in SK1 pre-press software; the joy of reverse engineering and a handy tip for receiving Russian TV in Ukraine too.

igor_valek.mp3 [25mb …

Interview with George Williams (FontForge)

2007-05-07T13:32:00+02:00

Interview (~~unedited files~~) with George Williams, developer of FontForge, the open source font editing tool. Conversation about Shakespeare, Unicode, the pleasure of making beautiful things and pottery. Enjoy!

Listen to the recording :
GW_dl1.mp3 [8.1 mb] and GW_dl2.mp3 [16.6 mb]

... or read the transcription: "I think the ideas behind it are beautiful in my mind"

This interview is part of the book I think that conversations are the best, biggest thing that Free Software has to offer its user.

Tools of the trade

2006-12-11T15:40:00+01:00

Conversation with Ricardo Lafuente

Ricardo Lafuente looks at the way typography, (open source) tools and design economies feed off and into each other. In a few weeks he will publish his text here for you to download. In the mean time, read a few of the ideas we exchanged by e-mail. Comments are of course more than welcome!

RL: I am interested in the way designer's tools, particularly the typographer's, from letterpress to software, have influenced/defined the whole production system.

FS: I think you're right to start thinking about the (r)evolution of type tools, by looking at the interrelation between tools for designing (digitizing?) type, systems for their distribution, and tools for output. It means looking at the development of Fontographer, of typefoundries, but also at the history of Postscript. Although all of these elements are intimately connected, each of the tools in the chain is operated upon by other professionals with different aims.

In Pandora's Hope (1999), Bruno Latour argues that objects and subjects can not be viewed as separate from each other, in other words -- we have been shaped by our artifacts as much as we have shaped them:

Who or what is responsible for the act of killing? Is the gun no more than a piece of mediating technology? ... Which of them, the gun or the citizen, is the actor in this situation? Someone else (a citizen-gun, a gun-citizen) ... You are a different person with the gun in your hand; the gun is different with you holding it.

RL: Besides a historical reference as to the evolution of those tools, I also want to delve upon how the availability/cost/dimensions of the design tools actually shape the design activity.

The main 'cost' in producing typography is time; time needed for development, for proofing and for apprenticeship. Now the price of tools such as Fontographer Fontforge is relatively low or even gratis, digital proofing systems are widely available and there's other materials to design in/with than carving marble, lead molds or photographic systems... all that's left is human hours spent on drawing a typeface or tuning kerning tables.

In that way, the process of developing a typeface is in some aspects similar to developing software and I think typographers should seriously look at open source developments, because it could help in imagining another future than erasure or control. Sharing the work could actually work for typography.

RL: What is the role of those tools in shaping the market and professional relationships (e.g. the way availability/cost/size of tools helped change the environment from craft to commodity)?

FS: I do not think typographic craft has become commodified; the craft has changed and the commodity has changed with it. Again, if you think of type as software, the shift makes sense if you parallel it to the way commodity functions in software (Microsoft vs. MySQL: not that the latter is necessarily more sympathetic, but to base profit on service seems to make more sense than to base profit on distrust)

RL: Since Gutenberg, drawing and printing tools have progressively become more accessible and less bulky. Today, free software means we have access to free tools with no larger a physical footprint as the computer that hosts them. Rid of its physical and economical restraints, what is a design tool today, and more importantly, what can it be? What implications does this have to the whole design field?

With print-to-plate systems, or the way screen typography is (hopefully) developing, you could say that also printing is close to being incorporated. To me the most exciting effects of this convergence of tools, is that in theory design, distribution and use are melting into each other. It could potentially radically change the way typo(graphic) practice works. A designer is not necessarily an authority and the user becomes potentially more than a consumer.

RL: I also found an interesting concept that can help sustain the issue of de-physicalisation (horrible term) of the tools - Radovan Richta's concept of technological evolution and its consequences (particularly, the importance of the switch from manual to mental labour): http://en.wikipedia.org/wiki/Technological_evolution

FS: I am not so sure whether this shift from physical to mental labour should be taken that literally when it comes to software for (type)designers, and whether de-physicalisation is a useful term. Someone like Katherine Hayles writes about the embodiment, and materialization of knowledge beyond the physical in ways that seem to link to the practice of design. In Abstracting Craft: The Practiced Digital Hand, Malcolm Mccullough describes how tools shape our perspective, i.e. how physical and mental work inform each other:

Tool usage simultaneously involves direct sensation, provides a channel for creative will, and affirms a commitment to practice. The latter is quite important: only practice produces the most lasting and satisfying form of knowledge.

and later on:

A tool directs your attention. Its function becomes your focus: as the saying goes, when you hold a hammer, all the world looks like nails.

(Or should we say with Latour that when you hold a gun, everyone looks like potential victim... ;-))

Physicality shifts place, but we still have bodies: hands operating keyboards, trackpads; eyes that judge, limbs suffering from RSI. To often, craft is made synonymous with 'handmade' and software ubiqutous – in short: craft is not solely manual, and software is not body-less

Maybe those two truisms could help rethink craft beyond the patriarchal master-apprentice system that is still en vogue with typographers. The problem with type-design is, that it is often thought of as signature; writing in purified form. But in a networked world this cannot be the only way to do type. Typographers, while using digital tools for longer than most of us, have a hard time to let go of a closed model of authorship, and a hierarchical approach to teaching. I am not sure why it the stereotypical image of the lonely, ascetic, male typographer fighting against all odds for the survival of an undervalued secret craft seems so necessary to be maintained.

RL: Is the market model and the typographer/designer's activity accounting for this evolution, or is it lagging behind? And what would be a feasible alternative that could account for authorship safeguards? And why should it be open?

FS: I am convinced that a more progressive form of licensing, and an open source approach to the development of typefaces is absolutely necessary for typography to survive. The amount of policing necessary to check illegal copies would be absurd. It is impossible but most of all undesirable to technically protect typefaces; this form of Digital Rights Management will come at the cost of typographies fluidity and ability to be truly embedded.

Also, typefaces are getting more complicated now since they are often shared over multiple computers with different locales and operating systems. So it seems important to engage in a collaboration with people across borders to continue to develop typefaces fit for todays texts (I do not think we have enough typography already!). Think about networked typography, dynamic type, print on demand... When the bezier curves and kerning tables are made available to be studied, adjusted, discussed by communities of people I think this could mean a whole new life for an old discipline.

You need to copy to understand

2006-08-06T15:43:00+02:00

Interview with Harrisson

One of the co-conspirators in this open source adventure is a Brussels graphiste going under the name Harrisson. His interest in open source software flows with the culture of exchange that keeps the off centre music scene alive, as well as with the humanist tradition persistingly present in contemporary typography.
Harrissons' visual frame of reference is eclectic and vibrant, including modernist giants, vernacular design, local typographic culture, classic painting, drawing and graffiti. Too much food for one conversation.

_____________________________

You could say that "A typeface is entirely derivative", but others argue, that maybe the alphabet is, but not the interpretations of it.

The main point of typography and ownership today is that there is a blurred border between language and letters. So: now you can own the 'shape' of a letter. Traditionally, the way typographers made a living was by buying (more or less expensive) lead fonts, and with this tool they printed books and got paid for that. They got paid for the typesetting, not for the type. That was the work of the foundries. Today, thanks to the digital tools, you can easily switch between type design, type setting and graphic design.

What about the idea that fonts might be the most 'pirated' digital object possible? Copying is much more difficult when you've got lead type to handle!

Yes, digitalisation changed the rules. Just as mp3 changed the philosophy of music. But in typography, there is a strange confrontation between this flux of copied information, piracy and old rules of ownership from the past.

Do you think the culture of sharing fonts changed? Or: the culture of distributing them? If you look at most licenses for fonts, they are extremely restrictive. Even 99% of Free Fonts do not allow derivative works.

Warning message when attempting to embed a font in InDesign

The public good culture is paradoxally not often there. Or at least the economical model of living with public good idea is not very developed. While I think typography, historically, is always seen as a way to share knowledge. Humanist stuff.

The art and craft of typeface design is currently headed for extinction due to the illegal proliferation of font software, piracy, and general disregard for proper licensing etiquette.

http://redesign.emigre.com/FAQ.php

Emigré... Did they not live from the copyrights of fonts?!

You are right. They are like a commercial record company. Can you imagine what would happen if you would open up the typographic trade - to 'open source' this economy? Stop chasing piracy and allow users to embed, study, copy, modify and redistribute typefaces?

Well we are not that far from this in fact. Every designer has at least 500 fonts on their computer, not licenced, but copied because it would be impossible to pay for!

Even the distribution model of fonts is very peer-to-peer as well. The reality might come close, but font licenses tell a different story.

I believe that we live in an era where anything that can be expressed as bits will be. I believe that bits exist to be copied. Therefore, I believe that any business-model that depends on your bits not being copied is just dumb, and that lawmakers who try to prop these up are like governments that sink fortunes into protecting people who insist on living on the sides of active volcanoes.

Cory Doctorow in http://craphound.com/bio.php

I am not saying all fonts should be open, but it is just that it would be interesting when type designers were testing and experimenting with other ways of developing and distributing type, with another economy.

Yes, but fonts have a much more reduced user community than music or bookpublishing, so old rules stay.

Is that it? I am surprised to see that almost all typographers and foundries take the 'piracy is a crime' side on this issue. While typographers are early and enthusiastic adapters of computer technology, they have not taken much from the collaborative culture that came with it.

This is the 'tradition' typography inherited. Typography was one of the first laboratories for fractioning work for efficiency. It was one of the first modern industries, and has developed a really deep culture where it is not easy to set doubts in. 500 years of tradition and only 20 years of computers.The complexity comes from the fact it is influenced by a multiple series of elements, from history and tradition to the latest technologies. But it is always related to an economic production system, so property and 'secrets-of-the-trade' have a big influence on it.

I think it is important to remember how the current culture of (not) sharing fonts is linked to its history. But books have been made for quite a while too.

Open source systems may be not so much influencing distribution, licenses and economic models in typography, but can set original questions to this problematic of digital type. Old tools and histories are not reliable anymore.

Yes. with networked software it is rather obvious that it is useful to work together. I try to understand how this works with respect to making a font. Would that work?

Collaborative type is extremely important now, I think. The globalisation of computer systems sets the language of typography in a new dimension. We use computers in Belgium and in China. Same hardware. But language is the problem! A French typographer might not be the best person to define a Vietnamese font. Collaborativity is necessary! Pierre Huyghebaerttold me he once designed an Arabic font when he was in Lebanon. For him, the font was legible, but nobody there was able to read it.

But how would you collaborate than? I mean... what would be the reason for a French typographer to collaborate with one from China? What would that bring? I'm imagining some kind of hybrid result... kind of interesting.

Again, sharing. We all have the idea that English is the modern Latin, and if we are not careful the future of computers will result in a language reductionism.

What interest me in open source, is the potential for 'biodiversity'.

I partially agree, and the open source idea contradicts the reductionist approach by giving more importance to local knowledge. A collaboration between an Arabic typographer and a French one can be to work on tools that allow both languages to co-exist. Latex permits that, for example. Not QuarkXpress!

Where does your interest in typography actually come from?

I think I first looked at comic books, and then started doodling in the margins of schoolbooks. As a teenager, I used to reproduce film titles such as Aliens, Terminator or other sci-fi high-octane typographic titles.

Basically, I'm a forger! In writing, you need to copy to understand. Thats an old necessity.
If you use a typeface, you express something. You're putting drawings of letters next to each other to compose a word/text. A drawing is always emotionally charged, which gives color (or taste) to the message. You need to know what's inside a font to know what it expresses.

How do you find out what's inside?

By reproducing letters, and using them. A Gill Sans does not have the same emotional load as a Bodoni. To understand a font is complicated, because it refers to almost every field in culture. The banners behind G.W. Bush communicate more than just 'Mission Accomplished'. Typefaces carry a 'meta language'.

http://voice.aiga.org/content.cfm?ContentAlias=%5Fgetfullarticle&aid=2131398

It is truly embedded content

Exactly!

It is still very difficult to bridge the gap between personal emotions and programming a font. Moreover, there are different approaches, from stroke design to software that generates fonts. And typography is standardisation.

The first digital fonts are drawn fixed shapes, letter by letter, 'outstrokes'. But there is another approach where the letters are traced by the computer. It needs software to be generated. In Autocad, letters are 'innerstroke' that can vary of weight. Letterrors' Beowolf is also an example of that kind of approach.

http://www.letterror.com/foundry/beowolf/

It's a very interesting way to work, but the font depends on the platform it goes with. Beowolf only works on OS9. It also set the question of copyright very far. It's a case study in itself.

So it means, the font is software in fact?

Yes, but the inter-dependance between font and operating systems is very strong, contrary to a fixed format such as TrueType. For printed matter, this is much more complicated to achieve. There are in-between formats, such as Multiple Master Technology for example. It basically means, that you have 2 shapes for 1 glyph, and you can set an 'alternative' shape between the 2 shapes. At Adobe they still do not understand why it was (and still is) a failure...

I really like this idea... to have more than one master. Imagine you own one master and I own the other and than we adjust and tweak from different sides. That would be real collaborative type! Could 'multiple' mean more than one you think?

It is a bit more complicated than drawing a simple font in Fontographer or Fontforge. Pierre told me that MM feature is still available in Adobe Illustrator, but that it is used very seldomly. Multiple Master fonts are also a bit complicated to use. I think there were a lot of bugs first, and then you need to be a skilled designer to give these fonts a nice render. I never heard of an alternative use of it, with drawing or so. In the end it was probably never a success because of the software dependency.

While I always thought of fonts as extremely cross media. Do you remember which classic font was basically the average between many well-known fonts? Frutiger?

Fonts are Culture Capsules! It was Adrian Frutiger. But he wasn't the only one to try... It was a research for the Univers font I think. Here again we meet this paradox of typography: a standardisation of language generating cultural complexity.

Sketch for Univers by Adrian Frutiger

Univers. That makes sense. Amazing to see those examples together. It seems digital typography got stuck at some point, and I think some of the ideas and practices that are current in open source could help break out of it.

Yes of course. And it is almost virgin space.

In 2003 the Danish government released Union, a font that could be freely used for publications concerning Danish culture. I find this an intrigueing idea, that a font could be seen as some kind of 'public good'.

http://www.identifont.com/show?BW8

I am convinced that knowledge needs to be open... (speaking as the son of a teacher here!). One medium for knowledge is language and its atoms are letters.

But if information wants to be free, does that mean that design needs to be free too? Is there information possible without design?

This is why I like books. Because it's a mix between information and beauty - or can be. Pfff, there is nothing without design... It is like is there something without language, no?

If the design thinking is correct, the tools should be irrelevant

2006-08-06T14:56:00+02:00

Interview with Pedro Amado (TypeForge)

(Type) designer Pedro Amado is amongst many other things initiator of TypeForge, a website dedicated to the development of 'collaborative type' with open source tools. While working as design technician at FBAUP, he is about to finish a MA with a paper on collaborative methods for the creation of art and design projects. When I e-mailed him about open font design and how he sees that developing, he responded with a list of useful links, but also with:

"Developing design teaching based on open source is one of my goals, because I think that is the future of education."

This text is based on the conversation about design, teaching and software that followed.

______________________________________

You told me you are employed as 'design technician'... what does that mean?

It means that I provide assistance to teachers and students in the Design Department. I implemented scanning/printing facilities for example, and currently I develop and give workshops on Digital Technologies – software is a BIG issue for me right now!

Linux and Open Source Software are slowly entering the design spaces of our school. For me it has been a 'battle' to find space for these tools. I mean - we could migrate completely to OSS tools, but it's a slow progress. Mainly because people (students) need (and want) to be trained in the same commercial applications as the ones they will encounter in their professional life.

How did Linux enter the design lab? How did that start?

It started with a personal curiosity, but also for economical reasons. Our school can't afford to acquire all the software licenses we'd like. For example, we can't justify to pay approx. 100 x 10 € licenses, just to implement the educational version of Fontlab on some of our computers; especially because this package is only used by a part of our second year design students. You can image what the total budget will be with all the other needs...

I personally believe that we can find everything we need on the web. It's a matter of searching long enough! So this is how I was very happy to find Fontforge. An open source tool that is solid enough to use in education and can produce (as far as I have been able to test) almost professional results in font development.

At first I couldn't grasp how to use it under X on Windows, so one day I set out to try and do it on Linux... and one thing lead to another...

What got you into using OSS? Was it all one thing leading to another?

Uau... can't remember... I believe it had to do with my first experiences on line; I don't think I knew the concept before 2000. I mean I've started using the web (IRC and basic browsing) in 1999, but I think it had to do with the search of newer and better tools...

I think I also started to get into it around that time. But I think I was more interested in copyleft though, than in software.

Oh... (blush) not me... I got into it definitely for the 'free beer' aspect!

By 2004 I started using DTP applications on Linux (still in my own time) and began to think that these tools could be used in an educational context, if not professionally. In the beginning of 2006 I presented a study to the coordinator of the Design Department at FBAUP, in which I proposed to start implementing Open Source tools as an alternative to the tools we were missing. Blender for 3D animation, FontForge for type design, Processing for interactive/graphic programming and others as a complement to proprietary packages: The Gimp, Scribus and Inkscape to name the most important ones.

I ran into some technical problems that I hope will be sorted out soon; one of the strategies is to run these software packages on a migration basis - as the older computers in our lab won't be able to run MacOS 10.4+, we'll start converting them to Linux.

I wanted to ask you about the relation between software and design. To me, economy, working process, but also aesthetics are a product of software, and at the same time software itself is shaped through use. I think the borders between software and design are not so strictly drawn.

It's funny you put things in that perspective. I couldn't agree more. Nevertheless I think that design thinking prevails (or it should) as it must come first when approaching problems. If the design thinking is correct, the tools used should be irrelevant. I say 'should' because in a perfect environment we could work within a team where all tools (software/hardware) are mastered. Rarely this happens, so much of our design thinking is still influenced by what we can actually produce.

Do you mean to say that “what we can think is influenced by what we can make”? This would work for me! But often when tools are mastered, they disappear in the background and in my opinion that can become a problem.

I'm not sure if I follow your point. I agree with "the border between design and software is not so strict" nevertheless, I don't agree with "economy, process and aesthetics are a product of software". As you've come to say what we think is influenced by what we can make... this is an outside observation...

A technique is produced inside a culture, therefore one's society is conditioned by it's techniques. Conditioned, not determined" (LÉVY, 2000)

Design, like economics and software, is a product of culture. Or is it the other way around? The fact is that we can't really tell what comes first. Culture is defined by and defines technology. Therefore it's more or less simple to accept that software determines (and is determined) by it's use. This is an intricate process... it kind of goes roundabout on itself...

And where does design fit in in your opinion? Or more precisely: designers?

Design is a cultural aspect. Therefore it does not escape this logic. Using a practical standpoint: Design is a product of economics and technology. Nevertheless the best design practices (or at least the one's that have endured the test of time) and the most renowned designers are the one's that can escape the the economic and technological boundaries.

The best design practices are the ones that are not products of economics and technology... they are kind of approaching a universal design status (if one exists). of course... it's very theoretical, and optimistic... but it should be like this... otherwise we'll stop looking for better or newer solutions, and we'll stop pushing boundaries and design as technology and other areas will stagnate.

On the other hand, there is a special 'school' of thought manifested through some of the Portuguese Design Association members, saying that the design process should lead the process of technological development. Henrique Cayate (I think it was in November last year) said that "design should lead the way to economy and technology in society." I think this is a bit far fetched...

Do you think software defines form and/or content? How is software related to design processes?

I think these are the essential questions related to the use of OSS. Can we think about what we can make without thinking about process? I believe that in design processes, as in design teaching, concepts should be separated from techniques or software as much as possible.

To me, exactly because techniques and software are intertwined, software matters and should offer space for thinking (software should therefore not be separated from design).

You could also say: design becomes exceptionally strong when it makes use of its context, and responds to it in an intelligent way. Or maybe I did not understand what you meant by being "a product of". To me that is not necessarily a negative point.

Well... yes... that could be a definition of good design, I guess.

I think that as a cultural produce, techniques can't determine society. It can and will influence it, but at the same time it will also just happen. When we talk about Design and Software I see the same principle reflected. Design being the "culture" or society and software being the tools or techniques that are developed to be used by designers. So this is much the same as "which came first? The chicken, or the egg?" Looking at it from a designers (not a software developers) point of view, the tools we use will always condition our output. Nevertheless I think it's our role as users to push tools further and let developers know what we want to do with them. Whether we do animation on Photoshop, or print graphics on Flash that's our responsibility. We have to use our tools in a responsible way. Knowing that the use we make of them will eventually come back at us. It's a kind of responsible feedback.

Using Linux in a design environment is not an obvious choice. Most designers are practically married to their Adobe Suite. How come it is entering your school after all?

Very slowly! Linux is finally becoming valuable for Design/DTP area as it has been for long on the Internet/Web and programming areas. But you can't expect The Gimp to surpass Photoshop. At least not in the next few years. And this is the reality. If we can, we must train our students to use the best tools available. Ideally all tools available, so they won't have problems when faced with a tool professionally.

The big question is still, how we besides teaching students theory and design processes (with the help of free tools), help them to become professionals. We also have to teach them how to survive a professional relationship with professional tools like the Adobe Suite. As I am certain that Linux and OSS (or FLOSS) will be part of education’s future, I am certain of it’s coexistence along side with commercial software like Adobe’s. It’s only a matter of time. Being certain of this, the essential question is: How will we manage to work parallel in both commercial and free worlds?

Do you think it is at all possible to 'survive' on other tools than the ones Adobe offers?

well... I seem not to be able to dedicate myself entirely to these new tools...

To depend solely on OSS tools... I think that is not possible, at least not at this moment. But now is the time to take these OSS tools and start to teach with them. They must be implemented in our schools. I am certain that sooner or later this will be common practice throughout European schools.

Can you explain a bit more, what you mean by 'real world'?

Being a professional graphic designer is what we call the 'real world' in our school. I mean, having to work full time doing illustration, corporate identity, graphic design etc. to make a living - deliver on time to clients and make a profit to pay the bills by the end of the month!

Do you think OSS can/should be taught differently? It seems self-teaching is built in to these tools and the community around it. It means you learn to teach others in fact ... that you actually have to leave the concept of 'mastering' behind?

I agree. The great thing about Linux is precisely that - as it is developed by users and for users - it is developing a sense of community around it, a sense of "given enough eyeballs, someone will figure it out"

Well, that does not always work, but most of the time...

I believe that using open source tools is perfect to teach, especially first year students. Almost no one really understands what the commands behind the menus of Photoshop mean, at least not the people I've seen in my workshops. I guess The Gimp won't resolve this matter, but it will help them think about what they are doing to digital images. Especially when they have to use unfamiliar software.

You first have to teach the design process and then the tool can be taught correctly, otherwise you’ll just be teaching habits or tricks. As I said before, as long as design prevails and not the tool/technique, and you teach the concepts behind the tools in the right way, people will adapt seamlessly to new tools, and the interface will become invisible!

Do you think this means you will need to restructure the curriculum? I imagine a class in bugreporting... or getting help on line...

mmhh... that could be interesting. I've never thought about it in that way. I've always seen bugreporting and other community driven activities as part of the individual aspect of working with these tools... but basically you are suggesting to implement an 'open source civic behavior class' or something like that?

Ehm... Yes! I think you need to learn that you own your tools, meaning you need to take care of them (ie: if something does not work, report) but at the same time you can open them up and get under the hood... change something small or something big. You also need to learn that you can expect to get help from other people than your tutor... and that you can teach someone else.

The aspect of taking responsibility, this has to be cultivated - a responsible use of these tools. About changing things under the hood... well this I think it will be more difficult. I think there is barely space to educate people to hack their own tools let alone getting under the hood and modifying them.

But you are right that under the OSS communication model, the peer review model of analysis, communication is getting less and less hierarchical. You don't have to be an expert to develop new or powerful tools or other things... A peer-review model assumes that you just need to be clever and willing to work with others. As long as you treat your collaborators as peers, whether or not they are more or less advanced than you, this will motivate them to work harder. You should not disregard their suggestions and reward them with the implementations (or critics) of their work.

How does that model become a reality in teaching? How can you practice this?

Well... for example use public communication/distribution platforms (like an expanded web forum) inside school, or available on the Internet; blog updates and suggestions constantly; keep a repository of files; encourage the use of real time communication technologies... as you might have noticed is almost the formula used in e-learning solutions.

And also often an argument for cutting down on teaching hours.

That actually is and isn't true. You can and will (almost certainly) have less and less traditional classes, but if the teachers and tutors are dedicated, they will be more available than ever! This will mean that students and teachers will be working together in a more informal relationship. But it can also provoke an invasion of the personal space of teachers...

It is hard to put a border when you are that much involved. I am just thinking how you could use the community around Open Source Software to help out. I mean... if the on line teaching tools would be open to others outside the school too, this would be the advantage. It would also mean that as a school, you contribute to the public domain with your classes and courses.

That is another question. I think schools should contribute to public domain knowledge. Right now I am not sharing any of the knowledge about implementing OSS on a school like ours with the community. But if all goes well I'll have this working by December 2006. I'm working on a website where I can post the handbooks for workshops and other useful resources.

I am really curious about your experiences. However convinced I am of the necessity to do it, I don't think it is easy to open education up to the public, especially not for undergraduate education.

I do have my doubts too. If you look at it on a commercial perspective, students are paying for their education... should we share the same content to everyone? Will other people explore these resources in a wrong way? Will it really contribute to the rest of the community? What about profit? Can we afford to give this knowledge away for free, I mean, as a school this is almost our only source of income? Will the prestige gained, be worth the possible loss? These are important questions that I need to think more about.

OK, I will be back with you in 6 month to find out more!

My last question... why would you invest time and energy in OSS when you think good designers should escape economical and technological boundaries?

If we invest energy on OSS tools now, we'll have the advantage of already being savvy by the time they become widely accepted. The worst case scenario would be that you've wasted time perfecting your skills or learned a new tool that didn't become a standard... How many times have we done this already in our life? In any way, we need to learn concepts behind the tools, learn new and different tools, even unnecessary ones in order to broaden our knowledge base – this will eventually help us think 'out of the box' and hopefully push boundaries further [not so much as escaping them].

For me OSS and its movement have reached a maturity level that can prove it's own worth in society. Just see Firefox - when it reached general user acceptance level (aka 'project maturity' or 'development state'), they started to compete directly with MS Internet Explorer. This will happen with the rest (at least that's what I believe). It's a matter of quality and doing the correct broadcast to the general public.

Linux started almost as a personal project and now it’s a powerhouse in programming or web environments. Maybe because these are areas that require constant software and hardware attention it became an obvious and successful choice. People just modified it as they needed it done. Couldn’t this be done as effectively (or better) with commercial solutions? Of course. But could people develop personalized solutions to specific problems in their own time frame? Probably not…

But it means that the people involved are, or can resource to, computer experts. What about the application of these ideas to other areas? The justice department of the Portuguese government (Ministério da Justiça) is for example currently undergoing a massive informatics (as in the tools used) change – they are slowly migrating their working platform to an Open Source Linux distribution – Caixa Mágica (although it’s maintained and given assistance by a commercial enterprise by the same name). By doing this, they’ll cut costs dramatically and will still be able to work with equivalent productivity (one hopes: better!). The other example is well known. The Spanish region of Estremadura looked for a way to cut costs on the implementation of information technologies in their school system and developed their own Linux Distro called Linex – it aggregates the software bundle they need, and best of all has been developed and constantly tweaked by them.

Now Linux is becoming more accessible for users without technical training, and is in a WYSIWYG state of development, I really believe we should start using it seriously so we can try and test it and learn how we can use in in our everyday life (for me this process has already started…).

People aren't stupid. They're just 'change resistant'. One of the aspects I think that will get peoples' attention will be that a 'free beer' is as good as a commercial one.