HCMC Blogs

I've basically finished the layout of the GUI for the RomanLaw database; the objective has been to make it as flexible as possible in terms of resizing components, so the user can configure it to suit the nature of the records that are being edited. The results are quite pleasing, and are tested and working in Firefox, Opera, Safari and IE7.

Working on the RomanLaw interface, I found that both IE and Opera were throwing JavaScript errors which I had a really hard time pinning down. Eventually I discovered the problem was a trailing comma in JQuery option assignment expressions like this:

 $("#tabK_keywords_container").resizable({
     minHeight: 200,
     minWidth: 200,
 });

That trailing comma has to go. In view of some other reported bugs with IE with the current release of JQuery UI, I'm working with today's SVN version, which seems pretty solid so far.

To debug the problem, I had to download and install Microsoft Script Debugger from here: http://www.microsoft.com/downloads/details.aspx?familyid=2f465be0-94fd-4569-b3c4-dffdf19ccd99&displaylang=en. And in a fabulous piece of irony, if you go to that page in IE, with the Script Debugger installed and activated, the debugger will pop up, then freeze, and you'll have to kill it, and then the browser. Go Microsoft.

JT came by with an aging, much-edited document which used a range of Unicode and non-Unicode fonts to handle Old English and IPA characters. Worked through the document and got a usable PDF out the other end, although there are still some inconsistencies in margins. When we tried a test-print of the PDF, our printer had lost its marbles, so we had to give up. Finally figured out what was wrong with the printer: it thought the paper size for Tray 1 was JIS B5.

The Aðalsteinsdóttir, Engilbertsson and Gunnbjörnsdóttir article raised problems we had never faced before; it's been over a decade since the last time an article in this journal had multiple authors, and the XSLT processing wasn't set up to deal with it, so I've had to rewrite several bits. The best approach from the point of view of keeping the authors separate was to give each author his or her own <docAuthor> tag in the front matter; each of these is now processed separately, leading to each author's name appearing on a separate line in the PDF and XHTML article output, and also to the authors each getting a separate entry in the Contributors list. This works fine for articles in PDF and XHTML, and also in the print volume rendering.

I also had to rewrite the XQuery for the Authors page on the site; it wasn't handling the three authors correctly, returning the first one three times instead of three distinct entries. That page could still use another look, actually; it's returning multiple copies of the name where the person has multiple articles or reviews. The XSLT is filtering this out, so the output is fine, but it should still be checked.

This morning I followed the ELC instructor into the lab to make sure everything was working, and experienced the same problems as before: Starting the teacher program results in an RSRV error. This happens even after confirming that RSRV.exe and RSRVAny.exe are running. The only thing that fixes it is to turn the console off and back on again before starting the teacher program. This suggests it's something to do with the sequence of events; the sequence that works is to start RSRV, then power up the console, then start the teacher station.

The station is also lacking any obvious links to the teaching materials. I was able to navigate easily to them, but it would be hard for a teacher. In the past, we've put a link to the materials folder in the actual directory in which the teacher station always opens up its dialog box (which if I remember rightly is somewhere in its program folder). I'll do that if I get a chance today.

I frequently use rsync and robocopy to back up my data across multiple systems; it will typically go from my Windows PC at work to the backup (Linux) server, and thence through my Mac laptop at home to my Apple Time Capsule NAS. I've noticed that accented characters in filenames are causing problems for the second stage of this process; files are failing to back up because rsync cannot handle the accented characters in the file names. Since we currently have only two such files in the XML markup, I've decided to avoid the problem rather than solve it, by changing those filenames (and the associated xml:id attributes on their root elements) to ASCII representations. This has no consequences for anything except the file systems, but it keeps everything simple and it'll make backups more reliable.

Still flying solo...

Started in with JQuery and JQuery UI, which I'm gradually getting used to. I've created a tabbed interface with 4 tabs, each one of which will enable editing of one of the data tables. The main tab, for Inscriptions, will also build in the capability to add, delete or edit other items from the other tables on the fly, so the users will be able to work just in that tab if they want, but the others will probably be useful. So far I've got the tabs working, and built some resizable components, as well as some code for enabling and disabling forms easily.

Worked through JT's proofed copy of one of the vol 17 articles, making changes, until near the end, when it became clear we haven't really made our minds up finally whether we want headline case everywhere, or whether there are places that should have sentence case. Waiting for feedback from JT on that.