Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4974890

REGRESSSION: Font.decode(String) is backwards-incompatible and still broken



    • Bug
    • Status: Closed
    • P2
    • Resolution: Duplicate
    • 5.0
    • None
    • client-libs
    • 2d
    • generic
    • solaris_8


      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.


        Issue Links



              prr Philip Race
              gafter Neal Gafter
              0 Vote for this issue
              0 Start watching this issue