Possible bug in PNGRenderer (when output file doesn't include an extension)

[Matt Healy <mj...@cs.rit.edu>]

Gentle folk -

I believe that I've stumbled across a bug in the PNGRenderer's 
'setOutputDirectory' method.  If the user has set an output file on the 
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.

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 mandate file extensions (e.g., OS X), this 
problem could come up, and it's reasonably easy to resolve.

I've got a patch (see the attached file), but I'm trying to be a "good 
citizen" and check with the list before I submit it through Bugzilla, as 
indicated on the FOP web site.  (I've already checked for this issue 
being previously reported, and I've been able to find no matching entries.)

Any comments/ideas?

Thanks!

-mjh
-- 
Matthew J. Healy
Department of Computer Science, RIT
102 Lomb Memorial Drive, Rochester, NY 14623
mailto:mjh@cs.rit.edu
http://www.cs.rit.edu/~mjh
Voice: (585) 248-3425

Re: Possible bug in PNGRenderer (when output file doesn't include an extension)

[Andreas L Delmelle <a_...@pandora.be>]

On Sep 29, 2006, at 22:19, Matt Healy wrote:

Hi Matt,

> I believe that I've stumbled across a bug in the PNGRenderer's  
> 'setOutputDirectory' method.  If the user has set an output file on  
> the 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.
>
> 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 mandate file extensions  
> (e.g., OS X), this problem could come up, and it's reasonably easy  
> to resolve.

Seems like a fine suggestion to me, however, there's still a (rather  
exceptional) case that won't be covered:
What if the user doesn't specify an extension, but uses a '.'  
elsewhere in the filename?

More waterproof may be to suppose that, if there is an extension, it  
will always be '.png' or '.PNG' (?)


Cheers,

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org