As I mentioned previously, one of the requirements for us on the W3C Staff to be allowed to publishing media content is to make sure it meets some minimal level of accessibility, and in the current (draft) state of affairs, this means providing a transcription of its content. (Oct 8 2009: that policy is now publicly available)

My first reaction to that policy was slightly annoyed: I was afraid this would create too high a barrier on us from publishing multimedia content, which in this age and days seems to be a fairly important expression mechanism.

But the argument was made that we don’t publish non-valid HTML documents, that we try to maintain some minimum level of accessibility across the W3C site, and that multimedia content had no reason to be treated differently – and I was convinced.

Convinced, but still preoccupied to the potential barriers it creates; and if it creates barriers for us, in an organization of technophiles with a strong interest in creating accessible content, how great these barriers would be for most of the rest of the world, who primarily wants to share their content, without much direct interest in the technologies behind it?

I figured the best way to evaluate that was to go through the exercise myself; I should note that our policy should be accompanied with a budget so that we don’t have to do it ourselves, but it still seemed important to make my hand dirty in the transcription process to understand it better.

While we’re only required to provide a transcription, I was more interested in providing captions of the video of my ParisWeb presentation – given its duration of one hour, I was pretty sure I would get bored by the transcription process if I didn’t get the nice results of synchronized captions at the end.

So I started looking for tools to create these captions; the first one I found on my Gnome desktop was Subtitle Editor, which offers a pleasant user interface, showing the video with the subtitles as you write them, and shows also a waveform (i.e. a visual representation) of the audio track to help locate pauses in it.

But it appeared pretty quickly that the tool was more geared towards editing existing subtitles, than creating new ones from scratch: the user interactions to adjust the timing of the subtitles were really overly complex, and not adapted to the setting of what would appear to be 950 synchronization points!

Looking for another tool, I found Transcriber, available on Windows, Mac and Linux.

While the rather ugly Tcl/Tk interface of the tool and its lack of integration with the audio system in place on my Gnome desktop were a bit annoying, the tool itself and its well-defined keyboard shortcuts made it a much better tool for that captioning process:

• you load the audio file, from which a waveform is built and displayed in the lower part of the window;
• you can then use the tab key to start and pause the audio track, and jump back and forth in the audio track using the arrow keys;
• meanwhile, you can type the transcription and end each line of captions with the enter key

I’ve made a screencast (my latest whim on which I’ll come back later) showing that rough process of the transcription of the first few seconds of the video:

(also available as Ogg/Theora, with a Timed Text transcription)

Transcriber is already pretty good as is, but there are two improvements I could see to such a tool that would make it even better:

• provide auto-completion of words, both from existing dictionaries, and from the words already used in the transcription (probably with a priority to the latter);
• work directly with video, and show video with subtitles live, the same way subtitle editor does – this provides a nice instantaneous feedback that is quite useful in this rather laborious effort;

But even with a nice tool, transcription is a very tedious work; the purely transcription part (i.e. typing what you’re hearing) is probably the worse – the synchronizing part could almost made fun by turning it into a video game of some sort…

Clearly, having a speech recognition engine doing a first pass at the transcription would be incredibly useful; I didn’t find any ready to use (and open source) package to do for a French track, but in the process of looking for one, I stumbled on a few interesting projects:

• VoxForge which collects free voice samples to create voice profiles that can then be used by open source speech recognition projects; I contributed a couple of French samples, although the Java applet they’re using kept bugging, making the process much less easy than it should be;
• and related to it, LibriVox which is set to create a free and community-based library of audio books; quite appealing, although I found the process for getting started a bit too intimidating – I think an even more open system where anyone could contribute any reading from a very large list of possible texts would bring much more content (in a classical Cathedral and Bazaar fashion).

Back to transcription – I didn’t measure how long it took me to transcribe the one hour long track, but at least 3 or 4 times that duration; clearly this is an exercice I’d do myself again only for much shorter content; but then, people are much more likely to watch much shorter content as well, so that’s probably a reasonable assumption.

Beyond accessibility, I found the following interesting benefits in transcribing my own presentation

