This takes the prize for "strangest effect of the week."

At the top of the init.bsh file of Minimal, insert these lines:

for(AlbumObject ao : rootFolder.getChildren()) {
	Map thesevars = ao.getVars();
}

Obviously, this isn't actually doing anything - I've stripped this down from what I was tinkering with.

In Minimal, fixed-shape thumbnails are the default. With that code in init.bsh, add a couple of non-square images (so you can see the effect), Make Album, and look at the result. The actual thumbnails have, in fact, been created in the output with a fixed shape (square, per the default bounds). But on the page, they're shown with their non-fixed-shape bounds! When processing index.htt, the thumbHeight is being mis-reported, and gets plugged into the HTML.

Comment out those three lines, and Make All. The thumbnails are correct again.

Why would simply looking at an object's variables do this? Is Heisenberg involved in this somehow?

If you put those lines at the end of init.bsh, the error doesn't occur. And if you do the same routine in predir.bsh (using currentFolder instead of rootFolder, of course), there's no problem.

If you try to create a recursive routine like this, you get a "parse error," and I have no idea why:

private void traverse(AlbumObject thisfolder) {
	for(AlbumObject obj : thisfolder.getChildren()) {
		if(obj.isFolder()) traverse(obj);
		else Map thesevars = obj.getVars();
	}
}
 
traverse(rootFolder);

Please tell me I'm doing something obviously dopey.

Well, yes, it does, but, but, but.... In Java, the curly braces are optional if the clause contains only one statement! BeanShell weirdness at work?

ETA: I was puzzled, because I do these "brace-less" one-liners all over the place, but with a critical difference. Guess what else works? This:

else thesevars = obj.getVars(); 

Something about the typing is what trips it up.

Of course, this still screws up the fixed-shape routine. Well, not really - as I said earlier, the thumbnails in the output really are square! It's just the thumbHeight that's coughing up the wrong value.

Don't we all love BeanShell? . I must admit however that I've never seen a variable declaration in a single statement else clause. There's really no point in such code as the variable is discarded as soon as the else clause is done.

Now to the problem: It comes from the lazy instantiation of the variables bound to each album object. The 1:st call to getVars() causes the variables to be instantiated (set up), but if you, at that time haven't added the image filters to the engine, then the effect of applying, for instance the FixedShapeFilter to thumbnails isn't taken into account when calculating the width and height variables for thumbnails.

Background: jAlbum processes pages before processing images. This design allows page processing scriptlets to adjust the image processing and allows page processing without image processing. However, this design requires each image filter to be queried for how they affect the image sizes at page-processing time. (It's then up to each image filter to fulfill this promise when generating the actual image). Image filters can tell jAlbum that they actually affect the image size and that they want to be queried about this by implementing the ModifiesSize interface.