by

“The Song of Wandering Aengus”

Click here to view the exhibit.

One last little experiment with Neatline-powered interactive typesettings – this time with the ending of Yeats’ endlessly recitable “The Song of Wandering Aengus,” which, like many great poems, seems to somehow signify the entire world and nothing really in particular. I chose to use just the last three lines so that it would be possible to play with a more dramatic type of geometric nesting that, with more content, would quickly run up against the technical limitation that I mentioned in Wednesday’s post about “A Coat” – the vector geometry used to form the letters starts to degrade as the Javascript environment runs out of decimal precision at around 40 levels of zoom, making it impossible to continue the downward beyond a certain point.

With just three lines, though, I was able to place each consecutive line completely inside of one of the dots above an “i” in the previous line. So, the “silver apples of the moon” are inscribed into the dot over the “i” in the “till” of “till time and times are done,” and the “golden apples of the moon” are then contained by the dot on the “i” in “silver.” Since the nested lines are placed literally inside the shaded boundaries of letters (as opposed to the empty spaces delineated by the “holes” in letters, as was the case with the first two experiments), the color of the text has to alternate in order to be legible against the changing color of the backdrop. What I didn’t expect (although in retrospect I guess it’s obvious) is that this shift in the color palette completely modulates the visual temperature of the whole environment – the backdrop swerves from bright white to solid black back and then back to white over the course of the three lines, with the last transition mapping onto the night-to-day, moon-to-sun thematic movement in the final couplet.

Interestingly, this effect was almost thwarted by another unexpected quirk in the underlying technologies, although I managed to maneuver around it with a little hack in the exhibit theme. The problem was this – it turns out that OpenLayers will actually stop rendering an SVG geometry ones the dimension of the viewport shrinks down below a certain ratio relative to the overall size of the shape. So, in this case, as the camera descends down into the black landscape of the dot over the first “i,” the black background supplied by the vector shape would suddenly drop away, as if the camera were falling through the surface, which of course had the effect of making the second-to-last line – typeset in white – suddenly invisible against the default-white background of the exhibit.

I thought this was a showstopper, but then I realized that I could programmatically “fake” the black background by directly flipping the CSS background color on the exhibit container. So, I just fired up the Javascript console, inspected the zoom attribute on the OpenLayers instance to get the zoom thresholds where the color changes needed to happen, and then dropped a little chunk of custom code into the exhibit theme that manifests the style change in response to the zoom events triggered by the map:

Weird, but effective. Whenever I work on projects like these I’m fascinated by the wrinkles that arise in the interaction between what you want to do and what the technology allows you to do. It’s very different from analog scholarship or art practice, where you have a more complete mastery over the field of play – you have a much more direct and unmediated control over the sound of your words, the shape of a line in a physical sketch, the pressure of a brush stroke. With digital objects, though, you’re building on top of almost unimaginably huge stacks of technology – the millions of man-hours of work that it took to create the vast ecosystem of Javascript and PHP libraries that Neatline depends on, the whole set of lower-level technologies that shape the underlying browser rendering engines and Javascript runtimes, which in turn are implemented in still lower-level languages, which eventually brush up against the dizzying rabbit hole of physical hardware engineering, which to my mind is about as close to magic as anything that people have produced.

That kind of deep, massively-distributed collaboration can definitely exist offscreen (eg., all of intellectual history, in a sense), but it’s more loosely coupled, and certainly less fragile – if I write an essay about Yeats, Yeats can’t break in the way that a code dependency literally can (will). At first this really bothered me, but I’ve come to peace with it – digital work is by definition a relinquishing of control, a give-and-take with the machine, a negotiation with our current little slice of modernity about what’s possible.

by

More fun with interactive typesetting: “A Coat,” by Yeats

Click here to view the exhibit.

After spending the weekend tinkering around with an interactive typesetting of a couplet from Macbeth that tried to model reading as a process of zooming downward towards the end of the phrase, I became curious about experimenting with the opposite analogy – reading as an upward movement, an climb from the bottom (the beginning) to the top (the end), with each word circumscribing everything that comes before it. Really, this is just the flip side of the same coin. Meaning certainly flows “downhill” in a phrase – each word is informed by the previous word. But it also flows back “uphill” – each word casts new meaning onto what comes before it. What would it would feel like to visualize that?

This time I decided to work with “A Coat,” Yeats’ wonderful little ode to simplicity (he renounces what he thinks to be the stylistic affectation of his work from the 1890’s, and announces an intention to write “naked[ly]“). Originally, I planned to exactly invert the layout of the Macbeth couplet – start with the “I” at the bottom of the stack, and work upwards towards the end with “naked,” which, in the final frame, would geometrically contain each of the preceding words. I started to do this, but quickly ran into an interesting computational obstacle, which actually cropped up in the Shakespeare example as well.

Trip Kirkpatrick noticed the problem:

