Mariage

The title problem is actually in the title bar of the thumbnail window; when the titles of engravings or texts are long, they wrap too many times and the gradient fill graphic isn't large enough to fill the title bar area, resulting in unfilled bands under the title. "Fixed" this by changing the XSLT to invoke the truncation template so that long titles are truncated for the thumbnail window, just like they are for the document list. Tested on a range of browsers - seems OK, unless you make your font size so large that the same problem occurs even with short titles.

Could you tell me what's incorrect about those document titles? The site is just using the titles from the documents themselves, truncated so the page displays in a usable manner. Quite a while ago we discussed the possibility that you might add short-and-user-friendly titles for each of the documents (with regularized capitalization), but that's not been done yet, so we're stuck with the title as it is in the document. Some of them are virtually of paragraph length, so of course they have to be truncated for the purposes of the document listing. If that's all the problem is, then all we need to do is get you to add a new display title to each document. If there are typos of some kind in the titles themselves, then you just need to fix the XML code in the documents.

I've been a bit unhappy with the way the document list looks, so I revisited it today. For the ScanCan project, I've written a Java sort comparator which ignores leading articles when sorting text strings. This seems a promising approach for our document list, so I added French articles to the mix, and tested it. You have to allow for the following prefixes (quotes included to show spaces):

• "THE "
• "A "
• "AN "
• "LE "
• "LA "
• "LES "
• "L'"
• "L’"

remembering to include both varieties of apostrophe. I'm assuming I shouldn't be allowing for "un" and "une" -- correct me if I'm wrong!

Right now, the output just SORTS according to these rules; it doesn't remove or move the leading article from its place. If this were an English project, I would add code to the XSLT to complement this, so that the article would be removed to the end of the title, like this:

The Unfortunate Traveller becomes Unfortunate Traveller, The.

I don't know whether this is commonly done in French, or what the rules are for doing it, so I've refrained for the moment.

I also added a class "EvenRow" to the even-numbered rows of the output table, so that CSS can be used to give the rows an alternating background colour; this will make it easier to disentangle the documents visually. Greg is adding the colours to the stylesheets now.

Checked and uploaded the Invention (2) file.

Also logging time spent swapping in Claire's translation of the Style Switcher page, and adding it to the menu; and a discussion of ideas for the "multimedia presentation" view of the image markup files, with audio commentary.

Checking on the server, I discovered two things:

1. France had apparently edited some of the image markup files last Friday. I brought them down to my machine, validated them, and put them up into the db. That makes the db versions of the image files current.
2. My copies of many of the text markup files are older than those on the server account, which suggests that someone has edited those files since I last took copies for the db. This goes back to April, so I'll check with Claire before I do anything about this.

Worked for a while on the three different stylesheets, in an attempt to solve the problem of the search <fieldset>, which often wraps in an ugly way. The issue is caused by the div.Content selector, which has max-width: 50em. This is supplied in order to restrict the width of content on the page, in an attempt to prevent lines from becoming unreadably long when the screen is wide. However, the search <fieldset> is a child of this <div>, and is therefore restricted by it. The best option we could come up with that helps the search page layout without breaking the main site layout is to add white-space: nowrap to the fieldset selector's style. This works great for Firefox and Opera, but IE predictably ignores it. We'll probably have to revisit this.

These were the steps:

1. Created a content document called style.xml, with three links, one for each style (the page is here). Actually, they were originally links, but for various reasons (mainly oddities in the behaviour of Safari and Konqueror with anchor tags which have no href attribute), I ended up making them <span> tags with an onclick event.
2. Created a pipeline just for that page, for testing purposes, and implemented the branching structure for that pipeline.
3. Created a couple of JavaScript functions in the utilities.js file. One just sets a cookie (adapted from this page). The other does this:

   function SwitchStyle(NewStyle){
       SetCookie('PageStyle', NewStyle, 365, '/', '', '');
       window.location.reload();
   }
   

4. Set the onclick event in the <span> tags on the page to call the SwitchStyle function.
5. Tested the page on Firefox, IE6, IE7, Opera, Safari, WebKit and Konqueror, and tweaked until it worked the same on all the files.
6. Worked through all of the relevant matchers in the stylesheet, adding branching blocks as appropriate, and testing as I went.

Everything seems to be working well. IE's lousy CSS support makes all three themes less attractive on that browser, but that's life.

Now I need to get the text on the style-switching page translated, before I can add it to the site menu.

In a test pipeline, I implemented a branching structure following the example linked from the post below (next but one). I checked the root sitemap for Cocoon, and the Cookie Selector wasn't mentioned, so I added it to the Mariage sitemap:

<map:selectors>
  <map:selector name="cookie-selector" src="org.apache.cocoon.selection.CookieSelector"/>
</map:selectors>

Then I downloaded the very useful Firefox extension Edit Cookies so that I could add and edit cookies for the site. Adding and changing the cookie changes the styles as planned. Next I need to create the switcher page.

Implemented the first two steps in the previous posting, by making changes to four stylesheets (index2.xsl, all_docs.xsl, imt_p5_1_to_xhtml.xsl and text_p5_to_xhtml.xsl). Then I set up two test pipelines for documents and site pages, and manually set the parameter to see the style change. That all works fine, so next we can go on to stage 3.

We now have three distinct styles for the site, and we need a way to switch between them, and store the user's preference. After a bit of reading around, I think this is the best approach:

• Implement a style page which allows the user to preview the styles and choose one.
• Choosing a style sets a cookie in the user's browser.
• Sitemap pipelines for rendering pages follow this example to branch based on the value of the cookie.
• Instead of branching to different stylesheets, the XSLT stylesheet is the same in each branch, but different parameters are passed to it, as in the second example snippet on this page.
• The XSLT stylesheet inserts different CSS in the output (one file in the case of regular pages, and two files in the case of the imgae markup pages) depending on the value of the parameter passed to it.

This would be a good approach to building the functionality:

1. Tweak the XSLT code to use a parameter to determine the CSS to use, and give it a default value (the current preferred style).
2. Create test pipelines using slightly different URLs which pass other parameters in, and make sure that the stylesheets do switch appropriately.
3. Make the real pipelines branch based on the cookie value. At this point, the cookie doesn't exist, so we should always see the default style.
4. Hack the cookies in your browser to add appropriate values, and check whether the style is switched appropriately. Try this in various browsers.
5. Write the stylesheet switching page, and test it thoroughly.
6. Add the stylesheet switching page to the site menu.

Adding this as a task.