Category Archives: Tech Stuff: The Gory Details

Detailed descriptions of tech problems and solutions – in mind-numbing or exhilarating detail, depending on whether you should be reading this or not.

Kiln development: convenience features

Until recently, Kiln has felt to me like a bare bones developer’s tool, providing a simple but powerful framework for doing whatever XML publishing you might want, without any hand holding beyond some common elements added on to Cocoon. That has changed, somewhat, to the extent that now a new user, completely unfamiliar with XSLT, is guided in a new project to a site displaying TEI as HTML, complete with faceted search, without touching any code.

This, coupled with the new tutorial, hopefully makes Kiln a much more attractive proposition to those who are not so technically inclined (or who have not been forced to use and learn it by working at DDH!). Now I’ve gone back to adding in elements that aid the developer, and I’ll describe three of those.

Continue reading Kiln development: convenience features

New Backup and Disaster Recovery System

As you know, we run most of our systems on virtual machines on top of a VMWare ESXi 4.1 cluster, which is located at the University of London Computer Centre off Russell Square. The cluster runs with a SAN (disk array) providing  20TB of storage (in RAID10 format for speed) for virtual machine operating systems and data.

In order to further protect ourselves and our partners from loss of data and service, we have just installed a new backup system comprising:

1) Veeam Backup & Replication software on the VMWare cluster

2) A system with approximately 24TB of disks in RAID6 format housed in a Dell MD1000 disk enclosure which allows for upto 2 concurrent disk failures. Continue reading New Backup and Disaster Recovery System

Digital Humanities – under the hood

DDH has been undertaking a major infrastructure project – a complete server renewal – over the past few months which we’re just about to complete, and we thought it might be interesting to say a bit more about the project, and the way in which we run our server infrastructure.

Once this work is complete – and the migration from old infrastructure to new is now underway (hooray!) – we will have a robust, resiliant and high performance development environment and platform for hosting our web-based projects which will last us for a full five years, with a sustainability and replacement plan taking us well into the future. It’s taken us a while to get here – as well as the support of College and a fair bit of creative thinking all round – but we now have the flexibility to support and sustain projects of all sizes.  We have modest annual costs associated with the collocation of our servers but our sustainability planning covers this, and otherwise we’re self-sufficient, and this is a great place for a department like ours to be.

Continue reading Digital Humanities – under the hood

Event-handling bug in IE7/8 with Raphaël

Recently I’ve been using the Raphael Javascript library for creating complex browser-based visualisations. Mostly it’s been a positive experience – but the development cycle conforms to the standard pattern of getting everything looking pretty in the standards-compliant browsers, and then setting aside a couple of days to get the thing working in the IE family of browsers.

Generally speaking, Raphael does an amazing job of porting nice, clean, standards-compliant SVG over to IE 6/7/8’s horrendous native RVML format support. But ironing the kinks out of my viz application did manage to flush out one IE bug that Raphael doesn’t handle: IE does not register events bound to SVG paths when their opacity is set to zero. Rects, circles, and yes, even ellipses, will trigger events when transparent. But paths won’t.

Fortunately the fix is simple: assigning the path an opacity of 0.01 allows it to trigger and has no visible manifestation on-screen.

It’s an ugly hack. And it’s not necessary for IE9, which does offer SVG support. But for the moment it does the job.

Mixing and matching SVG and Text

One of the happier side-effects of the recent Apple vs. Adobe fracas is that it has led to the widespread rediscovery of Scalable Vector Graphics as a means of displaying illustrations and animations on the web. Long the poster-child of standards nerds, SVG was a spec I’d heard of before – but only in contexts that suggested its sole raison d’etre was to be yet another standard with which to beat IE6 over the head for not implementing. I’d looked into it, briefly, back in 2003 or so – but the syntax was forbidding (XML isn’t offhand the format you’d think best suited for describing graphics) and the documentation unfriendly to the point of absurdity. I didn’t think of looking at it again until I started thinking a bit about visualisations for humanities data, and needed a cross-platform iDevice-compatible animation medium.

And what a happy rediscovery that was: clearly, I owe the standards nerds an apology. There are now a couple of good Javascript libraries available for SVG (Raphael and a JQuery plug-in) that fix all the x-browser problems for you and help smooth away SVG’s awkward XML-ness – which is, furthermore, nowhere near as difficult as I’d concluded it was all those years ago. The spec is (reasonably) small, supple, and does what you want it to with a bare minimum of muss and fuss. All that and SVG elements exist within the DOM – meaning that, unlike children of the <canvas> element, you can access them using standard JS traversal methods, trigger events affecting the rest of the page with them, etc.

In fact, SVG would be pretty much perfect for creating highly interactive, data-intensive pages – were it not for the way it handles text. There is a text element in the SVG spec – but it doesn’t do what you want it to: i.e., style or wrap like HTML text does. And the workarounds are horrendous.

After a bit of Googling I discovered what seemed like a solution: the svg:foreignObject element can wrap non-SVG objects, and I was assured that in this way I could simply drop HTML content into the middle of my SVG code and all would be well.

Except, of course, that it wasn’t. In place of the lovingly-prepared HTML content I’d been expecting to appear in the middle of my screen, I got nothing. Nada. Nyet. Zip. Zilch. Nothing. And upon tracking the foreignObject examples back to their lair, I saw the reason why: while Raphael and JQuery assume that what you’re trying to do is drop SVG elements into the middle of a standard HTML page, foreignObject code only renders properly in all browsers tested if the page is served with MIME-type svg. Which of course then banjaxes every standard HTML element you’ve got on your page, i.e., most of it.

It seemed, for an embarrassingly long time, like this was a show-stopper, before the key to the solution occurred to me – that there’s absolutely no reason why the HTML elements ‘within’ an SVG graphic need to be children of the SVG element itself. Using Raphael (and presumably JQuery, though I haven’t tested this), your first step is to define the area that will hold your SVG graphic by specifying its coordinates (x and y) and dimensions (width and height). After that, you’re probably going to spend some time positioning graphical objects within this area, using the same metrics. And at that point you’ve got all the information you need simply to append your HTML elements after the SVG outer element and position them absolutely ‘inside’ it.

It’s so ridiculously easy I’ll repeat that again: don’t bother with the workarounds in SVG. Just position your HTML absolutely and on top of it.

This is, admittedly, a kludge – but it works, it’s easy – and it lets you spend all the time you would have wasted trying to get the svg:text and svg:tspan elements working across different data actually working on the visualisation.