wxHaskell: Scaling a Bitmap Image

I ran into this page while trying to figure out how to scale a bitmap image from within wxHaskell. The solution posted by the OP there scales the drawing context (e.g., the canvas) and not the bitmap itself.

To scale the bitmap itself, just do it like this:

import Graphics.UI.WX
import Graphics.UI.WXCore

scaleBitmap ... = do
    imgScaled <- imageConvertToBitmap =<< imageScale img (sz newWidth newHeight)
    -- do stuff with imgScaled; e.g., draw it somewhere with drawBitmap
    bitmapDelete imgScaled
    where
        img = image "foo.bmp"
        newWidth = 100
        newHeight = 20

The key is to load up the bitmap with the generic image function, and not the usual bitmap function. This way, you can make use of the imageScale function to scale your image, and then you can convert it back again to bitmap format with imageConvertToBitmap. Finally, when we are done with drawing this image somewhere, we free the memory used up to create the bitmap version of it, by calling bitmapDelete. A bit clunky, but simple enough. I tested it with a Windows BMP with an alpha channel and it worked quite nicely.

By the way, wxHaskell is very easy to learn — you just need to skim Daan Leijen’s paper whenever you get stuck. (Leijen also wrote the beautifully powerful Parsec library — another library I enjoyed using once I got the hang of it.)

Advertisements

Website Passwords: A Big Mess

TL;DR: You will inevitably be screwed when you try to change your website passwords.

So a few months ago, I changed all of my website passwords. I used a simple pseudorandom ASCII-only character generator to ensure the uniqueness of each one. In the process, I discovered that many websites have horrible, broken password interfaces.

This post is mainly a rant. Setting and changing passwords should never be difficult, and should be 100% transparent. We end users probably collectively wasted millions of hours with broken password interfaces, and will waste millions more until the issues below are addressed each time someone deploys a new website.

Special Characters

Many websites tell you a list of special characters that are not allowed in passwords. Sadly, this list is often incomplete. Worse still, some only accept alphanumeric passwords, but are silent as to this restriction — and to top it off, they don’t even bother to tell you why your chosen password is invalid! The gall.

It appears that the restriction against special characters is largely a matter of legacy vs. modern platforms. Newer websites like Wikipedia allow you to choose any character from a US ASCII keyboard. Many older institutions (Bank of America, for example) have very strange special character restrictions, which almost seem arbitrary (did you know that Bank of America calls passwords “passcodes”?).

What needs to be done: At a minimum, allow input of ALL characters from a US ASCII keyboard ([a-zA-Z0-9] and all punctuation characters and spaces (tabs are impossible to type into a text field in some browsers, so they can be excused)).

Password Length

This is the biggest problem. For roughly 1/2 of my website passwords, they have a maximum character limit. Some even enforce a 12-character limit (socalgas.com is one example). Some enforce a 16-character limit (bugs.freedesktop.org, login.live.com). Barnesandnoble.com has a 15-character limit (no space s allowed, alphanumeric only).

But the best part is this: many of these sites do not tell you about this limit. So, you can spend 5, 10 minutes thinking out a great mnemonic device for a fantastic password, and you’ll get hit with some “Invalid Password” error. Yet another well-meaning user slapped in the face.

Many sites are fixated on only preventing 3, 4 character passwords by implementing an interactive “password strength” meter that rejects short passwords. But they still fail to tell you that your password is too long.

EDIT: Bela pointed out in the comments another common bug: the site will happily accept your chosen password, but will truncate it to a shorter length (without telling you any warnings about it, of course).

What needs to be done: Explicitly tell the user exactly how many characters they may use, and if the password is too long, tell them about it.

Stupidity Award: access.enom.com

If you change your password at this site, be extremely careful: DO NOT choose a password that is more than 30 characters long. When I changed my password to a 50-character long password, it happily accepted it. Unfortunately, the actual log-in interface only lets you type in 30 characters long! Since access.enom.com has no contact information, you’ll have to call someone somewhere somehow to sort out this mess.

Realistic Outlook

Legacy systems are really, really hard to migrate out of. My prediction is that the stupid, broken web interfaces will continue to thrive for at least 20 years. Why? It’s because people in 2031 will still be using passwords that are around 10 characters long with mostly alphanumeric symbols. Sure, web standards will have evolved by that time, but human brains will still be the same. The steady flow of 10-character passwords by the overwhelming majority of users will ensure that legacy systems remain competitive, at least when it comes to dealing with passwords.

Hopefully, by 2111, we’ll have sane password interfaces for all websites. Perhaps it will become a web standard by then, enforced by an international e-court, or some such.