HCMC Blogs

Just a quick update to say that Theo is processing images for the CO 60/6 collection, of which there are 117 files in 1859. I will now move on to process the images for CO 60/5, of which there are 98 file in 1859.

Finished the addition of PB tags to the 1859 files found in CO 305/13 and CO 410/1. The latter, letterbook copies, pointed occasionally to enclosures that exist in the originals. Presumably, once and if we track down the originals, we will have to add these items.

[EDIT BY MDH: I've looked at these and can't find anything wrong in any of the programming code (XSLT, CSS or XHTML output); furthermore, the extra line breaks don't occur in Opera or Google Chrome, so I conclude this is caused by a Firefox bug, and I'm marking the task as Completed.]

Just a reminder to MH to fix the following lines contained in argument tags that include an extra line break when viewed online: Lines 10327, 10358, 10396 and 10534. Thank you!

[This is in the FOREST NUPTIALE.]

1) Lines 10328-10338 (extra line break occurs between "phes" and "In-" in XSLT):

<div>
<argument rend="float: left; margin-left: -6em; text-align: left;">
<ab rend="font-style: italic; font-size: 70%; text-align: left;">
Philoſo-<lb/>
phes <ref target="../../back_matter/references/references.xml#indien">In-<lb/>
diens</ref>.<lb/>
</ab>
</argument>
<p rend="margin-top: 0; margin-bottom: 0; text-indent: 0;">
ſans la liſte des Philoſophes <ref target="../../back_matter/references/references.xml#indien">In-<lb/>
diens</ref> en font pluſieurs cantons de<lb/>

2) Lines 10359-10368 (extra line break also occurs between "phes" and "In-" in XSLT):

<div>
<argument rend="float: right; margin-right: 5em; text-align: left;">
<ab rend="font-style: italic; font-size: 70%; text-align: left;">
Philoſo-<lb/>
phes <ref target="../../back_matter/references/references.xml#indien">In-<lb/>
diens</ref>.<lb/>
</ab>
</argument>
<p rend="margin-top: 0; margin-bottom: 0; text-indent: 0;">
deſquels ſont rentés, és autres, il faut<lb/>

3) Lines 10394-10406 (extra line break occurs between "des" and "Bra-" in XSLT):

<div>
<argument rend="float: left; margin-left: -5em; text-align: left;">
<ab rend="font-style: italic; font-size: 70%; text-align: left;">
Solenni<lb/>
tez au<lb/>
iour des<lb/>
nopces<lb/>
des <ref target="../../back_matter/references/references.xml#bracmane">Bra-<lb/>
mins</ref>.<lb/>
</ab>
</argument>
<p rend="margin-top: 0; margin-bottom: 0; text-indent: 0;">
ieunes,hommes & femmes: le iour<lb/>

4) Lines 10535-10544 (extra line break also occurs between "des" and "Bra-" in XSLT):

<div>
<argument rend="float: right; margin-right: 5em; text-align: left;">
<ab rend="font-style: italic; font-size: 70%; text-align: left;">
Femmes<lb/>
des <ref target="../../back_matter/references/references.xml#bracmane">Bra-<lb/>
mins</ref>.<lb/>
</ab>
</argument>
<p rend="margin-top: 0; margin-bottom: 0; text-indent: 0;">
quels couchent auec les ſœurs du<lb/>

I was happily sharing my Lightning (Thunderbird plugin) calendar by copying the calendar-data/local.sqlite file between home and work computers, but an update to Lightning made that suddenly impossible; even with the correct sqlite db in place, Lightning would show a completely empty calendar. Eventually I figured out what to do:

• Shut down the Thunderbird which has the problem.
• Install sqlite and sqlitebrowser (from the repos).
• Open the db file, and find the cal_id field value in one of the tables (such as cal_alarms). Copy it somewhere.
• Open prefs.js, and search for any entries with "calendar" in them. There should be a block of them, and they'll all look like this:

  user_pref("calendar.list.sortOrder", "5d27f585-81fb-4f2c-8686-cf28b7ee5a0a");

• Replace the id value (the long GUID) with the cal_id from the Sqlite db. Save, then start Thunderbird.

Last day, many backups...

Family trip to the UK, leaving Jan 6 returning Jan 16.

25 days added for 2011 vacation. These are actually earned during the year.

The Cocoon/eXist build that's housing the current ColDesp application is pretty long in the tooth, and we're going to need some newer features in the coming months (see the previous post). So I've been preparing the way for migration by testing the current application as it runs inside our latest build. This is what I had to do:

• Made a backup of the whole db from my local Coldesp app.
• Copied a fresh Cocoon/eXist into my local Tomcat's webapps directory as "coldesp2".
• Copied the "site" directory from the old version.
• Restored the content to the db (there were a couple of error messages during this, but as far as I can see, nothing is missing).
• Started up the app, and discovered that there were sitemap errors, so started commenting things out. To get it working, I had to comment out this from the top of the file:

  <map:generators default="file">
              <map:generator logger="sitemap.generator.text" name="text" src="org.apache.cocoon.generation.TextGenerator"/>
          </map:generators>
  

  and all instances of this:

  <map:transform type="session"/>

  I don't think the former was actually used (no sign so far), and the only possible function of the latter was to handle the authentication for blocking access to non-UVic users; that will need some careful testing.

These are my conclusions so far:

Working:

• Regular site pages (home, About etc.)
• Browse the collection
• View a document
• View annotation content (people, places, etc.)
• Search
• Map gallery and maps
• Indexes
• Schedules

Failing or suspect:

• Scan images (clicking on a collection results in a long wait caused by an out-of-memory error). I suspect this might be cause by an indexing problem, resulting from one of the collection.xconf files not being quite right for the new eXist. I saw an error about a collection.xconf file go by during the restore. I've tried editing the collection.xconf file quickly to add a tei namespace prefix and reindexed the collection, but that didn't help. I should probably look at that pipeline and see exactly what's happening. There's no reason it should eat up much memory. On the other hand, when I hit the same page in my old Coldesp app (local Tomcat) I get the same error, so it looks as though this is simply an optimization issue that can be solved first for the old version and the same fix might work for the new.
• Clicking on a snippet to go to its document resulted in an error once (something in my xqSearchUtils.jar library). This might be a fluke, or might be something more significant.

This is not exhaustive, but it's quite heartening; it suggests that reworking the collection.xconf files (and perhaps adding some for the actual documents) could be all we need to do to get a basic working web application. I can then test it side-by-side with the old one, to determine relative speed and see if there are any slowdowns that need to be worked on in the new version. Assuming it performs at least as well as the old one, there's no reason not to migrate.