HCMC Blogs

With the proposal for DH accepted, I'm now planning an implementation of the application that I could use to demonstrate and work with real data, and wondering what platform to use. I've already written one implementation in Delphi (not acceptable as a proper solution, because it's not cross-platform), and written a command-line implementation of the basic similarity metric in Java (easy because zip support is built into Java). But I'm now wondering if the benefits of compiled code, and the opportunity to build my QT skills up, merit doing this project in QT, assuming there's time before July. This is why I've decided to try this project in QT:

• QT includes qcompress, which takes a bytestream and returns a compressed bytestream, using zlib. This should be perfect for our purpose.
• C++ is going to be MUCH quicker for this sort of processing.
• I need more practice with QT and C++.
• A cross-platform native app will be as acceptable to the community as Java.

I've set up a new QT project for this, and I'm going to start coding the basic class for zipping, measuring, and calculating the similarity metric over the next couple of weeks.

Busy with committee work, but still having to keep the projects ticking over, the email answered and the databases updated...

Posting time spent with the third candidate (tour, lunch, interview).

I've been working slowly on the Laon style, which has now got a bit closer to the other styles in the interests of conformity; I've also made some tweaks to the main stylesheet to space some things out a little. I think progress on the appearance of the site will have to be incremental, because there's not enough time right now for the kind of work that a radical revision would require.

For text documents which have a thumbnail, the thumbnail is linked by including it in a <note> tag in the <biblStruct> in the <teiHeader>:

<biblStruct>
  [...]
  <note><graphic url="thumb_varin.jpg"/></note>
</biblStruct>

The XQuery finds this because it's looking for the first <graphic> element in the document. The XSLT is able to distinguish between <graphic>s in image markup files (which have no preceding "thumb_" in the filename) and these items, which do; the "thumb_" is only supplied in the teaser where it's needed. In the case of image markup files, the <graphic> the <facsimile> part of the document links to the main image for the file, and the thumbnail link is constructed from it, on the assumption (always true) that it exists; in the case of text documents, the thumbnail is the only image, so its filename is complete, but the XSLT is sensitive to this.

Attended the third of the presentations.

Talked with CC, and we decided that we want to show thumbnails of title pages in the teasers for text documents whenever we can. To that end, I've extracted and trimmed up teaser-sized images from all of the PDFs I have; CC has a couple more that I don't have, and she'll send them on. Once that's done, I have to determine how to make them work. Right now, the XQuery simply copies the first graphic/@url into an @n attribute on the <bibl[Struct]> tag which is generated as part of creating the TOC; this is then used to generate the thumbnail link, on the assumption that if there's an image, there's a thumbnail. I think we're going to have to be more explicit than this, though, so we can link in a thumbnail separately from a parent image (because for the texts, we won't be showing any larger image at all). This will require changes to both XQuery and XSLT, and presumably also to the XML of documents for which we now have thumbnails.

We noticed that the titles of engravings in our db sometimes didn't match the titles as shown in BNF catalogues; this led to some confusion when referencing the documents in articles. CC sent me a list of some of the BNF titles. This is what I've done:

• Where BNF titles are supplied, I've used them verbatim in the titleStmt/title, sourceDesc/biblStruct/title, and sourceDesc/biblStruct/title[@type="trunc"] elements. I have not created truncated versions of them, because few of them are all that long anyway.
• Where the BNF provided two titles, I have used them like this: Title one (Title two).
• Where the filename (and @xml:id) of the document did not match the title, I have created a new filename and @xml:id which does match the title (being a normalized, lower-case, truncated form of its first few words).
• For a few engravings for which CC didn't send me the BNF title, I have still normalized the filename and @xml:id. The aim here is to make it easier to find the XML document based on the title.
• Updated references to all documents which have changed throughout the collection.