• first, I re-heard the entirety of it, and it made me look at what had changed since then, what still holds and what doesn’t any more;
• it gave me a chance to analyse my own public speaking; I don’t know if that’s really a benefit, because it really highlighted a bunch of annoying speech tics, some twisted sentences, etc. But even if it hurts my ego somewhat, I’m hoping it can help me reduce some of these bad habits…
• I got a chance to correct in the transcript some rather obvious mistakes I made while talking (using “computers” where I meant “phones” for instance); I’m sure there are conventions on how to express this – I used “[phones]“;
• generally speaking, having a text transcript of the video offers a bunch of creative usage of that new text for further manipulation; e.g. here is the Wordle of the transcript of the video:
  .

And more importantly, this was a trigger for me to look more into the video / text synchronization questions, which will be the topic of my next blog entry in this series.

I just got a brand new PDA-phone last Monday, a Tréo 650 running PalmOS.

I have been reluctant to cell phones for a long while, finding them rather invasive: when you own a cell phone, people expect to be able to reach you on it pretty much all the time and everywhere. At some point, the trade off between this cost and the advantage of being able to call some people all the time and everywhere tipped the balance, and I finally decided to get a cell phone for my personal usage.

With this new toy, not only am using now a cell phone for my professional usage (the primary reason behind it), I’m also jumping into the PDA adventure; again, I’ve never been really convinced by the need to get a PDA; I organize most of my work using my computer, and even though I move quite a bit for my work, the need to have access to all my data all the time has never appeared so urgent to me.

But even if the primary reason to couple my cell phone with a PDA was to get my hands on some real Mobile Web experiences [Note to self: this site looks horrible on my PDA], I’m hoping to also make this an opportunity to give a shot at using a PDA for real, with access to my calendar, my email messages and a Web browser. Maybe the few times I remember having thought “too bad I can’t look this up” combined with the geeky joy of using a new gadget will make me a real adept of the digital life on the move?

Debian and Bluetooth

The first step in that direction was to make the said PDA to work well in cooperation with my Dell laptop (Latitude D600) running Debian, and where I keep most of the data relevant to my PDA using Gnome and Evolution.

Some part of this process were fairly easy, but way too many were incredibly difficult compared to the task.

Setting up my laptop to talk to my PDA using bluetooth was really simple, mostly thanks to Bill Wohler’s complete description of the steps needed to get Debian to work with the Treo. I guess I hope at some point most of this configuration work could be automated using hardware detection (e.g. HAL), but the current cost of editing a few text files is more than acceptable to me.

Getting them to talk together means that:

• they can detect each other and authorize each other as Bluetooth devices
• I can use my laptop as a network gateway for my PDA, thus making it possible to test all the network operations without eating my GPRS paid time

Most of the actual work is done by Click 2 Call which offers a Web interface to your Vonage line. But getting integrated nicely in your browsing/desktop experience is fun.

So, how do you get a new URI scheme to be handled by Firefox or Gnome?

Well, first, getting a new URI scheme to be handled by Firefox is equivalent as getting it handled for Gnome, since for some reason, Firefox uses the generic gnome-open command to handled unknown URI schemes. I haven’t been able to find how or why, so I don’t know if that’s Debian specific or if this is true for any Firefox running on Linux et al.

Getting a new URI handler in Gnome is not necessarily well-documented, but once you know, it’s very easy; the set of three commands below is all that’s needed to get my local script vonage-call to be added as the handler for tel: URIs:

gconftool-2 -t string -s /desktop/gnome/url-handlers/tel/command "bin/vonage-call %s"
gconftool-2 -s /desktop/gnome/url-handlers/tel/needs_terminal false -t bool
gconftool-2 -t bool -s /desktop/gnome/url-handlers/tel/enabled true

The same kind of commands allows to add any kind of URI handler, like my MID dereferencer, my urn:isbn dereferencer or the x-edit bookmarklet hack.

So, what does this vonage-call script do? Well, most of the actual work is done by a simple curl call to the said Web interface; but I’ve added a bit of interfacing to be improve the look & feel of the operation, using zenity, Gnome’s equivalent of xdialog.

So, when you call vonage-call without argument, you’re asked for a phone number to call:

Once entered (or directly if you’ve followed a tel: link), you’re asked for confirmation :

And eventually, there is even a progress bar for the few seconds it takes to run the curl command:

To finalize the integration of this small script into the desktop, and following Sun’s documentation on Gnome integration, I’ve managed to add an entry in my Applications->Internet menu… with great pain, I must confess.

