FlexibleFactory

After saying yesterday that Silverlight 3 has Cleartype, I must now point out that while this is true, after looking at a few samples today, as well as this font rendering comparison, the quality of rendering is not on a par with the standard Windows Cleartype that we are used to. (winforms text in the link above)

This is really disappointing. While its a significant improvement over 2.0, it still has that fuzzy, projected look to it, that to me, and others makes applications feel ‘foreign’ or even ‘fake.’

In the Flash world, we suffered terrible text rendering until the introduction of Saffron a few years ago, which is actually rather good, and although not native, has a crisp and even feel to it.

I honestly think that the lack of native widgets and text rendering has been a major barrier to the psychological acceptance of Flash/Silverlight/Java based applications as ‘real’. Remember the clunky old Swing components, and how they made you feel that ‘this is not the real thing’.

Of course, if it’s even better than ‘the real thing’ that’s great, but the difficulty of achieving this with a one-size fits all approach should not be underestimated.

As children, we learn to distinguish toys from real tools by their appearance, and this may account for the lack of credibility that non-native (looking) applications have. An enormous effort has been made to get native UI into Java, so I can’t be the only one who thinks this. However, I certainly don’t agree with Jeff’s preference for IE7, a program that, to me, is an abomination, and only exists to test the patience of web developers.

A couple of years ago I had the dubious pleasure of working with WSSE and the as3corelib library which implements some of the required functionality for communicating with WSSE enhanced web services in AS3. I was accessing a .NET application which exposed such web services and ‘consuming’ them with Flex. After hacking the code in this library a little so that it actually did what I needed (generating WSSE security headers for the SOAP messages), it turned out something was very much amiss. All the data getting sent looked good, but requests were rejected with an ‘InvalidSecurityToken’ or somesuch exception. After a lot of detective work, it turned out that this bug was squarely to blame.

In getUsernameToken, the nonce is base64-encoded. This encoded value is
then used in determining the password digest. This is not according to the
WS-Security UsernameToken specification: the password digest is based on
the unencoded nonce value.

from http://code.google.com/p/as3corelib/issues/detail?id=25

Now the fix for this is truly trivial, moving a single line of code in getUsernameToken , however I would forgive anyone facing this problem for simply giving up, the problem is so obscure (and unlikely).

Corrected code
var password64:String = getBase64Digest(nonce, created, password);
nonce = base64Encode(nonce);

Original incorrect code
nonce = base64Encode(nonce);
var password64:String = getBase64Digest(nonce,created,password);

TWO YEARS have passed since this bug was reported. It’s status is still ‘New’. It still doesn’t even have an owner. There is a patch for it though, which was submitted more than six months ago now, but still not has found its way into the trunk.

I bring this up now because I recently had the pleasure of sharing this esoteric information with another developer who was facing similar issues.

The thing is, how did this code ever end up being published? It is simply wrong. Have any of the orginal developers actually tested this code against a real implementation of WSSE? I don’t see how it could ever have worked, or how it ended up being published, and with the fix yet to be rolled into the trunk, every developer who has ever called the getUsernameToken method must be scratching their head.

Of course, I know that bugs can and do find their way into release software, it’s a fact of life. Hey, maybe it was a slip of the mouse at the last minute But show stopping bugs that are still there two years after they are reported, I cannot understand.

If you ever work with this library, do read http://code.google.com/p/as3corelib/issues/list because other issues that may also impact on WSSE also have fixes attached there.

As a long time Flash/.NET programmer, Silverlight has always been of interest to me. However, apart from a little pong game we made when it was still WPFE, I’ve never taken the trouble to delve into this new tech too deeply. The main reason has always been that these things tend to be both frustrating and disappointing in their first couple of years of life. APIs change and break your code, and essential features are broken or missing. All in all, developing with a mature platform is much more satisfying and rewarding.

For Silverlight, it was the lack of support for dynamic bitmaps, and the appallingly bad font rendering that screamed ‘Not ready!’ through versions 1 and 2. The look of the text reminded me of Linux windowing systems before they recently got their act together.

In fact, the font rendering was so bad that it sparked discussions such as this and this.

People did come up with some ingenious hacks for the bitmap problem, but really you don’t want to have to do this sort of thing. And as this quote from the Silverlight forums sums up, crappy font rendering is not an option if Silverlight is ever going to compete with Flash.

Fonts look like crap in Silverlight. Doesn’t matter what font I use, if I embed it or what, they look like crap. Even companies like DevExpress, Telerik and Componentone’s samples for their new controls look like crap because of the fonts.

This is just imbarrassingly bad. Is there a way to make them look like they should? Is this going to be fixed?

It sure should be fixed for the final version, cause otherwise Adobe and company are going to laugh you out of the room.

Geminiman

Fortunately MS appears to have understood the concerns here and Silverlight 3 has Cleartype as well as WritableBitmap

Looks like old Silverpants is starting to get with the program. Maybe I should too.

I like to keep my PC in good working condition. This means limiting the number of startup items and shell menu items that invariably sneak onto one’s PC when installing software from less reputable manufacturers.

If I want a toolbar, I’ll install it, thanks. If I want extra shell items hooked into my rightclick menus, I’d like to ask for them. I certainly don’t want some management buffoon deciding that the best way to up the number of installs of their pet project is by sneaking it in like a trojan on the back of some other product.

I installed the trial version of Illustrator the other day on my PC. Now I have something called AdobeDriveCS4 appearing in my right-click Explorer menus. I don’t want it. I didn’t ask for it. Adobe didn’t tell me it was going to be installed and now it’s there slowing down my machine. No worries… I’ll just uninstall it, right? Nope, there’s no uninstaller available, nor do Adobe publicise how one might get rid of this sneaky trojan.

The thing is, I’d quite like to carry on using Illustrator, and I don’t even know if uninstalling it will get rid of the parasite programs that hide within its monster 1GB (1GB???) installer.

Adobe… this sucks. The public decided a long long time ago that this is a bad idea. How long will it take for your management to catch up with us?

I’ll certainly think twice before I absent mindedly install any other Adobe products.

For the record:

Windows 64bit removal

regsvr32 /u "C:\Program Files (x86)\Common Files\Adobe\Adobe Drive CS4\ADFSMenu.dll"

Windows 32bit removal

regsvr32 /u "C:\Program Files\Common Files\Adobe\Adobe Drive CS4\ADFSMenu.dll"

Let’s have a page telling this, or even better the option not to install it in the first place. Adobe, if you really, really must install such crap then at least have the decency to provide an uninstaller.

The pity is, I don’t even know what Drive CS4 is. Now I guess I never will.