Mariage

TG has got through the full text of the first volume of Amboise, and is now working on the forme works etc., so I added it into the database to see what it would look like. As a result, I made a few changes to the text itself (mainly rearranging bits of the front matter, which is longer and more complex than the front matter in volume 2), and also revised some of the rendering code to get more consistent results.

I think we might now consider the possibility of placing images of the figures on the site, and weaving them into the text, instead of just rendering the descriptions we currently have. We could capture the figures from the original PDFs, on a white background.

The novel text we have so far (Amboise) has very short lines on very small pages. We are accurately reproducing that layout of the document, but it's not ideal for screen reading, so I wanted to provide another option for readers who want to see a continuous text.

I've implemented a parameter switch called proseView, which changes some of the XSLT processing to remove forme works, page breaks, page numbers, and linebreaks inside paragraphs. I've also added a switching mechanism, in the form of a pair of links, at the top of the page. This code is only invoked if the <classCode> contains "prose" or "roman"; it's ignored for verse. That might change in future -- although verse does need its linebreaks, it might be beneficial to be able to turn off the page breaks. The switch has text in English right now; I'm waiting for the appropriate French labels.

EM has started work on adding reference material for all the classical allusions etc. in the Sonnet (1621 version). I've created a file called references.xml, which EM is editing; it has a separate <div> for each "topic", with a unique @xml:id attribute. References in the text are linked like this:

<ref type="reference" target="references.xml#topicId">blah</ref>

Once we have a fully marked-up document, I'll be able to write the handling code (intercepting handling of existing <ref> elements, which have no @type attribute, and which handle cross-references in editorial notes.

Our RAs are beginning to mark up forme works (running titles, page and folio numbers, etc.), so I'm adding in some handling for those on the site. I've taken the opportunity to do some more thinking with regard to the integration of CSS. These are some points, exemplified in the Amboise 2 text:

• <fw> tags for page numbers had best precede those for running titles, even if they appear on the right of them, because they're essentially floated, while the running titles are centred. This is an easy convention to work with, and makes rendering much easier too.
• The dimensions of the actual pages, rendered in ems, are now stored in a <rendition> element in the header:

  <tagsDecl>
    <rendition xml:id="layoutDesc" scheme="css">width: 15em; padding-left: 3em; padding-right: 3em;</rendition>
    <rendition xml:id="pageBreakMargins" scheme="css">margin-left: -3em; margin-right: -3em;</rendition>
  </tagsDecl>
  

• These are linked in a general-purpose way like this:

  <text rendition="#layoutDesc">...</text>
  

  and in a specific way for the page-break elements (this is rather a kludge, but it allows us to put page-break lines which are the right width):

      <xsl:template match="pb">
          <xsl:element name="div">
              <xsl:attribute name="class">pageBreak</xsl:attribute>
            <xsl:if test="//rendition[@xml:id='pageBreakMargins']">
              <xsl:attribute name="style"><xsl:value-of select="//rendition[@xml:id='pageBreakMargins']" /></xsl:attribute>
            </xsl:if>
               <xsl:value-of select="@n" /> 
          </xsl:element>
      </xsl:template>
  

  There may be a much more generic way of doing this, but I haven't thought of it yet. I could have a convention that links a specific <rendition> element through its xml:id to all instances of a particular tag.
• <fw> tags are styled and positioned with @rend. We'll probably dispense with @place.

This is still very much a work in progress, but we're getting there. Another couple of days should result in some clear guidelines and usable output formats.

Three of our RAs were working today, and we worked out a lot of issues that relate to forme work. Page numbers will be marked up using <fw> tags, along with running headers, and printer's marks such as signatures at the bottom of the page. Arguments -- topic labels in the margin -- will be done with <argument>, at the beginning of the line group to which they apply, and positioned with CSS relative to that location.

After some discussion with PG and with the TEI list, it seems that we should be doing this:

• Marking page breaks using a plain <pb> tag.
• Marking up the folio numbers (they're not page numbers if they cover a folio) using <fw type="folioNum">29</fw>.
• Since we'll now be marking up "forme works", we should probably also be marking up the running titles using teh same tag. That can be largely automated.
• Handling the printers' marks at the bottom left of folios in the same way.

Following a discussion on the TEI list, I've added a couple of pipelines to extract all the @rend attributes (which are now pure CSS, at least within the <text> element) and format them as a CSS stylesheet which can be passed to the Jigsaw validator, for checking.

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.