ECH called to discuss two possible grant proposals; we went over the groundwork and arranged a ftf meeting to actually finalize the applications next week. Also she reported a couple of glitches on display of the site on some Windows computers; these were likely old, but details are not available of the setup. We should definitely build in detailed testing of how widely-supported the CSS3 font embedding really is.
September 2, 2011
Updates to the site on DR's instructions to add information, posters, photos etc. for the upcoming film week, and for last year's film week.
As in title.
September 1, 2011
I've made substantial changes to the Le Blanc, adding many linebreaks, moving all right-floated labels further into the margin, and reducing the page size. There are still problems: one issue is that the <quote type="italics"> inline quotes often actually have a smaller font size than the surrounding text, but @rend attributes on <quote> are not carried through to the XHTML yet. That needs to be fixed in the XSLT, and then the relevant <quote> elements (there are 394 of them) need to be examined to see if they need the @rend to reduce their font size.
I've now switched all files over to using the new schema, and standardized them all on the xml-model processing instruction, replacing the oxygen and oasis-schema PIs wherever they occurred. I've also trimmed out a bunch of old unnecessary namespace declarations from root elements.
Following that, I've worked extensively on the Le Blanc, which had a disastrous document model; some chapters were identified as such and some not; chapters were embedded within chapters within other chapters; other divs were left hanging outside chapters; and the structure took no account at all of the volume's organization into four books. That's all now fixed, along with many typos or layout issues I came across while working on it, but it will need proofing again eventually. I'm going to spend a little more time going through LCC's list of issues while I'm focused on that text, though.
August 31, 2011
Greg and Jamie both away early so I was on lates; then I got stuck with a massively invalid XML file that had to be fixed before I could leave it alone.
I've done some major refactoring of Le Blanc, which is my pilot text for using <label> instead of <argument> for the marginal headings. That feature is working well, but I've had to do a huge amount of work to fix wildly proliferating <div>s in the original markup; they're still a bit of a mess, with chapter <div>s interspersed with other unidentified <div>s that have no apparent purpose, while some subsections in chapters are nested <div>s and others aren't. But a few more hours should sort it.
I've also generated a new schema, which includes <argument> in all the right places as before, but also includes <label> and adds the @type attribute to it (so we can distinguish <label>s used for marginal headings from those in e.g. TOCs.
In the process of this work, I discovered some aberrant behaviour in oXygen which threw me for a while. The old oasis-schema PI, linking to an RNG file, was not actually working, now that oXygen has switched to xml-model; instead, it was silently switching to validation with tei_all, which meant that many things would validate under the oasis-schema heading but fail to validate when xml-model was used.
I have completed an image inventory for all the myriad collections we have on file, in a few locations. This can be viewed here as a webpage, which is updated automatically whenever any future changes are made.
Original website (i.e. Stew's version): http://web.uvic.ca/~lang02/bailey/
New development website (note: requires Netlink login): http://web.uvic.ca/~lang02/bailey_v2/
XML schema: http://web.uvic.ca/~lang02/bailey/schema/bailey_trialfile_proofing.rng
The Data
The data has gone through a few schema changes, all documented on the blog. See, in chronological order (i.e. earliest first):
- http://hcmc.uvic.ca/blogs/index.php?blog=36&p=7770&more=1&c=1&tb=1&pb=1
- http://hcmc.uvic.ca/blogs/index.php?blog=36&p=7853&more=1&c=1&tb=1&pb=1
- http://hcmc.uvic.ca/blogs/index.php?blog=36&p=8255&more=1&c=1&tb=1&pb=1
- http://hcmc.uvic.ca/blogs/index.php?blog=36&p=7853&more=1&c=1&tb=1&pb=1
- http://hcmc.uvic.ca/blogs/index.php?blog=36&p=8438&more=1&c=1&tb=1&pb=1
- http://hcmc.uvic.ca/blogs/index.php?blog=36&p=8531&more=1&c=1&tb=1&pb=1
For each set of data that SD sends, I do the following:
- Make a new folder in BaileyCapitalTrials/data/ named after the year range for the data, e.g.: 1730-39
- Put SD's XSL file in that folder
- Follow the import steps to convert the XSL to XML, saving all of the step_*.xml files in the newly created folder: http://hcmc.uvic.ca/blogs/index.php?blog=36&p=8283&more=1&c=1&tb=1&pb=1
- Make a copy of step_3.xml and save it as (using 1730-39 as an example) 1730_1739_for_proofing.xml
- Send that file to SD for proofing
- Post on the blog that the data was received, processed, and sent for proofing
Once I get the file back from SD, I do the following:
- Save as 1730_1739_proofed_by_simon.xml in the proper folder (see above)
- Validate the file in Oxygen and fix any errors. There shouldn't be at this point, but SD lets the odd typo slip through the cracks.
- Make a copy, name it 1730-1739.xml and put it in
BaileyCapitalTrials/data/finished_data/ - Once the file is 100% valid, import into the website: http://web.uvic.ca/~lang02/bailey_v2/import/index.php
- Post on the blog that the data was validated
Validation
As noted at the top of this document, the schema file is at http://web.uvic.ca/~lang02/bailey/schema/bailey_trialfile_proofing.rng . SD validates against this file so it always needs to be current.
The Website
The development website ( http://web.uvic.ca/~lang02/bailey_v2/ ) is a feature-complete, and mostly design-complete (I went for a muted look) HTML5-validated website. The site employs Jquery-driven Javascript to handle AJAX requests.
On the search form, the Jquery plugin bsmSelect is used to make multiple select fields more user-friendly. The plugin homepage is here: http://plugins.jquery.com/project/bsmSelect , and the blog post is here: http://hcmc.uvic.ca/blogs/index.php?blog=36&p=7864&more=1&c=1&tb=1&pb=1
The site search – both the form and the results – is handled by the Search suite of classes located at includes/classes (Search.php and the Search subdirectory). The Search_Form class, located at Search/Form.php, is responsible for displaying all of the search fields and populating them with the proper values. All of the classes are fully documented.
The site uses the Zend Framework's DB library for database interaction. The classes are located at includes/classes/Zend . All of the classes used in the site follow the PEAR class naming convention for easy autoloading. The PEAR convention dictates the following:
- Class names should begin with an uppercase letter
- Each file should only contain one class
Each subdirectory that a class is in should be represented in the name, with single underscores separating each level of the hierarchy. For example, if a class lives in Search/Form.php, its class name would be Search_Form . Similarly, if a class lives in My/Name/Is/Bob.php, its class name would be My_Name_Is_Bob . This convention has two primary benefits:
- Locating a class file is easy (just need to know the name of the class and the base class include directory)
- Autoloading classes is simple (the autoloader simply needs to replace underscores with directory separators)
The search results pages – both the results table and a single record – use the Model_ series of classes to display information, as well as either Search_Result (for the results summary) or Search_Single (for a detailed record view). Each row of a table (trials, trial_files, etc.) is represented by a class, which allows for easy placement of formatting functions and the like.
The Chart / Data Visualization
The chart to visualize results uses Flot, a Jquery-based plotting tool:
http://code.google.com/p/flot/
To accomplish the 'stacking' of the results, I used the stacking plugin, which is included wtih Flot:
http://people.iola.dk/olau/flot/examples/stacking.html
The Flot chart gets its information from a dynamic JSON dataset, which is based on a submitted search form. When a search is submitted, it's stored in the user's session for easy re-use on either the search page (to modify results) or the chart page. This is also how the “passing” of data from the chart to the results table (and vice versa) is accomplished – both just read and parse any search information in the session. The results themselves are not saved in the session, just the search query parameters.
The Flot initialization code is in js/init-flot.js – it's almost all 'stock' and taken from the examples, with the minor exception of a modification I had to make to get the totals for each year display under the year name in on the X axis of the chart.
I'm overall very happy with Flot, as is SD. It's fairly simple, decently fast, and, unlike some alternatives, still under active development.
I've now got the PDF down to 429 pages, by expanding the text area of the page a bit closer to the page number and the running title, and moving the page number down a little. I think we're still within the page limits they prescribe.
I've also fixed the drop-capital problem. The main fix was to uncomment the commented-out line-height: 1 setting.
So this is what remains to be done:
- Creating a title for the book, and reworking the title page.
- Rewriting the front matter, possibly eliminating the French version, and perhaps removing HT as review editor (I presume, since there are no reviews in the book, although she should definitely go in for proofing and editing).
- Getting a new ISBN number.
- Deciding whether we keep the current copyright declaration or rewrite it.
- Rewriting the introduction.
- Checking all the graphics in the articles to make sure they're placed appropriately. Articles with graphics:
- Egholm
- Gudmundsson
- Lindqvist
- Lunde
- Smith
Other things to consider:
- Should we start page-numbering earlier in the volume? (It currently starts with the Introduction, but it could also appear on TOC and author information pages.)
- Should we keep the Keyword Index? Alternatively, do we want to create a proper index? (This involves some markup work, although Find should help with a lot of it.)