Betalogue

I have yet to find confirmation of this in the official documentation, but it looks like the newer version of WordPress (2.5.1) that I have just installed does away with the separate excerpts feed altogether. With WordPress’s default configuration, I now have to choose between excerpts and full posts in the main feed, and that is the only option I have. (And I choose full posts.)

For now, I have automatically redirected the old excerpts-only feed to the main feed (with full posts). So people who were subscribed to the excerpts feed are now getting the main feed with full posts.

I can try and manually build a separate feed with excerpts only or install a WordPress plug-in that restores the choice. But before I do that, I’d like to ask current Betalogue readers whether they actually want such a feed.

My access logs seem to indicate that quite a few people were subscribed to the old excerpts-only feed, but I am not sure how important it is to Betalogue readers to have such an option. Certainly, the less I have to customize the default WordPress setup, the easier it will be for me. But if enough people say that they want an excerpts-only feed, I will do it.

So if you want one, please let me know by posting a comment or sending an e-mail. If you are happy with just a feed with the full text of the posts, then there is no need to write.

Thanks.

Microsoft’s own Erik Schwiebert writes a post about the return of Visual Basic for Applications to the Mac in the next version of Office.

It is an interesting read, if only to get a sense of the twisted logic under which the MacBU operates. In their world, everything is always great, and things are just going to keep getting better and better. That’s what happens when you live with a near-monopoly situation for so long, I guess. (The comments are also an interesting read.)

I just cannot keep wondering about the “corporate” or “business” Mac users who:

1. were dismayed to hear about the removal of VBA in Office 2008
2. bought Office 2008 anyway, because they didn’t have much of a choice (need for Intel-native applications, need for XML file format support, etc.)
3. painstakingly tried to recreate all their macros using AppleScript
4. now are told that they did all that work for nothing and were just supposed to keep using Office 2004 and wait for Office 2012

I have my own business and I use Office for Mac in my work, but I probably don’t qualify as a “business” user in the eyes of Microsoft, because I am not a big corporation and I refuse to put up with the crap that Microsoft tries to make us swallow.

Still, I could have gone down the path described above and attempted to recreate all my Word macros using AppleScript. I actually did it for one macro (for pasting unformatted text), but I didn’t go any farther, partly because it was a very unpleasant experience, but mostly because I know from experience that Microsoft cannot be trusted and that all the work that I might do today could again count for nothing in one year or two. I have been burnt before.

As the example above demonstrates, it is simply pointless to try and follow Microsoft’s lead. On the contrary, it will cost you, again and again. And don’t believe for a second that all will finally be well when Office 2012 comes out. It is absolutely certain that Microsoft will find more ways to screw you.

The only sensible to do is avoid Microsoft products altogether, as much as possible. I can’t help but wonder whether the real story behind these headlines about the return of VBA for the Mac is that, by dropping VBA, Microsoft was hoping that corporate Mac users would simply drop the Mac altogether and switch to Windows. When they saw that, on the contrary, corporate Mac users were giving up on Microsoft and trying to move to other, competing products (such as iWork), then they realized that dropping VBA was a very bad idea indeed and decided to bring it back.

I suspect that it is too little too late. Of course, Microsoft’s sales numbers won’t fall dramatically any time soon. There’s just too much inertia in a near-monopoly situation and, with the Mac platform as a whole on the rise, like Gruber says, a rising tide lifts all boats. But sooner or later a critical mass of Mac users will realize that they don’t have to put up with this crap anymore and that there are realistic alternatives out there for many situations, including in the business world.

It really is quite unbelievable. And yet it’s true:

Microsoft on Tuesday announced it would restore support for Visual Basic for Applications (VBA) to Microsoft Office for Mac, a direct result of complaints from users about the removal of the suite’s cross-platform automation functionality.

Is Microsoft really telling us that, with all the resources that they have at their disposal to analyse their users’ needs to death (they always brag about how responsive they are to their users’ needs, after all), they really did not get the message about VBA on the Mac until now? What a bunch of hypocrites.

Since the only thing that appears to matter in Microsoft-land is money, one gathers that the latest version of Microsoft Office for Mac has not been selling too well at all. It would hardly be surprising. The new version brings almost no improvements, introduces a whole new slew of bugs (as per usual), performs miserably even on the most recent hardware, and is crippled compared to its predecessor. What’s not to like?

(That said, this official press release sounds like Office 2008 is selling pretty well. So who knows what the real story is.)

I cannot count the number of Mac users that I have talked to in recent times who have spontaneously inquired about iWork ‘08 and asked me, without prompting, what I thought of this alternative. Not many of them are VBA users, however. They are just disillusioned and profoundly frustrated with Microsoft Office in general.

Clearly there is a lot of dissatisfaction out there. (In other words: It’s not just me.) But if Microsoft really think that they can remedy the situation by restoring VBA… in the next version of Office, i.e. probably another 3 or 4 years down the road (talk about a “direct result” of the complaints), they are still seriously deluded. The damage has been done, and it will take more, much more than that to repair it.

