Overview Description: 
If the user has set an output file on a user agent, but the file doesn't include
an extension, a StringIndexOutOfBoundsException is thrown when the PNGRenderer
attempts to deduce the "file prefix" to be used for the various pages, causing
the rendering attempt to fail unexpectedly.

The attached patch will allow a file name missing an extension to be used in its
entirety as the prefix for pages being rendered.


Steps to Reproduce: 

1) Create a FOPFactory object.
     FopFactory fopFactory = FopFactory.newInstance();

2) Create an FOUserAgent object.
     org.apache.fop.apps.FOUserAgent agent = fopFactory.newFOUserAgent();

3) Set the "output file" for the agent, making sure that the file name does not
include an extension.
     agent.setOutputFile( new java.io.File( "/var/tmp/ProjectSummaryReport" ) );

4) Create a Fop object, using the configured agent, and targeting PNG as the
output format.
     Fop fop = fopFactory.newFop( org.apache.fop.apps.MimeConstants.MIME_PNG, out );

5) Use the Fop object to try to render an FO document.

Actual Results: 

A StringIndexOutOfBoundsException is thrown when the PNGRenderer attempts to
deduce the "file prefix" to be used for the various pages, causing the rendering
attempt to fail unexpectedly.

Expected Results:

Either the renderer should accept the file name (e.g., "ProjectSummaryReport")
as the full prefix, or else it should throw an exception (probably IOException,
given the context) to indicate that an inappropriate output file has been
specified.  


Build Date & Platform: 

Subversion repository version 451762, on Mac OS X 10.4.7.  (29Sep06)

Additional Builds and Platforms: 

Issue also occurs under Solaris and Windows, and should presumably arise
anywhere this is attempted.


Additional information:

This isn't likely to be an issue under many circumstances, since users will
frequently specify the file name using an extension (e.g.,
"/Volumes/Stuff/ProjectReport.png"), but if the user is accustomed to working on
an OS that doesn't place as high a premium on file extensions (e.g., OS X) and
is using an existing file as the basis for the output being generated by the
renderer, this problem could come up. 

During discussion on the mailing list, Andreas Delmelle suggested that the
renderer should probably not accept alternate extensions (i.e., other than
".png").  This changes is also included in the attached patch.