Mariage

In order to run some of the text-analysis operations we've been planning on the database, we need to be able to grab text-only output from the documents, and be able to specify various types of filter on that output. I've been working on that today. These are the main points so far:

• I've written an XQuery file called text.xq which does the extraction, based on input parameters (see below), and returns plain text. The file has this custom eXist option declared in it:

  declare option exist:serialize "method=text media-type=text/text encoding=utf-8";

  That means I can avoid any transformations at all, which is handy.
• I've set up a page here which presents a simple form from which you can choose the options you want.
• These are the parameters:
  • startYear
  • endYear
  • textProse
  • textVerse
  • imageProse
  • imageVerse
  The first two are date filters, but the other four are booleans which decide whether prose or verse from either of the two types of document is included. Other filters behind the scenes ensure that only transcriptional text is returned; editorial notes, metadata, regularizations, etc. are all excluded.

As usual, XQuery hacking took a long time, but it appears to be working well now, and it's faster than I expected. The user will now be able to get the text in the browser, and feed it as-is into an application, or supply the URL of the filtered text query to an online service such as the TAPoR Tools.

The project is now using an IMT 1.7 schema, so I've updated all files on the server to the new format, and updated the Image Markup Tool on the workstations so that everything is at 1.7. H and F shouldn't notice any difference, but it will be worth checking it all works OK when they come in to work tomorrow.

Le mariage sous L'Ancien Régime has been updated, with new styles (two so far, but more coming soon), and substantial reorganization. The XML file format has been updated to a pure TEI P5, using the new TEI Facsimile module instead of SVG. There are now 58 marked up engravings on the site, as well as various prose and verse texts.

Switched over like this:

• Took the CSS for the blue style which Greg has completed from his directory, and put it in the site CSS directory.
• Edited the Styles menu so that only the original and the new blue style are available (until Greg finishes the others).
• Re-converted all the XML files to IMT 1.7 format, and uploaded them into the database.
• Tweaked the AJAX JavaScript to make the progress messages French (these will need checking).
• Moved the new site into new_webapps in the mariage account.
• Changed the old site to old_webapps and the new to webapps.
• Tested -- all seems to be OK.

Spent many hours hacking away at little annoyances in the image markup display. The main problem is the need to support some very specific behaviours in the display of popup annotations, in an effort to make everything as intuitive as possible. The requirements are:

• By default, annotations pop up below the area to which they apply.
• If that puts them off the bottom of the screen, they pop up above the area instead.
• In this default display, they're position: absolute so that they scroll with the image.
• Annotations should be draggable, so the user can place them elsewhere on the page to get them out of the way.
• Once an annotation has been dragged, all other annotations pop up in the same location, so the user can set up the page with a fixed location for annotations.
• Once an annotation has been dragged, it (and all subsequent annotation displays in the same place) should be position: fixed, because we can assume that the user wants the annotations to remain in the same area irrespective of any scrolling of the image.
• When a dragged/fixed annotation is closed (by clicking on the X in its title bar), we assume the user wants to go back to the default behaviour and have new annotations pop up next to their annotation areas, with position: absolute.

Annoying variables are:

• The image itself, which is the ground on which this whole castle is built, is an unpredictable size, and positioned an unpredictable offset away from the top left of the page.
• Different browsers have different ways of calculating viewport size and element and scroll offsets.
• IE7 has a freaky little bug which causes the image to jitter if it's left in the normal document flow, so we have to make it position: absolute.
• IE7 is still problematic with positioning etc., but there's a limit to what can be achieved with such a poor browser.
• IE6 is hopeless, so I'm ignoring it. We should pop up a warning, or something.

Began revising our DH2008 abstract, and in the process of taking new screenshots I found a couple of things that needed fixing on the new version of the site:

• FIXED: Note links (notes containing links to other documents) were not being processed at all in the image markup.
• FIXED: The acknowledgement of the BN as the source of the image was not appearing on the image markup rendering.
• FIXED: padding values in the search hit rendering were wrong (too large on the left, zero on the right).
• NOT YET FIXED: Search hits which link to prose texts are not links, so you can't click on the word you searched for and go to a rendering of the text with that word highlighted. This doesn't happen in the old version either, but it should.

Re-ordering the sequence of elements in the page to place the navigation menu before the content has solved the z-index issue in IE, without breaking anything in the other browsers.

Finally managed to figure out a fix for IE7. It seems that when the position property has its value changed (going from absolute to fixed, etc.), IE does something odd: instead of recalculating the min-width and max-width properties (which were set in percentages in the stylesheet), it just sets them to zero, or to undefined, which is then interpreted as zero. Trapping for IE and explicitly resetting its value for max-width seems to do the trick: the annotation popups now no longer lose all width and background.

So the site is usable again with IE7. Testing on IE6 shows that it half-works there as well, although the annotation menu and popups tend to be too narrow.

Phew.

Removed from the list today:

• [UNFIXABLE: It looks as though Opera just doesn't support :target properly.] (Opera): Note display in text documents is the old-fashioned jump to the bottom of the page. Presumably the :target pseudo-class is not supported. Check this.
• FIXED: (IE, Opera): Site title renders badly. This was just caused by some bad font settings in the CSS.
• [FIXED: Opera has a rendering bug here, but setting the visibility propery as well as the display property seems to work around it. (Opera): In Complet, clicking on an IMT document shows the teaser, but then trying a text document will not switch the teaser over; it looks as though the image teaser appears on top of the other one, and hides it. What actually happens is that the previous teaser is overpainted properly.
• FIXED: [Content]: The Équipe page is out of date. Update the list to include H, and remove Eric because the schemas he researched are no longer used.
• [FIXED, or at least worked around: setting the main image to position: absolute seems to stop it from jumping around.] (IE): When areas are selected on the image, the act of selecting the corresponding item in the annotation menu causes the image to jump around, presumably because some layout thing is being recalculated. This might be impossible to fix, but we should have a go at it.

The last recalcitrant lot of annoyances:

• When jumping to an image segment/annotation, the correct one is selected, scrollIntoView() works vertically, but not horizontally, so an image segment off to the right is unseen; also, the segment pops up behind the annotation menu sometimes, which is disconcerting. Should the menu move when it's covering an annotation area? Is it possible to predict all of this adequately? Should we just let users work around this stuff?
• (IE): Hoverbox images are lower in the z-order than the other components of the page. Can this be fixed, or is it just an IE bug? It's just cosmetic.
• (IE): Z-order is REALLY screwed on IE; despite explicit settings in the stylesheet, the annotation menu goes behind the site menu. Perhaps we need to set a lower value on the site menu explicitly.

The last two issues here are really annoying IE problems that really don't seem to be fixable. The heart of the problem is that IE seems to be incapable of combining elements in the normal page flow (such as the menu and the header), which may have variable font sizes and take up unpredictable amounts of space, with elements which are to the left of them and below them, which have absolute or fixed position. So we can't have a reliable functioning site layout combined with an interactive image and draggable popups. It completely loses its marbles, and starts rendering elements with no background image, and no apparent width value.

I don't know how much time it's worth spending on this. My feeling at this point is that we should just warn IE users to get a proper browser. I've created a browser information page that needs to be translated, and we could use JavaScript to show a link to that page in every other page whenever the user has IE.