Microsoft has been selling us crappy products for many years, and there is only so much abuse that Mac users are willing to take. iWork ‘08 is a realistic alternative—often a much better one—in many situations, and it’s an Apple product. Every current Microsoft Office user on the Mac owes it to himself to at least explore this alternative.

As for Microsoft, if they really want to have any hope to remaining a key player on the Mac, they’ll need to add many, many more resources and work very hard not just to restore VBA, but also to fix and improve Office in many other areas as well. I seriously doubt that they will ever get that message.

I am afraid it looks like there have been repeated attempts to hack Betalogue in recent weeks. I actually now believe that the weird admin user reset problem I described a couple of months ago was the first manifestation of the hacking attempts.

Since then, in addition to repeat occurrences of the admin user reset, I have experienced a range of other issues with my web site, all of which have been invisible to Betalogue readers as far as I can tell. I won’t describe them in full detail here. I am sure that the issues are due to hackers, however, because of the appearance of files in my WordPress directory that I never installed there myself, which clearly bear the mark of either human or automatic hacking. (The Russian credits leave little to the imagination.)

I don’t quite know how “they” were able to go as far as to modify files and add new files, and why they didn’t use this ability to inflict greater and more visible damage. Apparently, based on my research, the problem had to do with something called “SQL injection”—although I have yet to find a page that clearly describes this as a known vulnerability in my version of WordPress, with exploits causing the symptoms that I have been experiencing, and with a clear requirement to upgrade to a newer version. (These search results certainly seem to indicate that it is a recurrent problem with WordPress.)

Still, I have taken a range of measures which I hope will eliminate the problem.

I have changed all the passwords involved (FTP/SSH password, WordPress password, MySQL password). I have removed the files that did not belong and replaced existing files that appeared to have been edited with the original local copies. And most important, I have upgraded to the latest version of WordPress.

I somewhat naively assumed that I was using a “stable” version of WordPress (1.5.1.3, I think) and did not feel the urgent need to keep up-to-date with the latest versions of the blogging software. But I now realize more clearly that server-based software follows rules that are quite different from desktop software, in that security issues are much more crucial and you cannot count on older versions of the software staying immune forever, quite the contrary.

As with other types of software, new versions come with new features, but also with bug fixes and security fixes that are not necessarily implemented in older versions. Since server-based software is permanently “exposed,” however, this means that existing vulnerabilities in older versions will be exploited sooner or later, and so, if you want to remain up-to-date in terms of security, you simply have to upgrade the software.

Fortunately, upgrading WordPress from 1.5.x to the latest version was quite painless. I have probably lost a few minor customizations along the way, but nothing vital, and I will work to restore those, if necessary or desirable, over the coming weeks.

My priority right now, however, is to determine whether the upgrade does eliminate the vulnerability. I won’t know for sure right away, because the hacking attempts, as far as I can tell, have been episodic, with weeks passing without incident. It just so happens that there was another one today and that I actually noticed problems while it was happening. (At least, that’s what I believe.)

As an additional precaution, I have closed new user registrations for now. This means that only existing users can post comments on blog posts. If new users want to comment at this point, they’ll have to write to me. I’ll decide later on if I want to take a chance and reopen user registration.

It’s rather sad that this type of problem exists in the first place. Based on the fact that the hacking attempts did not actually damage the site and only left anonymous code in places on my server, I tend to think that this was the work of some kind of automatic bot scanning the web for exposed vulnerabilities, and not the work of an actual, malicious hacker. (I don’t think it was the work of a “friendly” hacker trying to warn me about existing vulnerabilities on my site either!)

But it is still profoundly annoying and disturbing, especially in light of the fact that I hardly write about highly controversial issues or have a high-profile blog—although one never knows. It’s a crazy world out there.

I also sincerely hope that this hacking has not exposed any user-related data. I have no way of knowing for sure. I obviously want to apologize for any inconvenience that this hacking may have caused for registered Betalogue users. I realize that, by registering on Betalogue, you entrusted me with some private information and that, by failing to sufficiently protect my site from potential security risks, I may have exposed some of this information. Like I said, I may have been a bit naive about the reliability of the WordPress software that I was using, and this incident certainly has been a lesson for me. (If you are concerned about the on-going privacy of your login information, you might want to use your profile page to change your password.)

If all these measures fail to remedy the situation and Betalogue continues to experience hacking attempts, I will obviously have to take things to the next level, either with my host or with WordPress developers. I will certainly keep you posted if there are any new developments. If you notice anything on Betalogue that does not seem right, please do not hesitate to contact me privately using the link in the side bar.

The Official Google Blog has some pretty encouraging news about the recent uptick in the proportion of native Unicode web pages. There has been a pretty dramatic increase in the past couple of years, to the extent that, according to Google, Unicode is now the most frequent encoding found on web pages.

