Marti's blog

So it seems Canon couldn't be bothered writing a 64 bits driver for its MF5600 and MF5650 multifunction printer, even though Windows XP 64 bits already existed when the printer came out, and Vista arrived just 2 years later. That means that for anyone running Windows 64 bits, the printer is as good as a plain photocopier.

Printers models change all the time, but manufacturers usually stick to the same internals and protocol for a while. Now in the olden days of parallel port printing, there was no way for the driver to know what it was really driving, so if you couldn't find the exact driver you needed, you could just choose one for a slightly different model, install it and print happily. No such luck with USB: the driver knows exactly what is at the other end of the cable and will not install on the wrong printer.

So as it turns out, Canon has a 64 bit driver for the MF5700, which is pretty much the same thing as the MF5600. And of course the driver won't install. I however found out a workaround to keep printing : go to the Printer control panel, ask to install a new printer and choose the port "Print to file". When prompted for the driver, give Windows the location of the MF5700 64 bit drivers... the installation will go smoothly. Now go to the properties of the newly installed printer and change the port to the USB port you are using for your MF5600 driver. That's all ! The printer will still report as "non functionnal" on the device panel but printing works. You are still out of luck for scanning.

Why Canon hasn't bothered to write the 64 bits driver for the MF5600 series as well as the MF5700, given that it's pretty much the same thing, I don't know. I guess I'll not be buying another Canon printer next time.

You can now consider it officially official, as Toshiba announces discontinuation of HD DVD Businesses. Not exactly a surprise at this point, but now everyone can finally buy HD movies in a format (Blu-ray) knowing that it'll still be around for some time.

Note that I already predicted Blu-ray victory back in july, but then I had about 50% of being correct, so no cigar.

PHP 6 has been in the making for a while now and is hopefully going to come out this year. Although no official release - not even alpha - has been made, it's quite possible to use it right now by compiling the nightly build. Why would you want to use PHP 6 to begin with ? Well the biggest reason is Unicode: handling non-latin language with PHP 5 is a tricky exercise because it doesn't recognize Unicode character encoding natively (PHP considers that all characters are 1 byte long). As such the only solution is to use dedicated extensions like mbstring and be extra careful with other functions that expect strings, eventually filtering and converting when necessary.

PHP 6 however knows how to use Unicode (UTF-8 to be precise) natively, and properly configured will handle all strings as Unicode (some changes have been made to handle binary strings as a different type). Best of all, to make upgrading easy, it can use a mismatch of different character encodings seamlessly : you can input and output proper UTF-8 Unicode, store data in a MySQL database configured a different character set all with a scripts written in another one.

Disclaimer: the following is written using whatever information I could gather at the time, as PHP 6 is in the making, it could change over time and I'll try to update this post accordingly.

To PHP 6 or not PHP 6 ?

Since the code is not officially out and subject to bugs as well as compatibility-breaking changes, you might just want to make your current code future-proof and ready for the big release. Or you can try the nightly build at your own risk, but it might not be polished enough for a production environement. If you do install it right away, the following php.ini settings will make it work into Unicode mode :
unicode.semantics = on

And for inputing/outputing into UTF-8 :
unicode.http_input_encoding = utf-8
unicode.output_encoding = utf-8

Writing your scripts with the proper character set

As I wrote above, you don't have to write your scripts in Unicode to process and output Unicode. But it will certainly make things a lot easier. You can tell PHP what is your default script encoding inside php.ini with :
unicode.script_encoding = utf-8