The key to be able to use a personalized menu per-User on gnome is to have the following file created .gnome2/vfolders/applications.vfolder-info

<VFolderInfo>
  <!-- path doesn't understand $HOME or ~/ ; maybe it would understand it as a relative path to $HOME? didn't test -->
  <WriteDir>/home/dom/.gnome2/vfolders/applications</WriteDir>
</VFolderInfo>

This basically instructs Gnome that it can write into the said directory — make sure to actually create it (mkdir -p .gnome2/vfolders/applications) — when you try to personalize the menu with Nautilus; otherwise, you get a permission denied error, since Nautilus would try to modify the content of the directory defined at a higher level in /etc/gnome-vfs-2.0/applications-all-users.vfolder-info; once this is done (and despite the complete lack of documentation of this), you can use Nautilus to add (and probably remove) launchers in your menu. This is with Gnome 2.8; I’ve read that Gnome 2.12 fixes some of the menu-editing difficultiess, so this may be easier if you’re running a bleeding edge version.

A launcher in Gnome (and KDE) is a simple .desktop file that lists a set of well-defined properties; here is what I’ve used for my little script vonage.desktop that I placed in the directory created above, .gnome2/vfolders/applications:

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=Vonage caller
Comment=Call phone numbers using Vonage
Exec=/home/dom/bin/vonage-call
Icon=stock_landline-phone.png
Terminal=false
Type=Application
Categories=Application;Internet;

