Date: Wed, 07 Jan 2004 02:04:34 -0800
From: <###@###.###>
Subject: Font.decode(String) is backwards-incompatible and still broken
To: ###@###.###
Reply-to: <###@###.###>

The new parsing algorithm used by Font.decode() is going to break
a lot of existing code, for no good reason. In addition to
deliberately disallowing formats that have always been accepted,
it can fail to parse well-formed input in which spaces, rather
than hyphens, are used as field delimiters. For instance, when
passed the string

    "Lucida Sans Unicode ITALIC 16"

it reads the family name as simply "Lucida", because it
mindlessly treats the first space as the end of the first field.
It then tries to interpret "Sans" as a style name and "Unicode
ITALIC 16" as a point size, and ends up using the default values
for all three properties. There is no sanity checking at all.

Also, I think it's a bad idea to cut off support for the "non-
spec" formats. The "<familyname>-<pointsize>" format, in
particular, is probably widely used, because it's so intuitive.
Instead, the spec should be rewritten to clearly state that
either the style or the point-size, or both, can be left out, and
default values will be used (that's how I've always read it).

By employing some simple lexical analysis, you should be able to
do a better job of parsing than you are now (or were before), and
still support those (formerly) illegal formats. After all, this
is a method that never returns null or throws an exception--it
has to do the best it can with whatever input it receives. Not
even trying to do what the user meant, especially when it used to
do so, just comes across as churlish.