It would be interesting to try and pinpoint the reasons for this sudden surge.

And it would also be interesting to compare this with trends in Unicode use in e-mail communications. Sadly, my own experience suggests that things are probably not as improved in e-mail as they are on the web. I don’t have statistics about how many e-mail messages in my Inbox are encoded using Unicode, but I doubt very much that it represents more than a small minority.

And I am still occasionally encountering situations where messages (often forwarded messages) lose their proper encoding and are rendered improperly, which makes them unreadable and unusable if they contain any non-ASCII characters.

Of course it does not help that Apple’s own Mail application still does not seem to be able to use Unicode by default. The default text encoding when composing a new message is “Automatic” and, in my experience, that means that the message is encoded in ISO-Latin1. I have to manually select the Unicode option (in the “Message” menu) each and every time I compose a message.

Needless to say, I don’t do that, and I doubt very much that many Mac users do. If Entourage’s own interface is any indication, the situation isn’t any better on the Microsoft side.

It’s undoubtedly harder to force IT people to implement proper Unicode support and the use of Unicode as the default encoding in e-mail communications than it is for web pages, where the author of the web page is more in control and there are fewer potential pitfalls between author and reader.

But I am still hoping that, in the not-too-distant future, we’ll all be able to use the full range of Unicode characters in our e-mail communications without having to worry about whether they’ll be readable—and without being forced to switch to HTML e-mail (gasp!) either.

The Dock in Mac OS X 10.5.0 was a horrible fiasco, with the idiotic display and behaviour of “stacks,” which is a word that sounds way more innovative than what it actually describes, i.e. the specific, non-standard behaviour of regular folders in the Dock.

Thankfully, the Mac OS X 10.5.2 update addressed the most glaring issues, with the addition of options that enable you to bring back a certain level of sanity.

Even though these “sane” options are still not the default options—which means that there are still hundreds of thousands of Mac users out there enduring the idiotic Mac OS X 10.5.0 behaviours because they do not know that they can change them—at least by simply right-clicking (or control-clicking) on a “stack” in the Dock you can choose options to display the “stack” as a regular folder icon (as opposed to the utterly useless pseudo-3D display of a pile of multiple icons) and you can bring back the standard hierarchical menu of the folder’s contents that used to be the default option in previous versions of Mac OS X.

However, in spite of these (optional) improvements, I find it mind-boggling that, in Mac OS X 10.5, it is still impossible to open the corresponding folder in a Finder window in a simple way. You can open the corresponding folder in the Finder, but it is not simple. You have to click on the icon in the Dock, and then you have to manually select the “Open in Finder” command.

Worse still, if you are using the option to display the folder’s content in a hierarchical menu when clicking on it in the Dock, by default the “Open in Finder” command is actually hidden at the bottom of the menu:

As you can see in the picture above, the only thing that is visible by default at the bottom of the menu is the top 2 or 3 pixels of the “Options” command. And the “Open in Finder” is below that, so it’s totally invisible by default. You have to move your mouse pointer over the triangle at the bottom of the menu to cause it to scroll down the menu and make the hidden commands visible:

And then you can finally select the “Open in Finder” command to open the folder in question in a Finder window.

This problem occurs regardless of the actual length of the menu. Normally, the triangle is used when a menu is too long to fit on the screen. But that is not the case here. Even if you have tons of room above your Dock to display the menu in full, including its bottom two commands, Mac OS X still hides them by default and requires you to move your mouse pointer over the triangle to reveal them.

Compare this to the behaviour in previous versions of Mac OS X, where you could open the folder in a Finder window through a simple single click on the folder icon!

Mac OS X 10.5 changes the meaning of the single click, of course, which now brings up the contents of the folder in a fan, a grid or a menu. And that’s not necessarily a bad thing in itself.

But what is truly bad is that what used to be the default behaviour before Leopard has now become so complicated to achieve.

I’ve tried combining various modifier keys with a click on the icon in the Dock. The only thing that I have found is that a command-click on the Dock icon opens a Finder window showing the contents of the folder’s enclosing (parent) folder. But that’s not what I am looking for. What I am looking for is a truly simple way to open the folder itself in a Finder window (not its parent folder), which apparently only the “Open in Finder” command can do (with the above-described problems).

(To be more accurate, command-click shows the contents of the parent folder when the window is in list view. When the window is in column view, both the contents of the parent folder and the contents of the folder are visible, because the folder itself is selected in the parent folder’s column, and the next column shows its contents. What I would like is a simple shortcut that shows me the contents of the actual folder in list view, not of the parent folder.)

The only other thing that I have found is the “Show in Finder” command that appears at the bottom of the menu when you control-click (right-click) on the Dock icon:

