Like I said, Sicirec had to suspend most of her activities as an intermediary by mandate of the AFM. In order to survive and to continue the realization of their philosophy the company had to reorganize and focus on new projects. Where previously they had been focused on servicing the interests of a investments in third-party projects over which they had little to no control, they’re now developing their own projects (and also are still offering investments in the Sicirec Forestry Mixfund, which is the only investment option that remains of the old organization form).

As a previous Webmaster of www.sicirec.org, I had never been entirely satisfied by the limited possibility to really effectively inform all types of hardwood plantation investors within the constraints of a company website. That is why, during the final website cleanup round, before I resigned as Webmaster, I started a wiki about hardwood investments independently of Sicirec. With permission by Popko van der Molen, my dad and then director of Sicirec SA, I used much of the existing information about the various plantation companies that Sicirec maintained on their website as the seed content for this wiki.

Actually, most of the seed content was in Dutch, so after translating some of it for the English language wiki, I started a Dutch language version sister wiki and copied most of the content there. Since then (May, 2007), the Dutch version has grown to 500 pages, while the English version has remained at a meager 77 pages.

If you have anything you want to know or say about hardwood investments, you might like one of my wikis:

• Everything about investing in teak plantations and other hardwood investments
• Alles over investeren in teakplantages en andere hardhout-investeringen

The original logo with the “S.A.” suffix intact.

After removing the S.A. suffix from the vector file in Illustrator’s vector format, I wanted to export the logo to a small PNG again. Annoyingly, though, the PNG—if I wanted Illustrator to respect the correct aspect ratio—could not be the same width as the original PNG if I gave it the same height; it would always be one pixel higher. If, however, I exported it as a huge PNG corresponding to the vector’s original dimensions and scaled it down in The GIMP, the dimensions turned out about the same.

It was then that I noticed that The GIMP’s scaling algorithm is actually very decent. From just looking at the two images below, you need a moment or two to notice that one is a little sharper than the other. Obviously, that’s the Illustrator version.

In the end, though, neither version integrated easily with the complex layout which I had based around the logo image, so I simply opened the existing PNG image in The GIMP and erased the S.A. suffix.

The original PNG after the GIMP treatment.

I still don’t understand why I couldn’t repeat the scaling result of the original image in Illustrator. But, I’ve probably wasted enough time on a rounding issue that isn’t even an issue…

The Apache HTTPD at InitFour, our webhosting provider, is configured to send ISO-8859-1 by default, while the one on our test server is configured for UTF-8. This caused a little bit of a surprise when I uploaded the refreshed website and saw all characters outside the ASCII range mangled on the life website!

I quickly dug into my .htaccess file to add the AddCharset utf-8 .xhtml directive. To my surprise, this didn’t do squat. A lot of fiddling, reloading and researching later, I realized that the following section in my .htaccess file rendered the AddCharset directive irrelevant:

<Files *.xhtml>
ForceType text/html
</Files>

I had to change the ForceType directive to include the charset as a MIME parameter:

<Files *.xhtml>
ForceType 'text/html; charset=UTF-8'
</Files>

Now, it all seemed to work. (Except that it didn’t really because I do some ridiculously complex content negotiation stuff involving a 406 handler in PHP that virtuals the most appropriate variant when no match is found. This script didn’t send a useful Content-Type header. After first adding it to the script, I noticed that the AddDefaultCharset is actually allowed in .htaccess context—a discovery which luckily rendered the other hacks useless.)

Subversion’s merge tracking is non-existent. This means that, when I climb from branch to trunk and back again a lot, I have to manually keep track of all the changes in trunk/ that I merged into the branch. Every one such change, once merged, loses much of its meaningful history unless I painstakingly merge all the commit messages of the patch into the message of the commit that I do after the merge.

Today, after having maintained a branch for months to keep it somewhat in sync with an every-changing trunk, I’m at the point of having to merge the branch back into trunk. This is rather nightmarish because there are bound to be the many merge conflicts that I already suffered whenever merging changes from the trunk into the branch and then multiplied some.

To avoid torture, I decided I’d rather just replace the trunk with my feature branch. This is especially attractive because I then retain the history of the branch which is a little more useful to me than the history of the trunk.

I googled around a bit and could find one thread discussing a similar problem. The solution proposed there seemed to involve a few too many steps for my taste, so I did the following:

# From the working copy of my branch:
$ svn del file:///repos/trunk -m "Temporarily deleted trunk."
$ svn mv file:///repos/branches/my_branch file:///repos/trunk -m "Moved /branches/my_branch to /trunk"
$ svn switch file:///repos/trunk 

That worked perfectly fine. (Except that I still want automatic merge tracking, dammit!)