After some discussion with PG and with the TEI list, it seems that we should be doing this:
<pb> tag.<fw type="folioNum">29</fw>.Leaving a bit early.
Implemented the #3 solution from my previous post, on the local machine. In the process, I discovered an oddity in flowscript: if you have a string variable in flowscript (in this case mine is created from a Java String object), it doesn't seem to have a .length property, but it does seem to have a .length() method. Annoying and confusing.
I now have PDF generation with images working locally, and backups working (they also depend on the realpath value).
This was done by making changes to these files:
save_transformations.flowsitemap.xmaputilities.xslpdf_general.xslI should be able to migrate those changes to the main server without endangering much else, for testing; I'll try that on Monday. Once that's out of the way, and if it's confirmed to be working, then the whole site is portable again and I can go back to working on the corpus PDF code, which is quite complicated.
To further my work on the corpus PDF document, I've set up a local copy of the journal on my system. This has thrown up a couple of issues related to platform compatiblity. The main one is that the Cocoon realpath:/ protocol returns a path ending in a trailing slash on Linux, but on Windows there's no slash. This means (among other things) that images are not retrieved and used for PDF generation, because the path to the images folder is created based on realpath, and ends up lacking a slash.
Cross-platform compatibility is important for this project, so I need to solve this. These are some of the options:
teiJournal/images". This means that part of the path to the images is hard-coded into the XSLT, which perhaps makes it harder to change.realpath inside the sitemap, and branching based on that. (I don't know of any way to do that, other than flowscript).teiJournal/images in our current setup), then having the XSLT combine the two to create the full path. On balance, I think #3 is best because it allows for configuration within the sitemap, but platform flexibility through the XSLT.
This needs to be tested live on the server, though.
The Russian instructor brought some issues to our attention in Lab C, and they also proved to be the same in Lab B. The problem was initially confused by the fact that she was trying to access audio on her own site, which turns out to be partly down, so her audio files were not actually available. But when we started looking at other sites with audio, it quickly became obvious that there's something wrong. This is the issue:
On Firefox, the default media player for a wide range of material, including MP3s, is VLC. Unfortunately, VLC is broken on this build. If you try to load an MP3 file from a browser link, you get nothing (or sometimes you get a QuickTime logo with a question mark, for some reason). But nothing happens. If you try to start VLC manually from the Start menu, it fails with an error to the effect that it can't load its skin file. The skin file is there, but it won't load it, and it prompts you to choose another one. If you choose any of the available skin files, nothing happens -- the app just disappears.
On IE, I'm not sure what is configured as the default MP3 player, but you get the same behaviour: the QT logo with a question mark, and no audio.
For the instructor today, I showed her how to save a file to the desktop from a web link; once you do that with an MP3 file, it opens in Sanako, so that's fine.
There are probably two different ways to fix this, depending on your attachment to VLC. If VLC can be fixed, then great; but if not, then another player needs to be chosen as the default for all the media types currently assigned to VLC; the browser could either shell out to Sanako, or perhaps use QuickTime.
Also, Lab C station 20 is broken. It starts up, and it will let you log in, but once you log in, you just get a purple screen with a mouse cursor, and no desktop; after that it won't respond to anything.
met with SA and IMH to discuss use of Illustrator image of half globe including Europe for their information site. They said no problem with fact that image is a political map of modern Europe. They want user to click on location on map to populate a categorized list of topics (categories are Art/Architecture, Events, Geography, People, History). When the user clicks on one of the topics, then the details are presented. The details are typically a couple of hundred words organized by who, what, where, when, what.
They'd also like to be able to get at the topics by specifying any one of the categories and getting all records which have a value for that category.
They'd also like a search box. Looks like they'll need a small database backend.
IMH will send me samples of data and specifications for what part of the map he wants to use. We'll work with Greg to extract a bitmap for the map for now.
I'll come up with a design for the site and its interface over the next week.
They also want a rewrite of the departmental site by next September. As this site is fairly small, I might use it to try out the uvic template. They may have a student available who would be capable of taking template files and structural specs and producing a website.
Set up the pipeline for generating a PDF of an issue or annotation, and began work on it. First of all, I had to modify some of the base PDF code, which wasn't designed to handle a situation in which there were multiple documents. The most obvious case was the handling of end notes for each article, which is now fixed. Another case, still not fixed, is the handling of running titles and headers. These need to be derived per-TEI, rather than globally; my templates are rather too general, and result in all the items from all the articles being agglomerated and used en masse everywhere. One issue with this is that right now, there's presumably quite a lot of activity on the site, so I need to be careful not to break the existing PDF code.
However, I have a composite document rendering, with page-numbering and the like working OK. Before I go any further, I think I need to build a local copy of the system and work on that, though, so the main site isn't at risk.