This command is worded differently, because it does not do the same thing as the “Open in Finder” command in the other menu. Unlike “Open in Finder,” “Show in Finder” works the same way as the command-click shortcut, i.e. it reveals the folder in its parent folder. (In other words, it opens the parent folder, and then highlights the folder in question by selecting it.) This command is always visible by default when you control-click on the Dock icon, i.e. you don’t have to manually reveal it by moving your mouse pointer over a triangle. When using the list view mode in the Finder, however, it still opens the enclosing folder, which makes it less useful than the proper “Open in Finder” command.

I simply don’t understand why the “Open in Finder” command has to be hidden by default below the bottom of the menu when bringing up the regular hierarchical menu.

And I also believe that we should be able to use a simple shortcut to reveal the contents of the folder in a Finder window in list view without having to navigate the parent folder. The command-click shortcut should probably be kept for “Show in Finder” because that’s what the Command modifier key is used for in a variety of contexts (to reveal a Spotlight search result in its enclosing folder, for example). But maybe command-shift-click could be used here.

The bottom line here is that, in their apparent obsession with this new fancy “stacks” feature that is actually far from innovative, Apple’s engineers have failed to preserve the most basic level of usability for Mac users who happen to find the new fan or grid display modes far from useful. And it is quite careless of them indeed.

When I use Spotlight in Mac OS X 10.5 (Leopard), I find myself constantly having to resize columns in order to be able to read the file names of my search results properly. Why is this happening?

The reason is pretty simple. There are two ways to initiate a Spotlight search in Mac OS X 10.5: you can either open a new Finder window (or use an existing Finder window) and type a search request in its “Search” field in the toolbar:

or you can use the global Spotlight menu in the top-right corner of the menu bar:

The Spotlight menu itself, however, only shows you a subset of the total list of search results, so if you want to view the full results of your search, you need to use the “Show All” option in the menu:

which opens a new Finder window showing the full list of results.

In both cases, you end up with a Finder window showing a complete list of the results of your search. Sadly, this Finder window looks like a regular Finder window, but it does not behave like a regular Finder window. It has no view options (so you cannot choose which columns you want to see) and suffers from some enduring bugs and flaws that don’t affect other Finder windows. But it’s a Finder window.

The option you chose to initiate the search, however, has a significant impact on the way that search results are presented in the resulting Finder window.

If you choose to start your search from a Finder window, then Mac OS X will use the current width of that Finder window as the basis to calculate the default width of the three columns for the display of the search results (“Name,” “Kind,” and “Last Opened”), which means that, the wider your original Finder window was, the wider the three columns in the results window will be.

If you choose to start your search from the global Spotlight menu, on the other hand, and then use the “Show All” option to view the full list of results in a Finder window, Mac OS X will always show the full list of results in a new Finder window with the same default size, and this size will always be… 750 x 460 pixels.

Because of the limited width of this default window size and the need to display four columns of stuff within that width (the sidebar on the left, and then the three columns for the list of results), you always end up with a “Name” column that is far too narrow to display most file names in full. So you end up with a list of mostly truncated file names:

Unfortunately, resizing the Finder window in question does not help. It increases the overall width of the window, but not the width of the columns. You just end up with useless empty space on the right hand side. You then have to manually adjust the width of the “Name” column in order to be able to see most names in full—and you have to do this each and every time you start a new Spotlight search through the global Spotlight menu and then choose the “Show All” option to view all the results in a Finder window. Because the control for resizing the “Name” column is pretty small (it’s the small line separator between the “Name” column and the “Kind” column), this is an adjustment that takes a non-negligible amount of effort, and having to repeat it again and again throughout the day is no fun at all.

My main screen is a 30″ monitor. This means that I have more than enough screen real estate to use a default window size for the Spotlight search results window that is twice as big as this 750 x 460 window. But there is no way to adjust Mac OS X’s default behaviour. Apple’s engineers have chosen this default 750 x 460 size, and there’s nothing you or I can do about it.

They undoubtedly chose this particular window size as some kind of compromise but, as with all compromises, the risk is that it is a compromise that attempts to please everyone and ends up pleasing no one. It certainly does not please me.

There are other aspects of the Finder interface where Apple’s engineers have made at least some semblance of an effort to adjust to the user’s preferences by making the Finder “remember” the last window size used. For example, if you create a new window in the Finder, then resize that window and close it, the next new window that you will create will have the size that you’ve just defined.

No such luck with the Spotlight results window in the Finder, however. All the effort put into resizing the window and adjusting its columns’ widths is forgotten as soon as you close the window, and you have to start all over again each time you use the global Spotlight menu to bring up a Finder window with a list of Spotlight results.

Of course, the “workaround” here is to avoid the global Spotlight menu altogether and always start a Spotlight search using an existing Finder window in the Finder. But that is not a user-friendly approach, and the command-Space shortcut is just too easy not to use. In addition, when you start a new Spotlight search, you don’t always know in advance whether you’ll need to use the “Show All” option or not. Sometimes the subset of search results that appears in the Spotlight menu is good enough, and so you never have to show the full results in a Finder window, so the global Spotlight menu fulfills its role without too much inconvenience.

