You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/10/11 15:04:00 UTC

Extending Batik Support

Batik has standard hooks to support URL protocols.  They use
a "parsed url" which lets you get at all the good parts of the
URL without suffering the dreaded "MalformedURLException".  It
is also how we can add support for Cocoon's special purpose
protocols: "context:", "resource:", and (dare we hope) "cocoon:".

I would like to have Cocoon expand it's support and provide a
adaptor for Cocoon's Protocol handlers to Batik's
org.apache.batik.util.ParsedURLProtocolHandler structure.

If anyone knows Batik well enough to implement it quickly, please
volunteer.  Otherwise I will do it (it just may take me longer than
I like).  This is for a 2nd job I am doing to pay for my technology
habit (yes, I am addicted to newer and better computing experiences).
If the business picks up, I can get the owner to start up an R&D
arm...

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Extending Batik Support

Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
> > Cocoon now has supplied the context protocol to Batik!  Now you can code
> > your SVG files with confidence regarding where the files are located.
> > Next up will be the "resource" protocol.
> >
> > The Cocoon protocol does not result in a stream, and therefore will require
> > serious ugly hacks to open it to Batik.  Therefore, I am -1 for that.
> 
> How about this in CocoonSource:
> 
>     /**
>      * Return an <code>InputStream</code> object to read from the source.
>      */
>     public InputStream getInputStream()
>     throws ProcessingException, IOException {
> 
> Looks like stream to me. Can't it be used?

Ah, My knowledge of Cocoon protocol workings are limitted.  The problem is the
ugly hacks required in setting the reference to the CocoonSource so that Batik
can do it right.

> PS: Do you know, is there any issues with including resources into PDF?
> (I do not use FOP, but seems to me that it also might have some similar issues)

Don't know.  I know FOP now uses Batik for image stuff, so maybe one fix works
for the other....

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: Extending Batik Support

Posted by Vadim Gritsenko <va...@verizon.net>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, October 11, 2001 3:26 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Extending Batik Support
> 
> 
> > > > Batik has standard hooks to support URL protocols.  They use
> > > > a "parsed url" which lets you get at all the good parts of the
> > > > URL without suffering the dreaded "MalformedURLException".  It
> > > > is also how we can add support for Cocoon's special purpose
> > > > protocols: "context:", "resource:", and (dare we hope) "cocoon:".
> > >
> > > I put together something for "Context" protocols.  Unfortunately,
> > > I can't seem to make it work.  I can't even really tell if it has
> > > been loaded.  I will have to add some "print" messages to it just
> > > to make sure it works.
> > 
> > I have tried the print messages, and Batik recognizes the new protocol.
> > That is good--I was a bit concerned for a minute.  The problem is that
> > the resource is not returned to Batik.  I will do a little more
> > plugging around to see what is going on.
> 
> YAY!!!

Congrats :)

> 
> Cocoon now has supplied the context protocol to Batik!  Now you can code
> your SVG files with confidence regarding where the files are located.
> Next up will be the "resource" protocol.
> 
> The Cocoon protocol does not result in a stream, and therefore will require
> serious ugly hacks to open it to Batik.  Therefore, I am -1 for that.

How about this in CocoonSource:

    /**
     * Return an <code>InputStream</code> object to read from the source.
     */
    public InputStream getInputStream()
    throws ProcessingException, IOException {

Looks like stream to me. Can't it be used?

PS: Do you know, is there any issues with including resources into PDF?
(I do not use FOP, but seems to me that it also might have some similar issues)

Regards,
Vadim


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Extending Batik Support

Posted by Berin Loritsch <bl...@apache.org>.
> > > Batik has standard hooks to support URL protocols.  They use
> > > a "parsed url" which lets you get at all the good parts of the
> > > URL without suffering the dreaded "MalformedURLException".  It
> > > is also how we can add support for Cocoon's special purpose
> > > protocols: "context:", "resource:", and (dare we hope) "cocoon:".
> >
> > I put together something for "Context" protocols.  Unfortunately,
> > I can't seem to make it work.  I can't even really tell if it has
> > been loaded.  I will have to add some "print" messages to it just
> > to make sure it works.
> 
> I have tried the print messages, and Batik recognizes the new protocol.
> That is good--I was a bit concerned for a minute.  The problem is that
> the resource is not returned to Batik.  I will do a little more
> plugging around to see what is going on.

YAY!!!

Cocoon now has supplied the context protocol to Batik!  Now you can code
your SVG files with confidence regarding where the files are located.
Next up will be the "resource" protocol.

The Cocoon protocol does not result in a stream, and therefore will require
serious ugly hacks to open it to Batik.  Therefore, I am -1 for that.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Extending Batik Support

Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> 
> Berin Loritsch wrote:
> >
> > Batik has standard hooks to support URL protocols.  They use
> > a "parsed url" which lets you get at all the good parts of the
> > URL without suffering the dreaded "MalformedURLException".  It
> > is also how we can add support for Cocoon's special purpose
> > protocols: "context:", "resource:", and (dare we hope) "cocoon:".
> 
> I put together something for "Context" protocols.  Unfortunately,
> I can't seem to make it work.  I can't even really tell if it has
> been loaded.  I will have to add some "print" messages to it just
> to make sure it works.

I have tried the print messages, and Batik recognizes the new protocol.
That is good--I was a bit concerned for a minute.  The problem is that
the resource is not returned to Batik.  I will do a little more
plugging around to see what is going on.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Extending Batik Support

Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> 
> Batik has standard hooks to support URL protocols.  They use
> a "parsed url" which lets you get at all the good parts of the
> URL without suffering the dreaded "MalformedURLException".  It
> is also how we can add support for Cocoon's special purpose
> protocols: "context:", "resource:", and (dare we hope) "cocoon:".


I put together something for "Context" protocols.  Unfortunately,
I can't seem to make it work.  I can't even really tell if it has
been loaded.  I will have to add some "print" messages to it just
to make sure it works.

> 
> I would like to have Cocoon expand it's support and provide a
> adaptor for Cocoon's Protocol handlers to Batik's
> org.apache.batik.util.ParsedURLProtocolHandler structure.
> 
> If anyone knows Batik well enough to implement it quickly, please
> volunteer.  Otherwise I will do it (it just may take me longer than
> I like).  This is for a 2nd job I am doing to pay for my technology
> habit (yes, I am addicted to newer and better computing experiences).
> If the business picks up, I can get the owner to start up an R&D
> arm...
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org