Thanks (and ++)! Just a few minor nits...

Does everything in the output xls file really have to be bold?

Given that you start out like this:

my $infile = shift;
usage()  unless defined $infile && -f $infile;
[download]

your usage synopsis really should be like this:

sub usage {
    print "csv2xls infile [outfile] [subject]\n";
    exit;
}
[download]

(i.e. no brackets around "infile", because it is a required arg)

When I saw this:

    # We store the string width as data in the Worksheet object. We us
+e
    # a double underscore key name to avoid conflicts with future name
+s.
    #
    my $old_width    = $worksheet->{__col_widths}->[$col];
[download]

I was reminded of having to face a similar issue with DBI; in that module, the handy convention is that any time you want to add some "novel" attributes (hash keys) to the "normal" module object, you simply prefix the attribute name with "private_" -- I don't remember all the circumstances that made this "the right way to do it" with DBI, but it seems like a nice convention to use in general.

BTW, doesn't Excel already support a simple means for importing data from a csv file? I can appreciate the notion of having column widths adjusted for me automatically as the data are loaded, but in most cases, adjusting the column width in Excel isn't that much harder. I also understand the issues with really long csv data sets and the need to split them up somehow to be digestible by Excel, but in those cases, I'd have to wonder: why use Excel at all for that kind of data?

As for the last chunk of your code:

# Very simple conversion between string length and string width for Ar
+ial 10.
# See below for a more sophisticated method.
#
sub string_width {

    return length $_[0];
}
[download]

Is that supposed to be a joke, or did you actually leave something off at the end when you posted this? (just curious)