I don’t know enough about the underpinnings of Spotlight in Mac OS X to offer a definitive solution here. But it seems to me that some kind of behaviour where Mac OS X would “remember” the last window size and column widths used for a Finder window spawned by the global Spotlight menu would help alleviate this particular problem and enable each Mac OS X user to customize the behaviour of the global Spotlight menu without adding complexity to the Spotlight interface.

(Of course, I would also like Apple to give us more view options for the search results window, but that’s another story.)

It was somewhat disappointing that this was not a 12-0 victory, with such a gap in quality between the two sides. A half dozen goals was pretty a minimum requirement here, and shamefully Arsenal is now one of the very few sides in the league against which Derby has actually scored two goals in the same game.

But of course at this stage of the season, you cannot really draw too many conclusions. The Gunners obviously only took the game half seriously, and it is hard to blame them. What really does boggle the mind is why Paul Jewell actually elected to take the management job at Derby. I mean, based on this season’s evidence, they will struggle not to be relegated next year too. What on earth attracted Paul Jewell here? It really is quite mysterious.

There really is not much else to say. Adebayor got a deserved hat trick, which brings his goal tally for the season to 30. It’s too bad he suffered from a lull at a crucial time in the season. But then, the whole team did.

The questions about the Arsenal defence remain unanswered, and it is quite obvious that Arsène Wenger will need to make at least one purchase in that department in the summer, especially if, as suspected, Senderos is allowed to leave.

Third place is guaranteed. The goal now is to finish with 83 points. Whether that will be enough to move ahead of one of the two top teams is highly questionable. We will obviously know more about this by kick-off time on Sunday. Until then, we are all spectators, and of course most Arsenal fans will probably be Barcelona supporters today.

It might have been dramatic, but it sure wasn’t pretty. In fact, it really was quite an ugly spectacle.

As a die-hard Arsenal fan, I cannot really claim to be a “neutral.” But the truth is that I dislike both Manchester United and Chelsea almost equally, and much for the same reasons. I can tolerate Manchester United a bit more sometimes, because they do play attractive football at times, but I cannot stand the attitude of players like Rooney and Ronaldo (and van Nistelrooy before them, and Scholes, etc.).

Ronaldo is just so full of himself that it is painful to watch (except of course when he screws up gloriously, as in the missed penalty in mid-week at Barcelona), and Rooney is just a foul-mouthed, foul-tempered twit who happens to have good feet.

That said, in terms of being dislikable, Chelsea probably win the contest, as today’s game proved once again. And nobody does dislikable quite like Didier Drogba. Today’s game could easily have been titled “The Didier Drogba Drama Queen Show.”

It started with Vidic’s injury. Yes, it was probably accidental, and yes, Drogba did display some concern about the well-being of the player after the collision. But did you watch that slow motion replay carefully? Did you see how, immediately after colliding with Vidic’s head, Drogba’s immediate, instinctive reaction was to crumble to the ground in seemingly excruciating pain? It is only once he realized that what had hit his own precious knee was actually Vidic’s face that he corrected his reaction and decided that, after all, his knee didn’t hurt all that much and probably was not injured!

I don’t believe that, in the whole history of football worldwide since the very invention of the game, there can have been a single incident where any player got his knee injured through a collision with another player’s head. I think it is physically quite impossible, that even the toughest jaw or skull is simply no match for an elbow, let alone a knee. Yet Drogba’s instinct was quite obviously to try and make everyone believe that it was possible—until he realized how ridiculous it was. It just says so much about his attitude. As soon as anyone touches any part of his precious body ever so slightly, it has to be a foul, and he has to act like he’s seriously injured. It’s sad, just sad.

Then of course there was the whole Ballack/Drogba subplot. How embarrassing can it be to everyone involved with the club and to the team’s supporters to have the whole wide world witness such a spectacle on the pitch? There are of course big egos in English football these days, and there is a history of ugly confrontations between players from the same team in recent years. I distinctly remember the scene between Bowyer and Dyer at Newcastle a couple of seasons ago, and of course I am not forgetting the confrontation between Adebayor and Bendtner at Tottenham earlier this year.

But this one surely is the most high profile and the most embarrassing of the whole lot. And who else but Didier Drogba to be at the centre of it? How can any neutral spectator have any empathy for the “big family” at Chelsea after witnessing such scenes?

The bottom-line, however, is that they did win, and are now level on points with Manchester United. The Red Devils are still guaranteed to win the title if they win their two remaining games, because of their superior goal difference, but they cannot afford any kind of slip-up. It certainly puts more pressure on them, which they did not need ahead of the return leg of the Champions’ League.

It also means that mathematically, if Arsenal win at Derby on Monday, they still won’t be out of the race. There is of course, no realistic chance of both Chelsea and Manchester United slipping up in a major way in their remaining fixtures, but there still has to be some motivation to finish with the highest possible number of points, if only to prove that the Gunners really went pretty close this year.

