You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thomas E Deweese <th...@kodak.com> on 2001/04/10 16:51:26 UTC
[Commit] ImageTagRegistry and friends
Commit message was too long. Interesting bits included here
---
Added: sources/org/apache/batik/ext/awt/image/codec PNGRed.java
sources/org/apache/batik/ext/awt/image/renderable
DeferRable.java RedRable.java
sources/org/apache/batik/ext/awt/image/spi
AbstractRegistryEntry.java ImageTagRegistry.java
JPEGRegistryEntry.java
MagicNumberRegistryEntry.java PNGRegistryEntry.java
RegistryEntry.java StreamRegistryEntry.java
URLRegistryEntry.java
sources/org/apache/batik/util Base64DecodeStream.java
Log:
1) PNGRed is a modified version of the PNGImageDecoder that uses our
AbstractRed as a base class (should let us get rid of some of the
redundant code that got pulled in to support the PNGImageDecoder
that is there currently).
2) DeferRable, RedRable. This is a split of RasterRable into it's two
logical components. 1) It acts as a defering proxy class (you
return a RasterRable before you are done constructing the
underlying RenderedImage in another thread).
2) It turns a RenderedImage into a RenderableImage by way of
the AffineRed class.
This is a much cleaner seperation, and means that eventually
RasterRable will proably go away.
3) spi/* This is a collection of interfaces that will become a service
provider interface, that people can use to extend the set of formats
handled by the image tag in Batik.
I have example usage of this interface for PNG and JPEG. These
are untested (other than compiling) but the logic should be sound.
4) Base64DecodeStream - this is a rewrite of the Base64Decoder that
acts as a filter on an InputStream. This will be the basis for
a 'data:' protocol handler that I will register with the URL class
(which means we won't have to 'tip toe' around the construction of
URL objects on the off chance that it's a 'data:' URL). This should
also then plug very cleanly into the registy mechanism.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
URL and 'data:' protocol - was Re: [Commit] ImageTagRegistry and friends
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "CJ" == Christophe Jolif <cj...@ilog.fr> writes:
CJ> Thomas, Thomas E Deweese wrote:
>> I was actually planning on using the 'java.protocol.handler.pkgs'
>> system property to register the protocol handler. This works
>> around the one URLStreamHandler registration issue. However, you
>> are correct about the Applet issue :(
>>
>> Well, I _really_ _really_ _really_ hate passing around URL's as
>> Strings. It's ugly nasty, and leads to lots of replicated code
>> that that tries to analyze this or that piece of the URL.
>> [...]
>> We can support constructing the 'odd' URLS through the
>> URL(URL context, String spec, URLStreamHandler handler) method
>> which should allow us to use any URLStreamHandler we decide we want
>> with no policy issues (we could also construct our own parallel URL
>> class, but we can't extend URL).
>>
>> Anyone have comments, better ideas (I hope!).
CJ> I totally agree with you, I really like the idea of using an
CJ> extended protocol on URL to deal with the data protocol instead of
CJ> making our own stuff.
CJ> However looking one more time at URL class documentation, it looks
CJ> like that we will come up with the same problem by using the
CJ> URL(ctx, spec, handler) ctor because it also throws a security
CJ> exception...
AAARRRGGG!!!
I don't even want to know why this might be a Security violation,
seems like it should be 100% safe (I mean it's one thing to magically
get someones implementation of a url stream handler, it's another
thing when I provide that handler in the constrcutor).
Anyway, I guess this pushes us to a parallel URL class. It's ugly
though since anytime we interface with external libraries that might
take a URL we will have to "do something". Where I haven't sorted out
what "something" is. :)
Better ideas? Please!
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [Commit] ImageTagRegistry and friends
Posted by Christophe Jolif <cj...@ilog.fr>.
Thomas,
Thomas E Deweese wrote:
> Hmm,
>
> I was actually planning on using the 'java.protocol.handler.pkgs'
> system property to register the protocol handler. This works around
> the one URLStreamHandler registration issue. However, you are correct
> about the Applet issue :(
>
> Well, I _really_ _really_ _really_ hate passing around URL's as
> Strings. It's ugly nasty, and leads to lots of replicated code that
> that tries to analyze this or that piece of the URL. So if we decide
> that we must support extended protocols (ie. 'data:') in an applet
> (probably) and no one else comes up with any good ideas, my suggestion
> would be the creation of:
>
> batik.util.URLFactory
>
> That provides essentially all the same constructor interfaces as
> URL as static methods but also allows for the extension stuff that we
> need. We can support constructing the 'odd' URLS through the URL(URL
> context, String spec, URLStreamHandler handler) method which should
> allow us to use any URLStreamHandler we decide we want with no policy
> issues (we could also construct our own parallel URL class, but we
> can't extend URL).
>
> Anyone have comments, better ideas (I hope!).
I totally agree with you, I really like the idea of using an extended
protocol on URL to deal with the data protocol instead of making our own
stuff. However looking one more time at URL class documentation, it
looks like that we will come up with the same problem by using the
URL(ctx, spec, handler) ctor because it also throws a security
exception...
--
Christophe
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [Commit] ImageTagRegistry and friends
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "CJ" == Christophe Jolif <cj...@ilog.fr> writes:
CJ> Thomas E Deweese wrote:
>> 4) Base64DecodeStream - this is a rewrite of the Base64Decoder that
>> acts as a filter on an InputStream. This will be the basis for a
>> 'data:' protocol handler that I will register with the URL class
>> (which means we won't have to 'tip toe' around the construction of
>> URL objects on the off chance that it's a 'data:' URL). This
>> should also then plug very cleanly into the registy mechanism.
CJ> I guess you are talking about registering on the URL class a new
CJ> URL handler factory? We discussed this recently with a colleague
CJ> at ILOG (I have an implementation doing this that way). The
CJ> discussion ended with discovering two problems:
CJ> - the JDK URL handler facorty registering mechanism will require
CJ> certain priviledges that will not be available in an applet
CJ> environment.
CJ> - Moreover an URL handler factory can be set only once and if
CJ> someone previously set his own you will not be able to supersede
CJ> it.
CJ> Looks like it could be a problem if we rely only on this?
Hmm,
I was actually planning on using the 'java.protocol.handler.pkgs'
system property to register the protocol handler. This works around
the one URLStreamHandler registration issue. However, you are correct
about the Applet issue :(
Well, I _really_ _really_ _really_ hate passing around URL's as
Strings. It's ugly nasty, and leads to lots of replicated code that
that tries to analyze this or that piece of the URL. So if we decide
that we must support extended protocols (ie. 'data:') in an applet
(probably) and no one else comes up with any good ideas, my suggestion
would be the creation of:
batik.util.URLFactory
That provides essentially all the same constructor interfaces as
URL as static methods but also allows for the extension stuff that we
need. We can support constructing the 'odd' URLS through the URL(URL
context, String spec, URLStreamHandler handler) method which should
allow us to use any URLStreamHandler we decide we want with no policy
issues (we could also construct our own parallel URL class, but we
can't extend URL).
Anyone have comments, better ideas (I hope!).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: [Commit] ImageTagRegistry and friends
Posted by Christophe Jolif <cj...@ilog.fr>.
Thomas,
Thomas E Deweese wrote:
> 4) Base64DecodeStream - this is a rewrite of the Base64Decoder that
> acts as a filter on an InputStream. This will be the basis for
> a 'data:' protocol handler that I will register with the URL class
> (which means we won't have to 'tip toe' around the construction of
> URL objects on the off chance that it's a 'data:' URL). This should
> also then plug very cleanly into the registy mechanism.
I guess you are talking about registering on the URL class a new URL
handler factory? We discussed this recently with a colleague at ILOG (I
have an implementation doing this that way). The discussion ended with
discovering two problems:
- the JDK URL handler facorty registering mechanism will require certain
priviledges that will not be available in an applet environment.
- Moreover an URL handler factory can be set only once and if someone
previously set his own you will not be able to supersede it.
Looks like it could be a problem if we rely only on this?
My 2 cents,
--
Christophe
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org