teiJournal

With HC's departure as editor, I've amended the masthead to remove her and one editorial assistant, but put them on a secondary page which lists previous editorial staff.

With some help from the Cocoon list and from my own experimentation, it seems that {system-properties:os.name}, {system-properties:file.separator} and other similar variables are available in the sitemap using the SystemPropertiesModule input module, which is enabled by default.

Migrated fop-config.xsl to the production server (see previous message). PDF fonts seem to be working fine.

The problems with Windows continue, this time with the PDF generation, which depends on FOP being able to find the TTF font files. The trailing-slash issue seemed to be at the heart of it, but then I discovered that there was also an issue with the root path containing backslashes, but the relative path component for fonts having forward slashes.

After much pain and suffering, looking for a way to determine what host os Cocoon is running on, I decided that I can make that decision based on the presence of backslashes in the root path. If there are backslashes, then I conclude that it's running on Windows, so I need to change forward slashes to backslashes, and make sure the trailing slash is added to the end of the root path.

This is done in the file:

• fop-config.xsl

Tomorrow, I'll try migrating this solution to the live server, with the usual caution.

Cautiously migrated the four changed files listed in the previous post to the main site, and tested; PDFs are working fine, with embedded images, and backups are also working.

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.flow
• sitemap.xmap
• utilities.xsl
• pdf_general.xsl

I 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:

• Instead of passing in a fully-constructed path from the sitemap to the XSLT transformation, pass in only the realpath variable. Then the XSLT can check for a trailing slash before building the full path by adding "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.
• Finding some way to check the value returned by realpath inside the sitemap, and branching based on that. (I don't know of any way to do that, other than flowscript).
• A modified version of #1, which would pass both realpath and the subsequent component (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.

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.

The "corpus output" (a composite file consisting of a collection of individual contributions -- an issue, or an ad-hoc anthology) now has a complete <teiHeader> element, created by cherry-picking and combining various bits and pieces from the component documents. This is rather a complicated business, and is not always precisely what you want -- for instance, if you combine documents from two vol/issue sets, you'll get idno elements for each volume and issue, but no clear indication of which volume number goes with which issue number. Still thinking about that.

Completed the last two features of the backup system: there's now a button which can back up all the files, one by one; and there's a link to download a zip archive of all the files.

Because of (very reasonable) browser restrictions to prevent cross-domain scripting, it proves to be impossible to retrieve the response from the server when doing either an individual file backup or all of them, when the site is proxied through Bruno's server. What happens is that the JavaScript on the client runs, but the XMLHttpRequest object quite sensibly says that it can't do anything with the response because the response originates from a server which is not the one serving the page. Fair enough; I have some error-trapping in place which gives reasonable feedback for that, and given that (we hope) this password-protection nonsense will go away soon, we can live with it.

The other feature is pretty cool, and worth documenting in some detail. This is how it works:

• A directory generator is called to create Cocoon's standard directory generator XML output.
• This is run through an XSLT transformation which formats it as expected by Cocoon's zip serializer.
• The zip serializer streams out a zip file, as if it were a normal download of a static file. Whether it's creating a temp file first, then serializing it out, or serializing a zip file on the file, file by file, is difficult to know, but it's very fast and it works perfectly.

So now, with one click, the editor can create backups of every output format of every file on the system; and then download a zip archive of the results.