Certainly, on the evidence of today’s game at Stamford Bridge, there is no gulf in ability between Arsenal and Chelsea and Manchester United. The football played today—to the extent that any football was played, which is debatable—was really not impressive. It’s just highly unfortunate that the Gunners went through that bad patch after the Birmingham disaster and didn’t recover from it quickly enough. It was a very fine line between success and defeat (or, in that particular case, a succession of draws leading to defeat), and the Gunners ended up on the wrong side of it this year.

But I didn’t see anything today that convinces me that these other two teams were indeed better and “deserved” it more. They are just more adept at turning a footballing contest into big drama, with a stomach-churning blend of bullying, cynicism, theatrics, and referee abuse. If that’s what it takes to be champions this year, then the Gunners should have no regrets, and they should only hope that they can redress the situation by winning with stylish and quality football in the next contest.

Apple’s word processor Pages comes with some basic functionality for inserting an automatic date in a document. When you are composing a document, just go to the “Insert” menu and choose the “Date & Time” command.

This will insert the current date in a default (long date) format:

It looks like regular text, but it actually cannot be edited. If you click anywhere on it, Pages selects the entire thing, and if you double-click on it, you get access to a small floating thing that provides further options:

In this little floating thing, you can use the “Choose Date Format” menu to select other date formats:

The list of available date format options, however, is still limited. What if, for example, you’d like an automatic date in the universal “yyyy-mm-dd” format (as in “2008-04-25”)?

As you can see from the picture above, this particular date format is not part of the list of options. But this is where tight integration with Mac OS X’s underlying standards becomes important. See, the date format options provided in the floating thing above are actually based on the date format options defined in the “International” preference pane in System Preferences:

And the good news is that these date format options can be customized there. The “Customize…” button gives you access to a dialog sheet where you customize four different default values for the date format: “Short,” “Medium,” “Long,” and “Full”:

In the example below, I have customized the “Short” value and replaced it with the universal “yyyy-mm-dd” format:

(As this particular screen shot indicates, in order to get the number of the day with two digits, I just inserted the “Day of Month” control and then used the contextual menu to change from the default single-digit value to the two-digit value. You can do the same for the “Month” control in order to get the number of the month with two digits instead of the name of the month.)

Once this customization is done, I can return to Pages and double-click again on my automatic date, and now the options in the “Choose Date Format” menu have changed:

Et voilà! I can now insert an automatic date with the universal “yyyy-mm-dd” format in my Pages documents.

Sadly, Pages’s automatic date feature suffers from some frustrating limitations nonetheless. The major one for me is the fact that it is a unilingual feature, even though Pages itself is multilingual and lets you compose documents in a variety of languages.

This means that, regardless of which language your Pages document is in, the date inserted by Pages’s “Insert > Date & Time” command will be in the language-specific format selected in the “International” preference pane.

Since the majority of my documents are in Canadian French, I use the “French (Canada)” region in the “International” preference pane. Here are the four default values for the “Full,” “Long,”, “Medium,” and “Short” format options for the “French (Canada)” region:

As you can see, the “Medium” and “Short” values are exactly the same, which is pretty useless. This means that I can customize the “Medium” one to use the universal “yyyy-mm-dd” format mentioned above:

And I very much need this, because when I compose documents in Pages in English, the “yyyy-mm-dd” date format is pretty much the only acceptable one in English. Otherwise, I have no choice but to enter my dates manually in English, which means that there is no automatic updating—a particularly frustrating limitation when using dates in document templates.

Of course, in order to circumvent this limitation, Pages would have to break free of its total dependence on the “International” preference pane settings. It would have to provide its own preference settings for language-specific date formats, and that would undoubtedly add to the complexity of the feature. But I am afraid that, in a multilingual world, there is no other solution, and if Pages claims to be a multilingual word processor, then it needs to go all the way and provide multilingual options for dates as well.

The current situation might be acceptable to the majority of users who only ever use a single set of date, time and number formats—the one for their mother tongue. But it penalizes users who regularly switch from one language to another and, while these users might not be the majority, there are still quite a few of them, and not just in Canada.

(The same restrictions, of course, apply to automatic number formats in tables in Pages, Numbers and Keynote. Here again, it is impossible to use the applications’ automatic number formatting features in any language other than the one selected in the “International” preference pane.)

In conclusion and as a comparison, I was going to mention Microsoft Word’s own multilingual features. It used to be that Word was smart enough to change the date format used depending on the language setting for the underlying text. And indeed if I open old templates that I had defined in previous versions of Word, I can still find automatic dates in an English format in those templates that are in English. But when I try to insert a new automatic date in Word 2008, I now get the same limitations as in Pages, i.e. only it inserts the automatic date with the format options defined in the “International” preference pane, regardless of what the current language setting for the text is in the Word document.