From there you can either convert/write your scripts in UTF-8 with your favorite text editor, or warn PHP of what encoding each file is using by starting your code with an encoding declaration such as declare(encoding="iso-8859-1" ); (it has to be the very first PHP code line). The above declaration is PHP 5 compatible (it then doesn't do anything of course), so it's a good habit to use it everywhere right now. It also makes it easy to share include files between scripts running PHP 5 and PHP 6 and/or in different encoding (very convenient for progressively rolling out your upgrade).

Changing your code

First if you are still using PHP4 (but why ?), well obviously you should start by applying all the changes necessary to work with PHP5.

The ereg extension (regular expressions) is moved to PECL, which mean it's no longer installed by default. The PCRE extension however stays there, and as it's more powerful as well as faster, there's no reason to convert all your code right away to it (all right, so you spent nights trying to get those regexp working and now you have to change them again).

register_globals is gone for good (and it was already just an option in PHP 5), so you need to access all your input parameter with the $_REQUEST[] or other global arrays. $HTTP_POST_VARS and $HTTP_GET_VARS are gone also.

magic_quotes are no more. Good riddance! You can also wave good bye to safe_mode.

Then there are a few rough edges : an exemple is urlencode() which is supposed to process and output non-Unicode string only, but rather than silently convert your string to a binary string (1 byte per char) it just fails and returns a warning. The simple fix is to typecast your string first to binary using something like urlencode((binary)$some_string). This is also normally compatible with PHP 5.2.1 and above.

Other things

Once your PHP code is cleaned up and you have made the switch, you might also want to make sure your database is Unicode compatible. If you are using MySQL, it's usually configured to run some western-latin encoding by default (in which case PHP 6 will send queries in Unicode, and MySQL will transparently convert the best it can). You can convert each table to Utf-8 and use it's full character set by running a ALTER TABLE name_of_table CONVERT TO CHARACTER SET utf8 query (as usual, don't forget to do backups first in case something goes wrong). Do note that as utf8 can use multiple bytes for a single character, it will reduce the amount of space a text or varchar field can accomodate. If your table has such fields that are already full in a 1 byte/char encoding, converting it to UTF-8 might end up "cutting" the end of the text as space is lacking - data loss.

You might also want to serve Javascript, plain HTML or XML or even CSS as UTF-8 : you can use your .htaccess to do that (if you run Apache) by adding a AddCharset utf-8 .html line for every extension.

Further reading

You can read one of the presentation of Andrei Zmievski about Unicode and PHP 6, which greatly helped me upgrade my own code. Also check out Minutes PHP Developers Meeting which has a list of the planned major changes.

We are back again in Singapore. The city-state is famous for its great & cheap food and endless number of restaurants (as well as its ban on chewing-gum), and as such each stay there is the occasion to eat out as much as possible. One of our favorite place to go when we arrive is the old Telok Ayer market (which isn't a market anymore but a hawker center, a local food court). At night, one of the street is blocked to traffic to make space for dining tables served by several satay street sellers. As the sea is also nearby, you get to eat with a refreshing breeze that makes the local climate more bearable.

Since it rained last night we had to eat inside the market itself - not a bad thing in itself as the building is a beautiful iron-cast construction of the early 19th century. I had some spicy mee goreng to go with the satay, and a fresh pinapple juice to sooth my burning mouth. Truly a great meal for an unbelievable price (about 17 € for two !).

Despite adding a simple bot filter in this blog to block spammers (that's the easy and random question you can see below), I've recently found out that some still managed to get through! Have bots gotten smarter or are spammers posting their random garbage manually?

To find out, I actually logged the answers they were providing when posting (successfully or not). Turns out that many bots answer the antispam question randomly. As you would guess, the vast majority fail to post, but a few were lucky enough to get it right when the expected answer was a single digit. Solution: make more complex answer.

Speaking of spammers, I just got a spam SMS on my phone. The idiot who sent this mass-SMSing did something wrong because the SMS had a special keyword that was supposed to be replaced with a personalized value (something such as Congratulation #[RECIPIENT_NUMBER]...). Ahah!

NAS (networked storage servers) can cost a real bundle. In fact anything that can take more than two hard drives tend to be in the 500 € (about the same in dollars), if not more for something with a nice embedded software. And that is without counting the drives of course. Well I still needed to store some datas over a network and after some searches found what must be the cheapest possible NAS: 25 €! Here's how it breaks down:

• 1 old PC a in tower case (Pentium III with 256 Mb): 0 €
• 1 CompactFlash card, 256 Mb: 0 € (got it free with a coupon that came with my camera, but it's too small to use for taking picture)
• 1 CompactFlash to IDE adapter: 15 €
• 1 Serial-ATA controller: 10 € (30 €, but got a 20 € coupon for it, optional if you don't mind using IDE drives)
• FreeNAS, open-source: 0 €

As you can see, the whole trick is reusing old stuff and FreeNAS, which is a neat embedded FreeBSD distribution aimed at building NAS. Installation was very easy and did not require any Unix knowledge: just burn the ISO on a CD and boot it. From there you can either keep using the CD to boot and store the settings on a USB key (automatically detected), or do a full install over either a disk partition, a USB key (if you can boot over USB, but most old PC can't) or as I did, some flash memory installed as an IDE drive. All you have to set up is the initial IP configuration, everything else is done through a nice and user friendly Web interface.

As far as features go, it's got everything you expect a good NAS to have and even more, including SMB, FTP, NFS, RSync, AFP, RAID (0,1 & 5), UPnP, iSCSI, filesystem support, etc. The beauty of FreeNAS is that you can opt for software RAID, and it uses a standard FreeBSD system underneath. As such, you have much more freedom in building a RAID array or moving drives from one system to another (a new FreeNAS system will be able to access the content of RAID drives from a different installation and controller).

The downside is that FreeNAS is still beta, and although it works (for me anyway) it's very much a work in progress right now. Some might feel uncomfortable having their valuable data handled by such beta software.

Flexible HTML layouts are designs that adapt to the user screen and browser window by not using "hard" width and height: using CSS, sizes are set in percentage and not in pixels. In a time and age where users have screens ranging from 320x240 pixels (PDA and smart-phones) to 2540x1600, I think this is a great quality for any web site to have. Flexible layouts however are harder to do, because it's hard to get them to look pretty at varying screen sizes (large resolutions tend to make the page look empty, and at small resolutions it might look too crowded).

There's another hurdle that goes with making flexible layouts: getting form fields to be as flexible as other elements isn't as easy as it's supposed to be. Normally, all you have to do is set a CSS rule such as input, textarea { width: 100% } and your field is supposed to stretch to the width of its containing element. Well, as I found out this week, neither Firefox nor Internet Explorer (6 or 7) can get this right.

Firefox

It's the least buggy of the bunch, but it still has issues with textarea elements set to 100%. The trick is to go for a slightly lower value like 99% or maybe a bit lower depending on your situation. As it turns out, this also helps with Internet Explorer.

Internet Explorer

Both the 6 and 7 version have issues. The 6 is the worst and I have had great difficulties to get fields to flex properly. In the end I've found a hack that puts different CSS for version 6 and other more modern browsers (including version 7). I've always refused to use any non-standard trick to apply different CSS rules to different browser, but this one is 100% standard and quite clean:

input, textarea { width: 30em }
input[type="text"], textarea[id="IdOfTextarea"] { width: 99% }

With these rules, all elements are first sized to 30em, then browsers who are compatible with attribute selectors will apply the following line to elements with the proper name, type or whatever attribute you use to select them.

However I've still had difficulties going on with Internet Explorer 7 and textarea. Adding a style="width: 100%" to a container such as a div has managed to get the thing right.

I've recently gotten to work a bit on optimizing my site for search-engines, and more specifically how to have the best URL possible for search engines. Making your site user-friendly and accessible is a good way to get high ranking in search engines, and having clean and well layed-out URL will certainly help both your users and your ranking. However after searching through the forums I learned a few tricks:

What I knew

Dynamic URL: pages such as article.php?id=3 are properly indexed, however search engine prefer static ones like Article-3.html.

URL keywords: keywords in URL do count, even more so if they are inside the domain name itself (but nowadays all good domains with valuable keywords are taken...). That's why most blogging platforms use the article title to build the URL, eventhough it makes it very hard to type manually.

What I discovered

URL depth count: it seems search engines penalize pages that are too deep in a directory structure. That was an issue for me because like many people I was using mod_rewrite to cleanly pass parameters to scripts (such as script.php/param1/param2/param3/ ).

Dashes are the word separator: another problem was that I was separating keywords in URL with underscore. I went this route because it is easier to read in the address bar, however it turns out that to Google, a dash is seen as a keyword separator whereas the underscore is just another character.

mod_rewrite & PHP to the rescue

Of course I could have just changed the URLs and be done with it, with the old one returning a "404 Not Found" error. However, besides breaking external links, this will hurt ranking in search engine because the new URL will be considered like new pages, and might be considered duplicate content.

The fix to this is a permanent redirect, which is understood properly by search engines as "the page you look for has moved, but is otherwise the same thing". mod_rewrite can do just that, using something like :

RewriteRule ^old_url.html$ new-url.html [R=301,L]

You would obviously use regular expressions to handle multiple redirects within this single line. In my situation, regular expressions were not flexible enough to do my rewrite. I needed to process the old URL in something like PHP to be able to find the new URL and do a proper redirect. I found two roads to get there: the first is to use the RewriteMap instruction in mod_rewrite, which gives you the option of using some external program of your choice to handle URL rewriting. The other was a bit simpler, it involved changing this in the .htaccess file:

RewriteRule ^regexp_for_old_url$ fixit.php [L]

Which would silently have all old URLs handled by fixit.php. This would be a simple PHP script to do the rewriting work:

<?php
$newURL=$_SERVER["REQUEST_URI"];
// Process $newURL here
header('HTTP/1.1 301 Moved Permanently');
header('Location: '.$newURL);
die();
?>

Job's done !

My significant other was getting a bit annoyed at the 4 year old desktop PC she was stuck with, as it was slow (and, well, not very portable), so I decided to get her one of the new Santa-Rosa wave of laptop. There's not a lot of them out there right now but I got my eyes on the new Samsung Q45 which is already available and has pretty much all the required features : small form-factor (12" screen, less than 2 kg), decent power (1,8 Ghz Core 2 Duo with 1 Gb or RAM, new GeForce 8400 Go video card, large hard drive, etc.) and comes with Vista Home Premium. And is rather cheap at 1150 € inc. taxes (most competing models are significantly more)

The thing arrived and I can say it's everything and more than I expected : nice build quality, cool "piano black" cover (that gets fingerprints and dust all the time...), quite light to carry and very silent. Definitely an incredible good deal. My only complain is that it comes with a glossy screen, and I'm not a big fan of those, but having a mate was not an option.

As it turns out this is also my first go at Vista, and while it does look fancy I'm moderately enthusiastic about it. The new Windows Explorer feels a lot less easy to use, and crashed on me after the first 2 minutes of use (but was automatically restarted). The file layout has been overalled in a more sensible manner (My Pictures and other dedicated folders are now separate from My Documents, the whole user files are organized differently, Program Files is no more, etc.), but it takes some time getting used to it.

I also plan to upgrade my over 2 year old laptop soon but am looking forward something in the 13,3" range, and holding out for either the rumored Dell XPS m1330 or a Santa-Rosa version of the Sony SZ4. So probably nothing before at least the middle of July.

So Apple just announced the release of their Safari browser for Windows. As it turns out, this is a 3.0 beta version that is not quite finished. I've played with it a bit and it looks really fancy, bringing along it's Mac-ish appearance to Windows. Fancy animations, iTune-like brushed metal skins, even the font looks different (it seems it doesn't apply those given by the CSS stylesheet). However it's not yet ready for normal usage, as there are some serious bugs: titles and parts of texts disappear, odd stuff happens with backgrounds, and it's not that stable either (it crashed on me in the first 2 minutes of use). Otherwise Apple claims it's faster than Firefox and Internet Explorer 7.0, and while it's hard to tell from a first use, it does indeed feel snappy.

Let's hope some updates will fix the most obvious bugs, it should be an interesting browser to use.