Indeed, the last two words – “way” and “comes” – are pixelated and malformed:

way

comes

This wasn’t on purpose – I couldn’t figure out why it was happening when I was working on the exhibit, but decided against trying to fix it, half out of laziness and half because the visual effect had some satisfying affinities with the content of the line, especially when paired with the “descending” motif – a plunge down to hell, where order disintegrates, smooth lines are forbidden, etc. Anyway – after thinking it over, I’m pretty sure I know what’s going on, although I’m not certain. At the extremely deep zoom levels (far beyond anything you’d ever need for a regular map), I think that OpenLayers is actually losing the floating point precision that it needs to accurately plot the SVG paths for the letters – the computer is running out of decimal places, essentially.

I squeaked by with the Macbeth couplet, but this turned out to be a showstopper for the Yeats, since I was effectively trying to plot geometry about four and a half times deeper – 45 words versus 11. At that depth, the text becomes completely illegible, so I had to find a way to squeeze more content into fewer zoom levels. In the end, I managed to fit it all in by positioning each line into a geometric “notch” formed by the ascenders of two letters on the following line, which more or less preserves the philosophical rationale of the exhibit (each bit of text “envelops” the previous, if somewhat less completely than before) while limiting the zooming to just ten magnification contexts, one for each line.

heel

To scan the poem, just zoom out by clicking on the “minus” button (or scrolling the mouse wheel or pinching the screen, if applicable), or click on the lines in the reference text at the top left to auto-focus on a particular part of the poem.

by

Experimental typesetting with Neatline and Shakespeare

Click here to view the exhibit.

I’ve always been fascinated by the geometric structure of text – the fact that literature is encoded as physical, space-occupying symbols that can be described, measured, and manipulated just like any other two-dimensional shapes. There’s something counter-intuitive about this. When I look at a letter or a word, I see particles of sound and meaning, transcendental cognitive forms, not things that could be straightforwardly described as a chunks of vector geometry. And there’s definitely a truth to this – I do think that texts have a kind of extra-physical cognitive essence that’s independent of their visual instantiations on pages or screens, and that it’s usually this common denominator that’s most interesting when we talk about literature with other people. And yet, in the context of any individual reading, the physical structure of documents – the set of pragmatic decisions that go into the design, layout, and formatting of text on the page – can have subtle but significant effects on how a text feels, on the imaginative dreamscape that surrounds it in your mind when you think back on it days or weeks or years after the fact.

This is definitely true, for example, at the level of some-thing like font selection, which encodes a kind of “meaning metadata” about the text – where it comes from, who it’s intended for, how serious it imagines itself to be, etc. But I think it also holds at the level of more incidental, pseudo-random aspects of typesetting. For example, how does the vertical line traced out by the right margin of a paragraph or stanza color the reader’s affective reaction to the literary content? Does a jagged, unjustified border make the text feel more tumultuous and Dionysian? Would the same text, printed with a justified margin, become more emotionally controlled and orderly? I think of cases like Whitman’s long lines, which often have to be prematurely broken at the right edge of the page, resulting in a kind of clumpy, disorganized visual gestalt. I doubt that Whitman intended this, in the strong sense of the word (although I don’t know that he didn’t), but it has a kind of symbolic affinity with the poetry itself – sprawling, organic, uncontainable. When I think of Whitman, the image that appears in my mind consists largely of this. I wonder what it would be like to read an “unbroken” Leaves of Grass, printed on paper wide enough to accommodate the lines? Would it become more metaphysical, detached, ironical? Or would it be just the same?

Anyway, this kind of speculation fascinates me. I’ve been thinking a lot recently about experimental modes of digital typesetting that would be completely impossible on the analog page – new ways of presenting text on screens to evoke certain feelings or model intuitions about the structure of language. As a quick experiment, I decided to use Neatline to try to capture a certain aspect of my experience of reading Shakespeare. I’ve always been interested in the notion of language as kind of progressive enveloping of words – they’re printed side-by-side on the page as equals, but the meaning of a syntagm grows out of the ordering of the tokens. Each exists in the context of the last and casts meaning onto the next; each word is contained, in a sense, inside the sum of its predecessors. I was taken by this idea when I read Saussure and company in college, because it seemed to map onto my own experience of reading poetry – the sensation of scanning a line always felt more like a descent than a left-to-right movement, a shift from the surface (the beginning) to the center (the end).

To play with this, I built a Neatline exhibit that typesets a single Shakespearean couplet in a kind of recursive, fractal, Prezi-like layout in which each successive word is “physically” embedded inside of one of the letters of the previous word. Reading the couplet literally becomes a matter of magnification, zooming, burrowing downwards towards the end of the syntagm. To scan the fragment, either pan and zoom the environment manually, as you would a regular, Google-like slippy map, or click on the words in the reference text at the bottom of the screen to automatically focus on individual slices of the text.

by

Neatline 2.1.0

[Cross-posted from scholarslab.org]

