Mariage

CC and I have come up with this plan for providing document introductions on the site:

• CC will begin adding a new element to the <sourceDesc> in text documents. It will look like this: <bibl type="introduction"> [Detailed intro to the text...] </bibl>
• If that element is present, its contents will be displayed at the head of the document in the black box that's already there. If that element is not present (because it hasn't been added yet), the black box will display any other bibl tag inside sourceDesc (meaning that it will display the same text as is shown as a teaser when you mouse over the title of the document in the TOC page).
• I will implement a method for displaying all the metadata in the teiHeader, based on the way this was done in the ACH code, and as is also done for ScanCan. It will be handy to have that code available for P5 projects anyway. This can appear as a button at the top left of the page.
• The same approach cannot easily be taken with the images, because of screen space issues. We have discussed the possibility of using a special annotation called "Introduction", but I think it might be better to have a link at the top of the page, next to the metadata link, which will pop up the introduction over the top of the image. This has the advantage that all introductory material is encoded in the same way.

For text documents, I'm now displaying the content of the bibl tags in the sourceDesc part of the header. These are the "teasers" currently displayed when you mouseover an item in the TOC. They're currently too short to be useful, in most cases, so we have to decide whether to:

• just expand the ones we have, and see them also expand in the TOC; or
• create a new type of teaser which is longer and intended for the head of the document, and differentiate it from the teaser;

We also have to decide whether or not we want to do something similar with the images. That's problematic because space is at a premium where the images are concerned, so we might not want to insert a static block into the page.

Finally, we should decide whether we want to give access to the entire <teiHeader> information, and if so, how. We could add a "Details..." button to the little info box that would expand it and show all that information.

Both new RAs are now working on server copies of their files rather than local copies, after sysadmin added their netlinks to the mariage group. It took a while to get them set up to be able to access their files on the server, because on both machines, oXygen was running on the OpenJDK, which seems to provide rather impoverished dialog boxes to oXygen; browsing to a network share was impossible. Eventually by a combination of luck and determination, I got xpr files into the folders on the server, and managed to put links on the desktops to those files.

Both contracts and timesheets have now been submitted. I walked them over this afternoon, and was assured that GB's contract will be processed today so that her timesheet gets done in this cycle.

Our two new RAs met with us all today, and we've organized schedules for them.

Today I got the chance to do something I've been meaning to finish for a while. We had a lot of old-style linking code still remaining in the gravure and text markup -- mainly the former -- and it was no longer working, nor is it as effective as a tool for linking as the newer system is. I've now gone through all the image markup files and fixed all existing links -- 15 files were affected -- as well as the text documents, which also had a handful of the old link styles. For linking between documents, we're now using the much better system that looks like this:

<ref xml:id="wifes_lover" target="../../anthology/images/il_cherche.xml#wifes_lover">Il cherche ce qu'il ne voudroit pas trouver</ref>

In other words, each <ref> tag has an @xml:id (so you can link into it from another document or from the same document), a @target (it's best to keep targets singular for the moment), and some text that forms the link. This enables us to write normal expressive prose in notes with links in them, and link the appropriate text to the right target location. The old system was not so simple or flexible.

I haven't done anything with the modernized versions of the texts, because they have already diverged from their originals in both markup and content. We need to devise a proper strategy for embedding modernizations into the original files, I think.

Met with CC to plan the outline of our expenditure for the grant period. The grant is pretty slim, so the process was quite simple. Now we need to figure out exactly which texts to work on, and what order to do them in.

The original texts often use italics to signify quotes, rather than guillemets, so I've added the option to use this, so that you get italics but not guillemets:

<cit><quote type="italics">...</quote></cit> 

This will be tested over the next couple of days -- I'm using an <i> tag, but I suspect I should be using <emph>.

Just logging time spent over the past week or so debugging little markup issues, answering the odd question, emails, updating the db, backing up, etc. The general churn of the ongoing project.

<cit type="block"> is used for a blockquote, and normally translates into an XHTML <blockquote> tag in the output, quite reasonably. However, that gets it a default margin, which occasionally is not what is required, especially in the source texts, so I've now added a handler enabling the @rend attribute to be used to override it with (e.g.) margin: 0 on <cit>.

Fixed a couple of issues in the Nuptial mentioned by LSPW in the previous post -- it turns out that the layoutDesc had specified a default setting for text-indent in paragraphs, and although it was correctly being overridden, it turns out that the layoutDesc setting was being inserted into a @style attribute rather than being a class, which and it was being added AFTER the local style information. It strikes me that the layoutDesc data should actually be done with a CSS class, in an inline stylesheet, so that it would always be overridden by the local CSS; I'll have to do that, but for the moment I've just reversed the insertion sequence so that the local style comes later, and therefore overrides the preceding one from layoutDesc.

The bug with the Daumas reference was a problematic one, and puzzling too. The issue was this:

I never anticipated that the footnotes in documents would be calling out to references which are in the central bibliography; the biblio was originally set up for the editorial articles. However, a <note> element in the Sonnet now refers to an item in the biblio. The XQuery is correctly retrieving the biblio item and adding it in a one-item bibliography in a div in the back element (all correct, and what we want); but the XSLT was failing to convert this to output. It was just coming out as plain text, when it should have come out as a bibliographic list containing a single item with an appropriate @xml:id and styling.

I've taken the code which was handling bibliographical items in the editorial articles (in article_p5_to_xhtml.xsl) and adapted it for use in text_p5_to_xhtml.xsl. It took a while to get this working, but now it does -- I was fooled by the @mode="textDoc" setting, which had to be added to the initial template to start the processing of back/div[@type="bibliography" or @type='biblioCentral']. Seems to be working OK now.