|
Quick Lists
|
|
Bug ID:
|
4075967
|
|
Votes
|
2
|
|
Synopsis
|
Add-on Image Formats
|
|
Category
|
java:classes_2d
|
|
Reported Against
|
1.1.2
|
|
Release Fixed
|
|
|
State
|
11-Closed, duplicate of 4101949,
request for enhancement
|
|
Priority:
|
5-Very Low
|
|
Related Bugs
|
4101949
|
|
Submit Date
|
02-SEP-1997
|
|
Description
|
There isn't a standard way to teach the system
about new image formats. The 'natural' way of
doing so would be to define an 'imageFormat'
interface, which would have a 'getImage' method
accepting a URL. If the URL is recognized by the
imageFormat (by using the file prefix or any other
criteria), it would return an Image customer ;
otherwise null. given a registerImageFormat
method, getImage could just loop on the available
formats and return the first one which claims the
URL.
Variants would be to allow the imageFormat to
examine the first few bytes of the file; or,
alternatively, have each imageFormat provide a
getFilePrefix method and have getImage use this
exclusively to decide which imageFormat to use.
======================================================================
|
|
Work Around
|
We're trying to set up a system which would deal
with a lot of image files from many sources. We'd
like to allow our users to support such formats,
and to be able to use formats which would become
available in the future. Given the current state
of affairs, we are forced to add each new format
by manually adapting the system to the new
drivers. The feature described above would allow
format vendors to package their drivers so that
no additional coding would be requires, and in
fact the users would be able to just "drop in"
the new format, just like they can add JavaBeans
to an application generator.
======================================================================
|
|
Evaluation
|
N/A
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |