Mariage

Over the last couple of days, documents are reaching completion, and I've been revisiting the markup and rendering as I start looking at them on the site. After rewriting some of the XSLT and CSS, and normalizing some of the markup, I've sent this message to the team (reproduced here because it documents some policy changes):

I've started working on the rendering of the markup in the documents you've been working on, starting with Emily's text.

I came up against a number of issues which have led me to revise some of the markup Emily and I came up with on Tuesday, so I think we'll need to look again at Leanna's title page and frontispiece markup with these issues in mind. I've decided on a few policy changes:

@rend ATTRIBUTES ARE CSS:

When we're describing the rendering of textual elements, with the @rend attribute (<hi rend="xxx">), the value of the @rend attribute should always be CSS (Cascading Style Sheets) code. This is something that we're already doing in many cases, such as "text-indent: 3em" and "font-variant: small-caps", but in other cases we were using old TEI formulations. This means that you'll need to get familiar with some of the most common CSS code. Here are some simple examples:

• rend="font-size: 200%"
• rend="font-variant: small-caps;"
• rend="font-style: italic;"
• rend="font-weight: bold"
• rend="vertical-align: super;" (=superscript)
• rend="vertical-align: sub;" (=subscript)
• rend="text-indent: 3em;" (=first line indent in a para)
• rend="text-align: center;"

You can combine these together with semi-colons, like this:

<hi rend="font-style: italic; font-size: 200%;">

I think you'll get the idea fairly quickly, although this can get quite complicated -- for drop-capitals, I ended up with this:

rend="float: left; font-size: 200%; margin: 0; padding: 0; line-height: 90%;"

so feel free to ask me about this. There';s a good intro to CSS here.

It's widely used for styling Web pages, and in other contexts, so it's worth learning.

FIGURES:

Decorative figures, lines on the page, etc. (graphical elements in the text) are described like this:

<figure>
  <figDesc>Text describing the figure</figDesc>
</figure>

There's no need to use square brackets in the <figDesc>; I supply those during the rendering process. The descriptive text should be in French, of course.

PAGE NUMBERS:

Generally page numbering is straightforward:

<pb n="25" />

but we've come across cases where it's not -- where the page number is wrong, for instance, because of a typesetting error. Up to now, those instances have been handled like this:

<pb n="146" rend="164" />

meaning "page number 146; rendered wrongly as 164". However, there's a long sequence of page number errors in Leanna's text which are caused by numbers 18 and 19 being repeated; this means that most of the page numbers are "wrong" in the text. This causes me to wonder whether page numbers in our texts are best viewed as "labels" (i.e. they should be reproduced in the rendering exactly as they are, without our worrying about what they "should be"), or whether they're structural data, and we should number the pages as we think they should be numbered, and provide a note to the effect that the original text has an "erroneous" number. Claire, what do you think?

LINE BREAKS:

In the prose novels, lines are incredibly short, and we've been (correctly) inserting all the appropriate line breaks as <lb/> tags. However, for reading on screen, this is frankly weird (see Emily's text on the Web site), so I'm wondering if the display of the novels should ignore line breaks, giving us a more "normal" rendering like the other prose texts:

[Example]

What do you think? (We could also make this optional, allowing the reader to switch linebreaks on and off on the page.)

ANNOTATIONS ON THE DOCUMENT:

There are some instances of text written on the document by hand (such as the BL... number on the title page of Emily's text). I'm not sure yet how we should handle those, but if you've seen any in your own text, please let me know what they are, so I can get a better idea of how many and varied they are.

Worked with EM and LW on the encoding of the title pages and frontispieces of their documents. This seems to be complete now, so my next task is to enhance the XSLT to output it appropriately. Now EM and LW are proofing each other's work, while we wait for news of PG's job situation, and TG is still finishing her markup.

LCC started work today, so I spent some time getting her going with the Varin transcription (no XML yet). In anticipation of this, I reorganized the folder structure on the server so that all the documents which the team is actively editing are under one directory, and thus easy to back up (previously they were all over the place, some in personal directories). I also went through the three editing machines and removed or updated links and project files to point to the correct locations, so although the old files are still there, each person should now work on the new copies without necessarily being aware of it, and I'll be able to back up new work easily.

The changes to IMT file structure also broke the search functionality. I had to make changes to find.xq and search_results.xsl to accommodate the new @corresp and the hash in @facs and @corresp values. That also now seems to be working OK.

The transition from version 1.7 to 1.8 in the Image Markup Tool has introduced some new features and changes which needed to be migrated into the Mariage project files. This is the procedure I implemented to make the changes:

1. Data files (IMT XML files) were converted over to the 1.8 format. This was done with the IMT's built-in XSLT conversion file, but I modified it with some special overrides as below.
2. The result of this conversion would still have the wrong IMT version number in it, so that was updated by a modification to the XSLT conversion.
3. The conversion also results in a file which has inadequate distinction between transcriptional and non-transcriptional annotations. This problem arises in two locations in the file: first, in the <tagsDecl> area where the transcription categories are stored, the Transcription category had to be designated as "Transcriptional" by the addition of a <desc> tag inside the <rendition> tag. This was also easy to do through a modification to the XSLT.
4. The second problem component of the file is the linking, which by default ends up using @facs; all cases which are not transcriptional should be using @corresp instead. Another modification to the XSLT from IMT accomplished this conversion.
5. This gave me valid IMT 1.8 data files. The problem now was that the XSLT on the site was expecting the old format files, so I had to modify imt_p5_to_xhtml. Any code that makes use of the @facs attribute value had to be rewritten so that it could use both @corresp and @facs, and was sensitive to the new presence of the hash at the beginnings of those values.
6. Having converted all the data and the XSLT, I tested the XSLT by first uploading one new data file, and confirming that it failed to convert using the old XSLT; then uploading the new XSLT, and confirming that it worked with the new data file but failed with the old ones; and then by uploading all the new data files and checking a sample of them. Everything seems to work fine, including links into individual annotations.
7. Finally, I archived the old data files, and overwrote copies on the server in the mariage account with the new versions.

Everything seems to have gone smoothly. This is a tricky kind of task, especially on a live site, so it was good to do it when the office was empty and there were no distractions.

Fruitful project meeting to see where the transcription tasks have reached, and to plan our strategy for next semester. Decisions were mainly made for the two tag-teams, working on the Sonnet and the Amboise texts. The plan is basically that they'll finish up (any time soon), then they'll get together and examine each other's markup to look for inconsistencies, then we'll revise markup to incorporate all the best of both approaches. Then, the Sonnet team will begin tagging line equivalences, based on the 1609 text. The Amboise team will start adding <note> elements containing questions they'd like to see answered, along with possible suggested answers if they know them; these will form the basis of scholarly annotations. We need to categorize these notes by topic, using a type attribute. The other team will do the same, once they've tagged their line number equivalences.

Set up EM's workspace so she's editing directly on the server, and she worked through an example from a previous document to create a new header and frontispiece. Unfortunately, her many pages of previous transcription appear to have vanished; the file I backed up had no content in it other than the first line, and was timed at three hours before she finished on the 15th. It looks as though saving failed. However, she managed to get 18 pages transcribed again, and we now have solid backups of that data. I pushed it into the db to get some idea of how it would look; it's OK, but with such short lines, the left margin really ought to be moved over towards the centre a bit. I need to have a think about how pagebreaks are encoded, and what the default margins should be for prose text.

Spent some time getting the new RAs booked onto machines and working. EM is busy transcribing the second volume of the text that TG is working on; we haven't started on the XML with her text yet. AC is working on the Varin text; there we have a previous XML file started by CC, but not complete (it's missing authorial annotations, which are actually more extensive than the poetry), but the latest transcription doc file seems to be complete, so AC is moving blocks of transcription from the doc file into the XML file, and marking them up.

Things not yet done:

• Both of them are still working on local copies of files, until their accounts are added to the Mariage group. Have to remember to back up their stuff, and when the permissions are done, get their oXygen project files pointing at the files on the server.
• EM still needs to be started off with XML; that should be done next Wednesday, when she overlaps with TG, so that they can both learn together.
• AC and I need to meet with CC to figure out detailed plans for the Varin markup. For instance: all the poetry appears to be in italics except for some instances of plain, so we need an efficient approach to the markup to handle this, without using <hi rend="italic"> in every line. One approach is to use <lg rend="italic"> and then <hi rend="plain"> where non-italic bits appear.

Got TG set up on Arugula, initially transcribing the first half of one of EC's roman texts. Then CC brought down two more RAs who will start work next week, and we organized them. A will work on the Varin, and E on the second half of the roman.

The two latest images from the BN have been languishing ignored for a month, but I've now got around to dealing with them. I processed the image files to clean them up and create the three formats, then created new IMT files for them. To do this, I had to install the old 1.7 version of IMT on my machine, and avoid the current 1.8 development version. Then I did the actual transcription of the text, for a couple of reasons: to get something into the system so they can be added to the site, and to give myself more IMT experience ahead of finishing the new version off. Then I put the results into the db and checked them on the site. Waiting for any corrections to the transcriptions from CC.