So it looks like Word 2008 has been crippled in that respect compared to previous versions. Since I profoundly loathe Microsoft Word and use it as little as possible, I am not going to bother to try experiment to see if I can reproduce the language-specific date formats that I used to be able to achieve in previous versions. But if Word 2008 is indeed crippled, it is yet another reason to give up on Microsoft and switch to Pages. Word 2008 still has more flexibility than Pages (for example, it has separate field codes for print dates, which are dates that are only updated when the document is printed), but for all we know Microsoft’s MacBU is just as likely to further cripple the next version of Word and remove that functionality as well.

The real conclusion here is that Pages, while it is still somewhat limited in what it can do in terms of automatic dates, does provide a number of options, with further customization possible through the “International” preference pane in System Preferences.

A plain-vanilla 5,000-word document in Normal view (it’s called “Draft View” now), at a 100% zoom setting. Absolutely no formatting whatsoever. No tables. No graphics. Just plain text, in Times New Roman 12 point (a Microsoft TrueType font), left-aligned. It does not get much more basic than that, does it?

Yet apparently that is still enough to cause Microsoft Word 2008 to misbehave. Here’s the proof:

Here’s another sample, at 150%:

And exactly what horrible abuse of computing machinery did I commit in order to achieve such catastrophic text rendering?

I scrolled up and down the document.

Wow.

Good job, Microsoft. Once again, you have exceeded all expectations. This is really fantastic engineering. Remind me again… How much did I pay for this crap?

An absolute bargain.

Speaking of editing text in tables in Word, like previous versions of the application, Word 2008 suffers from a really irritating behaviour when you are typing text in a table cell in Print Layout View.

When in Print Layout View, as soon as you place your insertion point anywhere inside a table, Word displays this small proxy icon in the top-left corner of the table:

This little control is meant to be used for selecting the table and moving it around on the page.

The trouble is that, as soon as you start typing text inside a table cell, this control starts constantly flickering on and off. It’s a purely visual glitch and has no impact on the usability of the Print Layout View or the control itself (it stops flickering when you stop typing), but I find this flickering highly irritating and distracting.

And it serves as a constant reminder that Microsoft is unable to produce quality software with enough polish to qualify as real Mac OS X software.

Sure, there are many more important bugs to fix first. But the trouble with Microsoft is that there are also hundreds of such less important bugs, and Microsoft’s engineers simply never get around to fixing them—which means that we have to live with them for years, and cannot help but feel that Microsoft will never be able to achieve high enough levels of quality in their products.

As if unfortunately typical with Microsoft products, not only does the newest version of Word bring no real improvements, but it also introduces a whole slew of new bugs and performance problems that will take years to get fixed—if they ever get fixed.

In Word 2008, Microsoft has reshuffled and renamed its various view modes (which are still far too numerous), and the venerable Page Layout view mode is now called Print Layout View.

Whether this has anything to do with the new bugs it introduces, I do not know. But here’s a fairly simple example of an utterly annoying problem that, as far as I can remember, did not occur in previous versions of Word.

I often have to work with Word documents containing large tables, and sometimes these tables have rows that too big to fit on a single page. If the table has the option to “allow rows to break across pages,” then such rows can be broken in two by an automatic page break, and you get something that looks like this:

No problems here. But now consider what happens when I try to copy the selected text in the picture above and paste it into another column in the same table.

Here’s the second column of the table before I paste the additional text:

Again, no problems here. But now see what happens when I paste the copied text at the insertion point, which is near the bottom of the page:

Great. Word inserts the copied text in the table cell on the first page, but completely fails to refresh the display of the continuation of the same table row on the second page. This makes it look as if I only pasted part of the text, and the rest of the clipboard has disappeared into the ether, along with the last portion of the text before the Paste command at the bottom of the cell on the first page!

In fact the Paste operation has worked just fine. It is just that Microsoft’s engineers have failed to ensure that the display of the continuing table row on the second page would be automatically refreshed.

And getting Word to refresh its display is not just a matter of scrolling up and down the document either. I tried this again and again, and still Word would not refresh the display of the second page.

I inserted my cursor at the bottom of the first page and used the cursor keys to navigate to the “invisible” part of the pasted text, and then I started typing something else “in the dark.” And then finally Word woke up and remembered that it actually had to refresh the display of the table on the second page and I finally was able to see my pasted text in full:

But really, this kind of shoddy work is completely unacceptable. It is yet another illustration of the utter lack of professionalism at the MacBU, which releases products that are clearly full of bugs and gleefully charges users hundreds of dollars for them.

I know, I know, it’s nothing new. But sometimes a visual illustration of just how bad Microsoft’s products are can be a useful reminder of the level of incompetence and carelessness of Redmond’s Mac engineers.

Here’s a Word document that was authored on a PC and that I tried to open on my Mac with Microsoft Word 2008:

