Category Archives: Scribus

Turning tools into instruments

June 13, 2012 Gimp, LGRU, MyPaint, Performance, Piksels and lines, playing, Scribus, sound

The Piksels and Lines Orchestra (PLO)

If we turned our tools into instruments, could we experience Libre Graphics as an ensemble? What would be the performative potential of lay-out and drawing, and how to listen to the sound of a pixel, or to the tune of a line?

In response to these curious questions, The Libre Graphics Research Unit developed a prototype for The Piksels and Lines Orchestra. In a single afternoon, several well-known Libre Graphics tools were networked using standard protocols. The ‘Instrumented’ versions of Scribus, MyPaint, SketchSpace and GIMP were made to send their actions (everything that is saved to the undo/redo-history) as HTTP GET requests to The Underweb so that any completed brushstroke, transform or text-change made by the Orchestra’s Instruments would be displayed on a screen. From here, we used Lyd to sonify actions with the help of the LibreOffice sound-effects.
Simultaneously, Players were saving their results into git. A PureData-patch pulled from the repository and provided ambiant sounds based on processing the outcomes of The Instruments. Finally, through OpenFrameworks, we visualised the growing image-collection on-screen.

We started thinking about The PLO in the Demonstrating the Unexpected workshop with Brendan Howell

Pierre Huyghebaert drawing the PLO-diagram

Multiple visual outputs

The Orchestra performed two sets of about an hour, exploring the improvised connections between design-production and experimental sound. The differences in tonality of the various instruments were obvious, even if this was just a quick sketch. Scribus proved to be interesting to play; the action-history of this page-lay-out tool is fine-grained, and it’s large variety of operations is clearly defined. The range of sounds produced by MyPaint appeared to be less rich then we expected; to turn a drawing tool into an instrument, it might have been more interesting to take mouse-positions into account. Although exciting because it was the only web-accessible Instrument involved, playing SketchSpace was a little less gratifying due to the high granularity of actions that made it hard to actually perceive causal relations between a change on canvas and it’s sonification.

Ana Carvalho and Pierre Marchand playing Scribus

Pippin playing Lyd

Playing MyPaint while Brendan explains

Adding sound-feedback to lay-out broke the usual boredom of putting elements to the grid. The pleasure of connecting these different tools through a minimum of negotiation and a maximum of improvisation allowed them to express their character to each other and with each other. Free, Libre and Open Source Design practice will never be the same again :-)

100 idées

March 6, 2012 Co-position, file-format, ideas, LGRU, Scribus, standards, Unicode, versioning, whitespace

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

Colorfont
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. http://manufacturaindependente.com/colorfont/

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). http://blog.manufacturaindependente.org/2012/02/implied-spacing

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. http://xvm-2-183.ghst.net

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 http://unicornify.appspot.com 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: http://oep-h.com/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: http://www.cgemy.com/public/Scribus_whiteSpaceAction.pdf

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. http://pzwart3.wdka.hro.nl/~lspeybroeck/whitespace/5.svg

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: http://git.constantvzw.org/?p=osp.tools.visualculture.git

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: http://lgru.pad.constantvzw.org:8000/42. Thank you for making this four rigorous, rich and productive days!

The Libre Graphics Research Unit

Pen and paper

October 10, 2011 Co-position, Contest, LGRU, Libre Graphics Meeting, pen, Scribus, Tools, Vocabulary, Watch this thread, writing

The LGM splash

An M for Meeting

Something old, something new, something borrowed, something blue.

For the 5th edition of the Libre Graphics Meeting, OSP proposed to replace the paint splash by an abstract drawing of three squares forming a flag and also the letter M.1 The splash had been in use since 2006 and some community members felt alienated by the proposal. On 10/10/2009 AL explained on the CREATE-mailinglist: “The main issue for OSP, is that we don’t think continuity can be resolved by going back to the paint splash. We honestly feel it misrepresents the pleasure of using and developing Libre Graphics Tools and we have consciously decided to work with imagery that avoids such remediation.“2

Two years later, the Scribus Icon Contest (deadline October 31!)3 seems to have run into a similar argument. One of the proposals features yet another stylized iteration of a fountain pen:

Original Scribus logo

Scribus 1.3.5 introduced: Handwritten textboxes

Calligraphy AND textboxes. Proposal: Ian Hex

I am not the only one who doubts the calligraphic turn. LD responds:
“The pen has been around for ages. Yet, a pen has not much to do with DTP and has always seemed to me a bit out of topic or a bit misleading. Typography is not calligraphy. No pen is involved in the work, really. It’s also arguable what a “scribe” has to do with DTP but here I find myself more comfortable since the scribe’s work was in fact to put down the ideas on paper. From that to layout, I think the link is pretty clear.“4
GP does not altogether agree: “I think the connection makes some sense in that you have something of a depiction of the work of a scribe, which at least connects to the name Scribus. Furthermore, scribes worked as individuals, sometimes adding embellishments of drop caps and artwork in the margins (primitive layout) and were therefore much like the idea of an individual doing publishing on his own.“
He adds: “The difficulty with using computers, screens, mice, keyboards, etc., is that these might be used in the logo for almost any software”

Avoiding the problem: Adobe InDesign (2011)

Reverse evolution: From a typographer's portrait to a writing tool. Aldus Pagemaker (1985)

An individual doing publishing on his own?

It puzzles me why the Scribus community — like other Libre Graphics projects — would want to ignore the rich source of imagery provided by their own object of development. Some keywords for a dreamt logo:
Box, Canvas, Chain, Character, Colour, Column, Curve, Diagram, Document, Figure, Font, Frame, Gap, Grid, Guide, Hyphen, Image, Layer, Line, Margin, Masterpage, Origin, Padding, Page, Pagenumber, Paragraph, Path, Point, Script, Sentence, Shape, Space, Stream, Stroke, Style, Table, Word.

  1. http://ospublish.constantvzw.org/news/watch-this-thread-lgm-site-and-logo-proposal
  2. http://lists.freedesktop.org/archives/create/2009-October/002091.html
  3. http://forums.scribus.net/index.php?topic=243.0
  4. http://lists.scribus.net/pipermail/scribus/2011-October/044555.html

Python week, day 1

September 12, 2011 Abstracting craft, Co-position, LGRU, Python, Samedies, Scribus

This morning: Review of lists, dictionaries, arrays, functions, loops.
Afternoon: Remembering how to speak to the Scribus-API (results possibly less abstract tomorrow). For now:

instructions = ['Don't read', {'Take': ['paper', 'rods', 'blocks']}, ['set them out', 'color', 'build']]

:-)

Don’t read

September 12, 2011 Co-position, El Lissitzky, lay-out, LGRU, Proun, Python, Samedies, Scribus, Vocabulary

Exercise for next week:

"From the phrase Don't read, a line extends horizontally and then angles diagonally downward to the word Take, from which extend three short lines that connect the words paper, rods, blocks to the rest of the phrase. To the right of this cluster is the phrase, set them out, color, build"

[Description of About Two Squares (instruction page), El Lissitzky’s revolutionary children’s book. In: Margolin, Victor. The Struggle for Utopia: Rodchenko, Lissitzky, Moholy Nagy, The University of Chicago Press, 1997]

+

Think Python: How to Think Like a Computer Scientist
by Allen B. Downey

+

[The Open Source DTP application Scribus can be automated via a scripting API using Python. Booklet: The F*cking Manual, by OSP]

=

?