This can actually be created with the graphical interface, I think: right-click on your desktop, create a new launcher bound to the right command and selecting the right icon; once done, open the “Applications” virtual folder in Nautilus (either from the virtual “Start here” folder, or using the applications-all-users:// URI (sigh!)), and copy your new launcher in it; the right thing should happen:

Well, that’s about it; there is still a bit too much of magic for my liking, but the fact that this is doable, and even fairly easy once you know the magic is already pretty sweet!

I toyed with the idea of using a solution based on VNC, which allows one to share a unique X Session on two or more computers, especially as Gnome includes a server (vino) easily configurable; but my tests with various clients (xtightvncserver, xvncserver, svncviewer) were quite inconclusive, the resulting experience being always very sluggish (limited by CPU, I think, which on a 1.60 GHz computer would be disappointing), and sometimes buggy (e.g. key press being repeated too many times). I probably should investigate further whether this is to be expected or due to some failure on my part…

Meanwhile, I decided to took the traditional X-over-the-network approach ; the default and well-deployed solution is to use XDMCP, which is really easy to set up when using Gnome login manager (gdm); the only problem is that XDMCP is really insecure (transmitting passwords on the clear), and although this would be mainly to run on my local wired network, I don’t want to rely on security through obscurity.

Unfortunately, it appears one cannot run XDMCP through ssh, since it relies on UDP traffic which apparently ssh can’t tunnel. So securing XDMCP is not directly easy.

I then found about sdm which basically does what I want: it acts as a graphical login manager, which instead of running a traditional X-session starts an ssh connection to your target host and launch your traditional X session manager there.

The only problem with that solution is that I don’t want to rely on another login manager but gdm, since it’s well integrated with Gnome; so instead, I quickly reimplemented the equivalent solution for GDM, which proved to be quite easy: I only had to add (in Debian) the two following files to get a new session type available from the GDM session menu under the name “SSH”.

The most important file is a simple shell script that will act as the X session manager: it asks graphically which host to connect to, asks the passphrase, connects through ssh and invokes the local x-session-manager. I placed it under /usr/local/bin/ssh-session:

#!/bin/bash

TARGETHOST=`zenity --title "Host to connect to" --entry --text "Enter the name of the host you want to log in to"`
#@@@ should probably get a user name too; I don't need it so didn't set it up that way
#@@@ should it do an ssh-add so the user doesn't have to enter its passphrase again?
SSH_ASKPASS=/etc/alternative/ssh-askpass /usr/bin/ssh -A -X -T -n "$TARGETHOST" /usr/bin/x-session-manager

(Ideally, the zenity call should include a list of servers, either taken from .ssh/known_hosts, or from a zeroconf lists of local servers that provide an ssh connection; too bad Zeroconf is still so little implemented on linux, but hopefully Avahi should fix that in the near future)

The other file is the one responsible to linking that session manager from GDM; it’s a simple .desktop file, which I placed at
/etc/dm/Sessions/ssh.desktop:

[Desktop Entry]
Encoding=UTF-8
Name=SSH
Comment=This session logs you into a remote host using ssh
Exec=/usr/local/bin/ssh-session
Type=Application

(Given that it relies on the existing Debian conventions, this should also work to start a remote KDE session through kdm.)

So now I can connect from my desktop directly into my laptop system, and the resulting experience is impressively good with a 100Mbs ethernet connection (on the 11 Mbs wireless connection, the result is much less pleasing) ; it doesn’t seem to take much CPU at all on the laptop either.

Update (17 Jan 2006): As part of the Bug 322155 and with lots of helpful comments from Brian Cameron, I have produced a patch to make such a session a built-in in GDM, patch that has been committed to the CVS server.

So, using a Gnome desktop, I installed a set of 4 clocks on my desktop set on the timezones of the people I work the most often with… Et voilà !

One of these terrible “un-break me” configuration options, where the user is left to wonder why this was broken in the first place…

The main piece that didn’t quite work as is, is the ACPI configuration; fortunately, other people than me have gone through this, and following these Dell D600 tips for Linux, I think I got the remaining bits working; a few notes to other Debian users with regard to the notes linked above:

1. as of today, Debian acpid won’t read configuration files with a . in them (see a related bug report), so rename the trap_all.conf and PBTN.conf files without their .conf extensions
2. the radeontool binary compiled in the process hardcodes the location of the lspci util at /sbin/lspci whereas Debian has it in /usr/bin/lspci; so either recompile it with the proper fix, or make a symbolic link from one to the other
3. the acpi_handler.pl file needs to be tweaked to be adapted to Debian, too; that’s mostly replacing /sbin/service by /etc/init.d/

As far as I can tell, now my laptop goes to suspend when the lid is closed and the AC power is off; and the screen goes blank when the lid is shut, whatever state the AC power is at.

See also my kernel configuration file, my XF86 configuration file (both shamelessly stolen from colleagues of mine), my modified version of acpi-handler.pl.

I hope that the weird disk noises that I heard this morning were just that, and not the sign of anything worse… Also, I still get to get the internal Wifi card to work, although the fact that my PCMCIA card works as is doesn’t really motivate me to make it work…

The basic idea is to get my browser to understand that application/*+xml is really just like application/xml, unless it knows better. To that end, I first wrote a small CGI script that more or less proxies resources served as application/*+xml into application/xml, by simply rewriting the Content-Type header. Note that it respects the charset parameter if it is set, and also forwards HTTP Authorization requests and responses between the client and the server.

Once this was available and working (as demonstrated by applying it to a W3C RDF file), I needed a way to tell my browser to use this service for the relevant MIME Types; in Gnome (and thus Galeon), this is done using the “File Types and Programs” tool in the advanced preferences menu; I added an RDF entry inside the “Information” category, with the MIME Type application/rdf+xml, and made it handled by a very simple shell script that I had created in my ~/bin directory:

#!/bin/bash
galeon --no-raise -x "http://www.w3.org/2004/07/viewAsXml?uri=$1"

This should have been enough, but the fact that by default, tools that are specified using this tool aren’t supposed to understand URLs, so that Galeon would first download the file in /tmp and then pass /tmp/filename.rdf to my little shell script, making it call the CGI script on a bogus URI…

After some investigation, I found out that adding the following lines in the relevant section of my ~/.gnome/application-info/user.applications configuration file (and despite the warning at the top not to edit it by hand) would finally make my browser do the right thing:

 viewAsXml
        ...
        mime_types=application/rdf+xml
        expects_uris=true
        supported_uri_schemes=http

Now I can view RDF files in my Web browser happily again!

Of course, the real solution would be to solve Mozilla’s bug itself; pending that, this solution could be improved:

• to work with any Mozilla derivative; I believe that with Mozilla (or Firefox) in Gnome, setting the preference to have it use the systems default should be enough; KDE has probably the same kind of capacity has Gnome in that regard, so this should be easy enough to adapt to that case; for Mozilla alone, I haven’t found a way to configure the mimeTypes.rdf file properly to make it pass the URL along
• to work with any application/*+xml MIME Type ; right now, it only works for the one you actually specify, but I’m doubtful that the underlying MIME Types system has any capacity to match such a pattern