And here’s the exact same document when I opened it with Apple’s Pages 3:

Pretty sad, isn’t it? Microsoft’s own software engineers are unable to ensure a sufficient level of cross-platform compatibility, and Apple’s engineers, on their own, probably with no help from Microsoft whatsoever, are able to provide better compatibility with Word for Windows documents than Microsoft Word 2008 does.

Then again, when I try to open the same document with Word XP (Word 2002) in Windows XP under Parallels, I systematically get an application crash, so I am not even able to open it and edit it there. So clearly Microsoft’s engineers are just as careless about cross-version compatibility on the Windows side. I suppose Microsoft expects me to purchase Vista and Office 2007 just to be able to maintain compatibility…

Now, of course, this is just one particular file. I don’t have a lab of full-time technicians to test thousands of Word for Windows files in order to determine their relative compatibility with Word 2008 and with Pages 3 respectively on the Mac.

And it is also true that, for some types of Word documents, Pages has many compatibility problems—especially Word documents with “fancy” layouts making heavy use of text frame objects or whatever these things are called in the Word interface. These text frame objects have been prettified in Word 2008 compared to previous versions of Word for the Mac, but they are still extremely painful to use and atrociously designed and handled, so I certainly don’t blame Apple’s engineers for not even attempting to preserve “fancy” layouts in Word documents that make heavy use of text frames. It’s a nightmare just to use them in Word, so I cannot even imagine how difficult it must be to support them properly when converting Word documents to the Pages format. But this limitation in Pages’s compatibility with Word documents unfortunately means that I still have to use Word from time to time, for certain documents.

Still, my experience with Word for Windows documents is that, apart from documents with text frame objects, when I open these documents in Pages, I get results that are just as good, and often better, than what I get when opening these same documents in Microsoft’s own Word 2008. The above example illustrates this quite clearly. And it reflects the sad reality that Word 2008 is, well, yet another piece of Microsoft crap.

Out of curiosity, I tried to determine what type of image file it was that was causing the above problem in Word 2008. This is not easy to do, however, as neither Word 2008 nor Pages 3 provides any tools for identifying the type of picture file that was originally used to insert a picture in the document.

It is also impossible to just drag the picture from the document to the desktop to get the original file, like you can do with most pictures on web pages.

And when I try to copy the picture to the Clipboard and then paste it in another application, I get varying results. When I switch to Preview and create a new file, it automatically creates a new file based on the Clipboard, and that file is a PDF containing the logo in question, but I am not sure that this means anything about the actual format of the original picture file.

When I paste the Clipboard into a new Photoshop file, I get a layer called “Vector Smart Object,” with a low-res preview of the picture in black and white used as a some sort of background with an “X” across it, so that doesn’t really tell me anything either.

So basically I still don’t know whether this particular logo was a JPEG, a GIF, a BMP, a TIFF, a PNG, a PDF, or something else. But whatever it was, it was something that Pages was able to handle properly, whereas Microsoft’s own Word 2008 was not. And I also have no way of checking what happens to the picture after I edit the Word file in Word 2008 and return it to its author, because I cannot open it in Word XP. I just hope that somehow the picture is preserved and still looks OK in the returned file. But this means, as usual, that I am penalized for being a Mac user, and running the risk of delivering damaged documents to my PC-using colleagues, which can impact me negatively in my work and how it is perceived by my colleagues. All thanks to Microsoft.

It was, unfortunately, the kind of routine league victory that has been missing so much in the past couple of months. It’s good to see the team return to winning ways, in style, but of course it is far too late now.

Manchester United might have dropped two points, but it’s a two-horse race between them and Chelsea now. The big clash at Stamford Bridge on Saturday will be crucial, but Arsenal fans will be watching it as neutrals, because the result will have no impact on the outcome of their own season. One can always dream of Manchester United losing their remaining three games and Chelsea losing their other two games, but it’s about as likely as lightning hitting Wayne Rooney and turning him into a beautiful frog.

It’s really too bad, because three more victories is definitely a possibility for the Gunners, which would mean finishing with a grand total of 83 points—a huge improvement over the last two seasons, but one that won’t count for anything except for a psychological boost at the beginning of the next season.

Still, even this comfortable 2-0 victory against relegation-threatened Reading couldn’t mask the fact that this Arsenal team still has trouble finishing off the opposition. What we really need is a string of more emphatic victories that reassert the Gunners’ superiority in an unequivocal fashion. And of course we need all the current players to stay at the club.

I was going to add “except for Éboué,” except that, shockingly enough, when Éboué came on on Saturday for the injured Touré at right-back, he actually had a pretty good game. Of course, it doesn’t mean much in a game like this, but it really made it look like this “Éboué as a winger” thing—which has been a bit of a nightmare, to be honest—had actually never happened in the first place. Does this mean we could use Éboué against as a right-back ahead of Sagna? No way. But maybe we could keep him as a capable substitute…

OK, maybe not.