Maintenance

Today I made a start on figuring out the best way to put linked SVG logos on web page. The test document was a new HCMC logo comprising the UVic shield and the HCMC name. This is what I had to do to the SVG image:

• Create a group for each part of the logo, to make it linkable.
• (In Inkscape) right-click on the group, and choose Create Link.
• Right-click again, and choose Link Properties.
• Fill in the @xlink:href, @xlink:title, and @target attributes. If you don't include @target="_top", then the link will replace the SVG image with the linked page. That's usually not what you want.
• Create white boxes (in this case, because the image BG is white) over the top of each group; link them in a similar way, and then send them to the bottom. If you don't do this, the link only work when the mouse is over the actual content of the element (the text, in this case); in between letters, there's no link.
• In the root SVG element, set @viewBox="0, 0, [width], [height]", where [width] and [height] are the original @width and @height attribute values from the same element.
• Add @preserveAspectRatio="xMinYMin meet" to the root <svg> element.
• Set the @width and @height attributes of the root <svg> element to the pixel values you want the image to show up with. These are naked integers (no 'px' or other units). (This is unfortunately necessary.)
• Clean any cruft you can out of the SVG file. I was able to remove some old @style attributes which had font info in them, even though the text had already been converted to paths.

That's it for the SVG. Now, to insert it into the page. In this case, I wanted it centred, which proved annoyingly tricky.

• Create a <div> element with width and height set to the desired pixel-width of the image (as already specified in the SVG file), in the @style attribute, and also include margin-left: auto and margin-right: auto.
• Create an <object> tag inside it, with the same width and height settings, with the @type attribute set to "image/svg+xml" and the @data attribute pointing at the SVG file.
• Include some appropriate fallback content in the <object> tag, in case the image can't be displayed.

The results (for the Map of London project footer) look like this:

  <div style="text-align: center; margin-left: auto; margin-right: auto; width: 237px; height: 40px;">
    <object type="image/svg+xml" data="images/hcmc_logo_linked.svg" style="width: 237px; height: 40px;">
    <a href="http://hcmc.uvic.ca/">
      <img src="images/hcmc_logo.gif" alt="Humanities Computing and Media Centre" width="163" height="39" /></a>      
      <a href="http://www.uvic.ca">
      <img src="images/uvic_logo.gif" alt="University of Victoria" width="104" height="40" /></a>
    </object>
  </div>

This is tested and working on Firefox, Safari, Opera, IE9 and Chrome. Chrome has a bug which changes the linked bit into a black square once it's "visited", but that's a known webkit bug which has just been fixed, so Chrome should inherit the fix soon.

For some reason I keep getting tree conflicts in the Moses SVN. This is the only way I've found to resolve them:

svn resolve --accept working -R .

You need to do this from one directory above the level of the actual conflict. I'm still trying to figure out why this keeps happening, but it may be something to do with the fact that the project was dormant for a good while, during which time the SVN remained unchanged, but my working copy was affected by a crash and restore of my home directories.

We have more info about build targets that have to be run prior to the main build to get the correct version information into the app, so I've updated and tested my build script for an eXist WAR.

We had a problem on beet where a local user had Gnome Keyring issues when trying to commit changes to svn. It *appears* that if the local user name and the remote user name are the same, but have different passwords, things can get a bit weird. We deleted the local user's keyring, but the problem re-occurred on reboot.
When the user logged in to beet with their netlink id the problem did not occur.

Note to self - do not provision local users that have the same name as the project itself.

I'm finding it useful to attack the TEI Guidelines with XQuery once in a while, to dig out and format stuff for review and discussion. However, you can't just load the P5 source into eXist, because you'll have problems with entities and have to mess with DTD catalogues. Instead, you can just expand the guidelines-en.xml file to pull in all the content referenced through entities, like this:

.../P5/Source$ xmllint --noent guidelines-en.xml --output guidelines-expanded-en.xml

That gives you a 6MB file you can upload into eXist and query easily.

We have many Cocoon + eXist projects currently running on Tomcat 6 on Pear. At some point, they'll migrate to Tomcat 7, so I've been using Tomcat 7 on my desktop to see what problems emerge. Here's one of them:

When I started Tomcat 7 with the Mariage project running in it, the site worked, except for the home page, which showed an error to the effect that "index.html" was not there. The site doesn't use index.html at all; its sitemap matcher for the home/root looks like this:

<map:match pattern="">

and all the site links point to the directory root. I eventually determined that this was caused by a change in the way Tomcat handles default "welcome files". If you look in Tomcat's conf/web.xml, you'll see this:

    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
        <welcome-file>index.htm</welcome-file>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>

Obviously, there's no handler for an empty directory root; Tomcat 7, when presented with a directory root, goes to this list to see what to pass to the webapp. This list is identical in Tomcat 6, so it's clearly a change in the logic of the handler rather than the default configuration.

First I tried adding an empty <welcome-file> element to the top of the list, but that didn't work, so I commented out all three of the <welcome-file> elements, and then normal service was resumed. Incidentally, you have to restart Tomcat between changes to web.xml to cause them to have an effect (according to the web).

If this is a new setup and you've never checked out eXist before, then:

• mkdir exist_trunk
• cd exist_trunk
• svn co http://exist.svn.sourceforge.net/svnroot/exist/trunk/eXist .

Otherwise just go into exist_trunk and do

• svn update

• cd eXist
• ./build.sh clean
• ./build.sh download-additional-jars
• cd extensions
• cp build.properties local.build.properties
• [Check local.build.properties to make sure FOP is turned on. It's turned on by default at the moment. **FYI: just checked out rev 15484 (Oct 29, 2011) and FOP is turned off in build.properties]
• cd ../
• ./build.sh

NOTE: if the build fails because of an error related to a Ant and Ivy, then download this file: http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.2.0/ivy-2.2.0.jar and put it in eXist/tools/ant/lib/

• ./build.sh -f build/scripts/jarsigner.xml
• ./build.sh dist-war

Next, if you're going to store your XQuery and the rest of your application logic in the database, don't forget to edit WEB-INF/controller-config.xml to make sure requests in the webapp root are handled by your controller file. For example, I added this:

<!-- MDH: Application site configuration. -->
  <root pattern="/*" path="xmldb:exist:///db/site"/>

to tell eXist that my controller.xql lives in /db/site, and should be handling every request to the webapp from the root down.

One other fix proved to be necessary: my application serves images out of an /images/ subcollection, but there's a line in the default controller-config.xml which blocks the handler in my controller.xql. I had to comment it out:

<!-- MDH: Commented this out. -->
  <!-- <forward pattern="/images" servlet="ScaleImageJAI"/> -->

To make sure Tomcat starts with UTF-8 instead of the default, I put a script in [tomcat]/bin called utf8startup.sh:

#!/bin/bash
./startup.sh dFile.encoding="UTF-8"

Running this instead of the standard startup.sh helps to avoid character encoding issues.

Learned something I didn't know today. When you run updates on an Ubuntu headless server, it doesn't tell you when a reboot is required; instead, it creates this file:

/var/run/restart-required

or:

/var/run/reboot-required

Check for the existence of that file. If it's there, do a reboot. It'll be removed during the reboot. I learned this when doing updates to teijenkins.

Heard from AR that he's now integrated support for the Lucene SnowballAnalyzer into eXist trunk, so I built a WAR from SVN to test this with. I've added lucene-snowball-2.9.2.jar (to match the Lucene version in trunk) to WEB-INF/lib, and I'm going to start investigating both this and the way controller.xql works, ahead of porting Map of London to the latest eXist.