We’re pleased to announce the release of Neatline 2.1.0! This is a fairly large maintenance release that adds new features, patches up some minor bugs, and ships some improvements to the UI in the editing environment. Some of the highlights:

  • A “fullscreen” mode (re-added from the 1.x releases), which makes it possible to link to a page that just displays a Neatline exhibit in isolation, scaled to the size of the screen, without any of the regular Omeka site navigation. Among other things, this makes it much easier to embed a Neatline exhibit as an iframe on other websites (eg, a WordPress blog) – just set the src attribute on the iframe equal to the URL for the fullscreen exhibit view. Eg:

    Thanks coryduclos, colonusgroup, and martiniusDE for letting us know that this was a pain point.

  • A series of UI improvements to the editing environment that should make the exhibit-creation workflow a bit smoother. We bumped up the size of the “New Record” button, padded out the list of records, and made the “X” buttons used to close record forms a bit larger and easier-to-click. Also, in the record edit form, the “Save” and “Delete” buttons are now stuck into place at the bottom of the panel, meaning that you don’t have to scroll down to the bottom of the form every time you save. Much easier!

    neatline-2.1

  • Fixes for a handful of small bugs, mostly cosmetic or involving uncommon edge cases. Notably, 2.1.0 fixes a problem that was causing item imports to fail when the Omeka installation was using the Amazon S3 storage adapter, as we do for our faculty-project installations here at UVa.

Check out the release notes on GitHub for the full list of changes, and grab the new code from the Omeka add-ons repository. And, as always, be sure to send comments, concerns, bug reports, and feature requests in our direction.

In other Neatline-related news, be sure to check out Katherine Jentleson’s Neatline-enhanced essay “‘Not as rewarding as the North’: Holger Cahill’s Southern Folk Art Expedition,” which just won the Smithsonian’s Archives of American Art Graduate Research Essay Prize. I met Katherine at a workshop at Duke back in the spring, and it’s been a real pleasure to learn about how she’s using Neatline in her work!

by

Parsing BC dates with JavaScript

Last semester, while giving a workshop about Neatline at Beloit College in Wisconsin, Matthew Taylor, a professor in the Classics department, noticed a strange bug – Neatline was ignoring negative years, and parsing BC dates as AD dates. So, if you entered “-1000″ for the “Start Date” field on a Neatline record, the timeline would display a dot at 1000 AD. I was surprised by this because Neatline doesn’t actually do any of its own date parsing – the code relies on the built-in Date object in JavaScript, which is implemented natively in the browser. Under the hood, when Neatline needs to work with a date, it just spins up a new Date object, passing in the raw string value entered into the record form:

Sure enough, though, this doesn’t work – Date just ignores the negative sign and spits back an AD date. And things get even funkier when you drift within 100 years of the year 0. For example, the year 80 BC parses to 1980 AD, bizarrely enough:

Obviously, this is a big problem if you need to work with ancient dates. At first, I was worried that this would be rather difficult to fix – if we were hitting up against bugs in the native implementation of the date parsing, it seemed likely that Neatline would have to get into the tricky business of manually picking apart the strings and putting together the date objects by hand. It’s always feels icky to redo functionality that’s nominally built into the programming environment. But I didn’t see any other option – the code was unambiguously broken as it stood, and in a really dramatic way for people working with ancient material.

So, grumbling at JavaScript, I started to sketch in the outlines of a bespoke date parser. Soon after starting, though, I was idly fiddling around with the Date object in the Chrome JavaScript terminal when stumbled across an unexpected (and sort of inexplicable) solution to the problem. In reading through the documentation for the Date object over at MDN, I noticed that the constructor actually takes three different configuration of parameters. If you pass in a single integer, it treats it as a Unix timestamp; if you pass a single string, it treats it as a plain-text date string and tries to parse it into a machine-readable date (this was the process that appeared to be broken). But you can also pass three separate integers – a year, a month, and a day. Out of curiosity, I plugged in a negative integer for the year, and arbitrary values for the month and day:

Magically, this works. A promising start, but not a drop-in solution for the problem – in order to use this, Neatline would still have to manually extract each of the date parts from the plain-text date strings entered in the record forms (or break the dates into three parts at the level of the user interface and data model, which seemed like overkill). Then, though, I tried something else – working with the well-formed, BC date object produced with the year/month/day integer values, I tried casting it back to ISO8601 format with the toISOString method. This produced a date string with a negative date and…

…two leading zeros before the four-digit representation of the year. I had never seen this before. I immediately tried reversing the process and plugging the outputted ISO string back into the Date constructor:

And, sure enough, this works. And it turns out that it also fixes the incorrect parsing of two-digit years:

I am deeply, profoundly perplexed by this. The ISO8601 specification makes cursory note of an “expanded” representation for the year part of the date, but doesn’t got into specifics about how or why it should be used. Either way, though, it works in all major browsers. Mysterious stuff.