Left a little early.
Stations 1, 7, 9, 11, 19 and 20 all lost contact with the domain controller; 19 was successfully removed and added back into the domain, but as of this writing, Greg is still working on the others. We have heard that Cisco routing equipment is reputed to be the cause of this kind of thing. Caused problems for a Russian class in the lab. Greg will probably add more detail later; he was out when it happened, so I caught the initial request for help and spent an hour on it.
Began porting RecentFiles library. This unfortunately relies on my old-style XML i/o code instead of ADOM, so the disk i/o stuff will have to be rewritten, but it shouldn't take more than an hour or so.
Also, with Greg, began testing D2009 test apps on Darwine. It seems that the Kronenberg download of Darwine (which is at 1.0.1, the same as the Ubuntu version) works perfectly as long as you run your apps from the command line using the wine binary; if you try to use his WineHelper app, they blow up. What this means is that Wine works great on OSX (we even tested with Japanese GUI strings), so we have a viable platform, but we don't have a user-friendly Wine front-end for Mac users. That may change over time, but in any case we can provide a script-based installer that would put the app in the right place, and then create shortcuts that would run it properly. So all three platforms are a go.
For future reference
Came across something that might work in place of the QT-based player.
JW FLV Media Player 4.3
Player homepage and download: http://www.longtailvideo.com/players/jw-flv-player/
API documentation: http://developer.longtailvideo.com/trac/wiki/FlashAPI
Moved some changes up from the dev site to the main PA dept site.
I've gone through Amboise 1 to add all the remaining <fw> elements (catchwords and sigs), fix some missing line-breaks, remove spaces before linebreaks (so that removal of hyphenation works correctly), add the last couple of elements (the "Fin..." line and the library stamp on the last page), and a bit of other tidying up. Amboise is now "complete" (meaning it needs to be proofed against its web view and PDF).
The banquet for the conference is currently an agenda item for the main event, but there will also be people who register for only the banquet and do not attend the conference; for those people, we've created a second RegOnline event which you can register for separately. This is awaiting testing and activation by JS-R.
As we get towards the end of the markup of the first novel, I've worked carefully through the Amboise vol 2 again, and done a number of things:
- Automated the markup of page numbers and running titles, based on the old page numbers in
@nattributes of<pb>tags. This will save LW a lot of time. I've also run the same code on the vol 1, to help TG. - Manually marked up the remainder of the "sig" and catchword strings in vol 2, partly to get it finished, but mainly to shake down and normalize all the relevant markup practices. They're detailed below.
- Fixed a few oddities and typos.
- Added more CSS and XSLT updates, mainly to normalize long s characters to regular s in the "continuous view" (which is becoming the "more modern view"), and to remove trailing hyphens and leading spaces from linebreaks. There are 998 instances of words hyphenated across linebreaks in the text, and a quick scan through showed none that I could see that ought to retain their hyphens, so I've gone for a global solution which may result in a few hyphens disappearing where they ought not to, but which is certainly better than a hyphen+space interrupting a word 998 times.
These are some standard formats I've used for the forme works, included here for documentation and reference purposes:
- Catchwords in these texts are always bottom-right, so they're marked up as follows, following a regular line break:
<fw type="catchword" place="bot-right" rend="float: right;">bligea</fw><lb/>
The@placeattribute is only there for tradition, really; the whole rendering instruction is in the@rendattribute. - Signature labels (type 1): There are two types of signature numbers, one of which is simply the number in roman numerals (this is the only kind which appears in volume one). Again, these follow the last line break:
<fw type="sig" place="bot-right" rend="float: right; margin-right: 3em;">A iiij</fw>
As above, the@placeattribute is really superfluous. The@rendattribute captures the fact that the sig identifier appears floated right, but is slightly indented from the right margin. - Signature labels (type 2): The second type of signature marks the beginning of a signature, and is more complex; it appears only in volume 2:
<fw type="sig" place="bot-center" rend="text-align: center; margin-left: auto; margin-right: auto;"><hi rend="font-style: italic;">II. Part.</hi><space quantity="4" unit="em"/>B</fw>
The whole (treated as one line) is roughly centered, but the two components are separated by a space of about 4 ems (all measurement is done in ems, for simple scalability). The margin settings are there as a conventional way to express the fact that the block is not full-width, and is located in the centre (and this CSS can be passed straight to the browser in the rendering code, to get the effect we want). - Page numbers: Whether right or left (recto or verso respectively), these come first after the page break. That has two advantages: first, we know where they are reliably, programmatically, and second, they will render correctly floated, alongside the centred running title:
<fw type="pageNum" place="top-left" rend="float: left;">18</fw>
- Running titles: These are always encoded after the page number, even if the page number is on the right, for the reasons stated above:
<fw type="head" place="top-centre" rend="text-align: center; margin-left: auto; margin-right: auto;"><hi rend="font-style: italic;">Le Comte</hi></fw>
As with other<fw>tags, the@rendis the key attribute, expressing the fact that this is a part-width, centred block that renders on the same line as the floated page number.
- When in edit mode, new searches do not respect the setting. All new hits display in browse mode.
- When the editor has no image to display it shows a default image. Sometimes, however, the db thinks there *is* an image (sql `has_img`='Yes'). It should check if `has_img`='Yes' AND if there is an image where it's supposed to be. If there is a mismatch there, catch it and warn the editor that they have either a missing image (in which case, change the has_img value) or the image is misnamed (in which case inform me so I can change it).
- Add fields for has_img and definer to editor.
- Set up a script that uses shell_exec to rsync (only update) the images folder in the live DB with a folder that the department sets up for the RA to use. This way, RAs doing the scanning can upload images somewhere (like unix.uvic.ca) and we don't have to give them access to our FS.
Added a new search and report field (e.g. family status)
For search form, create new form element by adding to searchformbasic.inc
<label for="p_family">Family Status</label>
<a class="DataListButton" onclick="showDataList('p_family_text','p_families','Family Statuses','f_family_id','p_family','n','y');">
<img src="images/buttons/DataListButton.png" alt="Show a list of possible values for this field" title="Show a list of possible values for this field" class="button" /></a>
<input name="p_family" type="text" id="p_family" value="<? print $p_family; ?>" />
On search.php, grab the value from the form on page load:
$p_family = load_data('p_family');
On search.php, extend SELECT clause of $query by appending:
" p_families.p_family_text"
On search.php, do JOIN of exams table and p_families table:
$left_join .= " LEFT JOIN p_families ON (p_families.p_family_id = exams.p_family) ";
On search.php, add to WHERE clause if user has specified a value in the Family field of the search form:
if (!empty($p_family)) {
$where .= make_where_pattern($p_family, 'p_families.p_family_text', $where);
}
On searchresults.inc, grab the family status item from the current row array returned from the search query:
$curPFamily = $row["p_family_text"];
On searchresults.inc, display the family status data:
<th>Family Status</th>
<td><?php echo $curPFamily;?></td>