The second manuscript from the backlog is from a new archive, the Beinecke Library at Yale, one of the largest collections of medieval manuscripts in the US. MS 663 is an early 16th Century Book from Tournai, now in Belgium. The calendar is almost entirely undecorated, only gold and colored KLs to start the month, but the overall manuscript has a large number of complex miniatures.

An interesting bit of scribal practice is revealed errors in the calendar. January begins on f.4v, so that each month is a complete opening, however the second half of January, properly f.5r, is on f.4r. This points to scribal error, possibly the scribe noticed that he had mis-copied Anthony (1272) as a Monk on January 17th, where he should be properly a Confessor, Abbot or Hermit. Since the recto was not needed before the start of January, he was able to save the parchment without the need to scrape it. Why the second half of the month would have been done before the start is unclear, but since the red ink is missing from f.4r, this seems more likely than that he put the first part of January on the back of the wrong leaf.

The calendar entries are extremely accurate, with only three noted errors, all of which are at the start of the month. Due to an error in the layout of the page, the short verses for June take up the space of the first of the month(see f.9v below). The entries for June 1 (Nicomedes) and 2 (Peter and Marcellini) were shifted to June 2 and 3, to compensate. More interesting is Brigid, usually February 1, appearing on January 31. Shifts across month divisions are extremely rare.

Finally there is a bit of a mystery in the calendar, October 9 has Bishop Dyonisus, the most common name for the date, in black ink, followed by a word I read as “mesda”, in red. I’ve been unable to find a useful meaning for this word.

(DB Id: 270)

The another manuscript from the Bibliothèque de Genève, hosted by the excellent e-Codices site, was made for use in Nantes, MS Lat 33. It is lavishly decorated throughout, with block-borders on almost every text page and filled pages to start the hours and each month in the calendar.

The calendar is unusual in that it is unranked. There is a strick alternation of blue/gold for the entries, with no distinction for high-importance feasts. Also somewhat unusual is the line-fillers for every day. The saints are rather error-prone, with at least 43 noted on the wrong date. Several more names have become quite corrupt, for example St. Ballece, December 3 (see f.12r below), is most likely meant to be St. Barbara, December 4 853

(DB Id: 241)

A code update was pushed along with the addition of this MS to properly store manuscripts with unranked saints. This is unusual, so far there are only 3 manuscripts in which the color change does not seem to impart any sort of ranking information. One further manuscript, the oldest in the DB (DB Id: 68), only has black text in the calendar.

This is only the start of the JSON classes, but there is now a helper class to format data for the Google Chart API.  The basic operations are:

• add_column - add a header for a single column
• add_row - add a row of data
• get_json - emit the data as a json string, properly formatted to be directly injested by the google.Visualization.DataTable constructor.

The stats.pl cgi has already been updated to take advantage of this new library, which trimmed about 15% of the code out

Harvard's Houghton Library MS Lat 133 is a somewhat unremarkable Book of Hours, but the calendar is unusually messy.  There are rather few entries, only 171 saints, and those that are there are error prone and poorly scribed.  The red saints were written at a different time from the black, and some were neglected, at minimum St Laurence was forgotten, though the octave(Aug 17) was properly added.  The end of July has many of the possible errors: seven saints have been shifted up one day and the feast of Mary Magdalene is 3 days off (see f.7v below).  Interestingly there are no vigils in the entire calendar.

From the beginning there has been a color table in the db which links to color and secondary color names in the calendar_entries table, and provides the color names to be used in the HTML code.  There has always been the relevant css data, both the generic color "code" (i.e. #444444 for medium gray) as well as any custom html, such as this, needed for the red-strikethrough sometimes used to indicate medium importance

.black-redline{
	color: #000000;
	text-decoration: line-through;
	-moz-text-decoration-color: red; /* Code for Firefox */
	text-decoration-color: red;
}

Although this css code has always been stored in the database, until some work this week the actual css had always been maintained by hand.  When a new color was added to the DB, it was manually added to the .css at the same time.  This has finally been rectified, a generate_css.pl script and matching colors.tt template have been added and will properly generate the .css at any time to match the DB.  Eventually this may be called dynamically from the html code, but for now, manual intervention is needed to regenerate the colors, but at least it's just running a script

Finally completed a bunch of prep work to get the secondary saints working.  The saint and color tables are now joined to the main calendar_entry table in 2 places, one for each saint.  ALL of the saints, well mostly all, there are probably some straglers, have been properly coded so they can be broken between primary and secondary.  So everything is in place to do color and link work for them, it's just not been done

• Most of the code changes have been to properly get filters working in the manuscript view.  They now look right and have close boxes that pull them out of the filter chain when wanted.  The UI part of that is complete in the compare view as well, but backend changes are still needed to have the search properly update on deleting a restriction
• A logo has finally been added to the top bar!
• updates in the template code and the jQuery code to make the restriction links much easier to maintain.  The links are now generated on-load by the jquery, rather than being hard-coded in the templates

Today's addition is a fast DateConverter.  the Date class can be used for conversion, usually by creating an object and then getting values, eg.

my $date = BOHdb::Date->new({ 'name' => 'id', 'values' => 283});
my $month = $date->get_month_num();
my $day =  $date->get_standard_day();

However if that's the only reason to create the Date object, it's sorta inefficient to hit the DB in order to convert a date. For simple conversion between day_id (1-365) and month/day numbers the DateConverter class is MUCH faster.  It's had the three relevant columns of the DB turned into big perl arrays and coded into the class directly, so a conversion is simply an array lookup.  There are also the 2 functions in there to generate the static arrays, in case the backed data ever changes, the class is easy to update.  The user only uses the 2 get functions, get_date_by_id and get_date_by_month_day. Both return a little hash with all the relevant data

{
   'month' => 'October',
   'day' => '10',
   'id' => '283',
   'month_num' => '10'
},

A quick timing test:

ok 1 - get_date_by_id returns a hashref in 0.000009 seconds
...
ok 5 - BOHdb::Date created in 0.027421 seconds

The first of the clever functions has been implemented in a basic way, saints are cross-referenced.  In a calendar listing, any saint with a proper identity is slightly bolder-face and a hyperlink.  Clicking will bring up a dialog with the cannonical name, date and links to see all MS either containing the saint, or missing the saint, see screenshot below. 

At the moment this only works for the primary saint, not the secondary one.  Breaking the link into 2 parts is a harder problem and will be tackled later-on.  The lookup works for both however.