Category Archives: whitespace

Support de Fortune

[W]hat then, would become of it — this context — if transferred? — if translated? Would it not rather be traduit (traduced) which is the French synonyme, or overzezet (turned topsy-turvy) which is the Dutch one? 1

SdF-1aprilThis month, Kristien Van den Brande installed her research Support de Fortune in the vitrine of Recyclart, Brussels.

“How do supports of writing — a book or a single piece of paper, pencils, typewriters or internet pages — work on our thoughts? How do ‘chance supports’ (a train ticket, the back of an envelope, the margin of a book) challenge common ideas and practices of archiving, binding, displaying, reproducing, translation?”

With Jonathan Lahey Dronsfield, Nick Thurston we contributed artist talks and performative readings, adding to the rich collection of material (books, references, ideas) that Kristien had brought together. It was a welcome opportunity to revisit many familiar themes, an occasion for a re-take of A Romance of Many Dimensions and a first try-out of Technical Writing.

100 idées

A first harvest of future tools that were brought to the surface at the Co-position Research Meeting:

The days of monochrome digital typography are over. Inspired by art-deco hand-drawn lettering experiments, Manufactura Independente came up with colorfont.js. This javascript library makes it easier to create multi-colored typography for the web. It was further developed and documented in the slipstream of meeting.

Commit unbaked area only
From the understanding that design files are always collections of elements (each with their own properties and timelines), we tried to think how to version selectively. A design file contains both fixed and fluid areas (some elements stabilize early on, and others might keep changing), could we think of a way to mark areas as ‘unbaked’ and only track changes for these areas?

Comparing processes
Versioning a design-file means tracking changes between different stages in a process, rather than comparing lines in code. Looking at a diff for a Scribus file is at best confusing, and current versioning tools are not helping much to understand differences that matter to design. Since each program is already saving state data, could we use this information to make more intelligent versioning possible? Inspired by so-called edit-decision lists that are used to store edits outside the actual rendered video-file, we discussed the possibility of recording a creative process rather than the result of it. If the data is stored in a separate file, could this be used to reconstruct a design? What kind of ‘actions’ would it need to contain?

Conversational control
If we see design as a practice that seeks to articulate collisions, how could computers be of use to help organise them, to make them visible and legible? We worked on scenarios for potential conversations between computers and designers, interaction between computational optimization and design decisions. This prototype would also have an option ‘just start over’.

Do all these elements need to fit on one page? YES
Should all elements be legible? YES
Can we make this page bigger? NO
[system makes a proposal]
Do you like this better?
[user making changes] YES

Implied spacing
Saving space without negative effects on legibility, could that be possible? This script removes all spaces between words and creates a gradient in letter colouring instead. As a word gets closer to its end, each letter gets progressively lighter (Python script, works with Scribus API).

Lazy Landscape lay-out
We looked into Lazy Landscape, a novel way of sharing and running software inside our browsers. While we explored and got baffled by its intricacies and fixed a few bugs, we wondered how far we could take it to have a new kind of layout tool based on flows and filters. It took us only an afternoon to create the skeleton of a text engine.

Meaningful hashes
A commit signifies a difference that matters, but they are identified with a row of arbitrary numbers. How could these hashes be more meaningful? Could they express something about the character of the commit? How could they be more visual? We looked at and developed some images of our own.

More ideas for whitespace implementation
When we started imagining tools from the perspective of whitespace, we came up with many ideas for new types of lay-out. A few examples:

Multi-level type design interfaces
Type design is an iterative process of refining design directions. Starting from a better understanding of what happens when you design a font, we worked on a type design environment that moves more fluently between different scales of design: From single glyphs to letter-pairs and textblocks but also to move between different versions of both digital and hand-drawn sketches. Some of these features can be already discovered in Fontmatrix:

Save-as commit
Adding a ‘save-as-commit’ option to Inkscape, Scribus and/or Gimp could prevent the sometimes unnecessary harsh transition from design environment to git. Hypothesis: If commit-actions would be better integrated into the design workflow, the spirit of the design process might be better preserved in the commit history.

Shared undo histories
Programs already save undo histories, so why can’t we write those changes as commits? This idea got also referred to as ‘shared action lists’, but that sounds a lot less promiscuous. We liked the possibility of distributing painful discoveries and propagating our mistakes.

Space revelator
Space revelator is a tool to test the way Scribus acts on white spaces (and its support). It uses a squared-glyph font to help designing spaces:

Toonloop-audio (or: Philip Glass machine)
In a parallel workshop taking place at JES, A Pure Data patch was developed that records audio fragments while Toonloop grabs a frame, and than plays it back in sync. So now Toonloop can do multimedia stopmotion!

Ultra-geometric space
What if we could generate believable lay-outs based on almost-right interpretations of classic rules? A persiflage on canonical grid lay-out or how to make Villard eat a snake.

Unicode remapper
The Unicode Standard is far from easy to navigate. A complicated war history of competing interests and ever-changing ideas about how to make place for All Languages of The Universe means that related glyphs are often spread out over 17 ‘planes’ and sometimes even fractured into multiple code-points. Why not make it easier for users to re-arrange glyphs according to their needs? We could work with experts to design pre-sets for specifc languages. Rarely used glyphs could be pushed into the periphery and more common ones could take center stage. These re-mappings can than be loaded into type design applications such as Fontforge. This could stimulate type-designers to prioritize their work on sets of relevant glyphs, instead of just concentrating on the first plane(s).

Visual Culture
We tried to rethink the text-only and bureaucratic interfaces of current commit-repositories. What if you could visualize the depth of changes, the variety of mimetypes involved. What if you could understand difference at a glance?
OSP developed a working prototype that we tested and tried:

practice shapes tools shapes practice
Implied spacing
PH explains how multi-level type design interfaces could work
Relaxed Folder Icon by ES
Lazy Landscape acts on a glyph
Toonloop performance @ FOam
CG reveals patterns in Scribus lay-out
SVG from scratch
Colorfont is selectable text

Many people contributed to these ideas: Thank you for making this four rigorous, rich and productive days!

The Libre Graphics Research Unit