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 Bill Haneman <bi...@ireland.sun.com> on 2001/03/13 12:52:36 UTC

Re: Batik SVG in Mozilla

Aaron Leventhal wrote:
> 
> Bill,
> 
> I would love to see your Batik SVG project be integrated into Mozilla as
> a layout component. Our current SVG project is stalled, the developer
> has moved on, and no one wants to take over the code. SVG in Mozilla is
> a must!
> 

Hi Aaron:

This is great, we'd love to assist in any way we can.  I believe that
Vincent Hardy (vincent.hardy@eng.sun.com) of the SVG team has already 
integrated Batik as a Mozilla pluglet, at least as an investigation, 
and can give you feedback about his experience doing this.  I don't
believe that you'll encounter any significant problems, though
Batik does require Java2.  JDK 1.3 has a bunch of performance
improvements which are quite visible in Batik, so 1.3 is ideal.

I myself have been thinking, not too surprisingly :-), of adding 
accessibility features to Batik (in addition to what comes
directly from using JFC/Swing components), which would make it
possibly the first fully accessible graphics display 
engine/format.  Batik is getting pretty close to fully compliant
as a static rendering engine now, and scripting support is
on this year's roadmap as is completion of text support with 
SVG fonts and text-on-a-path.  

I don't see why Batik couldn't help with the chrome as well,
but bear in mind that it renders into a Java component.  
It can create a number of different image buffer types, so
it's possible that it could be bridged to native image buffers
fairly effectively.

Please keep up posted on this front, and feel free to post to
batik-users@xml.apache.org or batik-dev@xml.apache.org with
questions and suggestions.

Regards,

-Bill

P.S. - I have CC'd batik-dev and mozilla-accessibility, so anyone who
replies may want to be careful about the cross-posts :-)


> That said, we don't want SVG just in the content area. We want to be
> able to use SVG in place of .gif's and .png's in our UI chrome. This
> would enable us to build a scaleable, high contrast chrome with simple
> graphics. We'd be able to script the size and colors of the chrome and
> icons through the DOM.
> 
> - Aaron
> 


-- 
--------------
Bill Haneman
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland

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


Re: Batik SVG in Mozilla

Posted by Vincent Hardy <vh...@eng.sun.com>.
Aaron,

Aaron Leventhal wrote:
> 
> Vincent:
> 
> Can you see any problem with using Batik SVG in the Mozilla chrome itself?
> I'd like to see who you should be talking to here.

Well, I do not know enough about Mozilla Chromes to give you a definite
answer. If a Mozilla Chromes content provider can be implemented by Java
code, then I would think it is possible. So far, the experiments we
made were with the pluglet infrastructure.

Regards.
Vincent.

> 
> Aaron
> 
> Vincent Hardy wrote:
> 
> > Aaron, Bill,
> >
> > Yes, we have indeed experimented and demonstrated integration of
> > Batik in Mozilla, using the pluglet architecture, which lets developers
> > write Mozilla plugin in the Java language.
> >
> > What we have shown (thanks to the help of the pluglet team) is that
> > you could use Batik to handle the SVG Mime Type in Mozilla and we
> > demonstrated that at an XML conference in Washington last December.
> >
> > This is not distributed on the Batik web site because there is a fair
> > amount of additional work to be done:
> >
> > a. Packaging what we have done (documentation, installation
> > instructions).
> > b. Finer integration (there are some big things missing, such as
> >    a pop-up menu in the SVG canvas to change the zoom factor, etc...)
> >
> > As Bill mentioned, we are finalizing the first version of Batik and
> > part of that effort includes a much improved JSVGCanvas that will
> > make integration with Mozilla a lot easier.
> >
> > Also, once we get scripting in, the integration work will have to
> > incorporate making the Batik SVG DOM visible to Mozilla so that, for
> > example, a script embeded in an HTML page could access/modify an
> > SVG document rendered by Batik.
> >
> > We (the Batik team) are very short on resources for this integration
> > work even though we realize it is quite important. Any help would be
> > greatly appreciated.
> >
> > Regards.
> > Vincent.
> >
> > Bill Haneman wrote:
> >
> >> Aaron Leventhal wrote:
> >>
> >>> Bill,
> >>>
> >>> I would love to see your Batik SVG project be integrated into Mozilla as
> >>> a layout component. Our current SVG project is stalled, the developer
> >>> has moved on, and no one wants to take over the code. SVG in Mozilla is
> >>> a must!
> >>>
> >> Hi Aaron:
> >>
> >> This is great, we'd love to assist in any way we can.  I believe that
> >> Vincent Hardy (vincent.hardy@eng.sun.com) of the SVG team has already
> >> integrated Batik as a Mozilla pluglet, at least as an investigation,
> >> and can give you feedback about his experience doing this.  I don't
> >> believe that you'll encounter any significant problems, though
> >> Batik does require Java2.  JDK 1.3 has a bunch of performance
> >> improvements which are quite visible in Batik, so 1.3 is ideal.
> >>
> >> I myself have been thinking, not too surprisingly :-), of adding
> >> accessibility features to Batik (in addition to what comes
> >> directly from using JFC/Swing components), which would make it
> >> possibly the first fully accessible graphics display
> >> engine/format.  Batik is getting pretty close to fully compliant
> >> as a static rendering engine now, and scripting support is
> >> on this year's roadmap as is completion of text support with
> >> SVG fonts and text-on-a-path.
> >>
> >> I don't see why Batik couldn't help with the chrome as well,
> >> but bear in mind that it renders into a Java component.
> >> It can create a number of different image buffer types, so
> >> it's possible that it could be bridged to native image buffers
> >> fairly effectively.
> >>
> >> Please keep up posted on this front, and feel free to post to
> >> batik-users@xml.apache.org or batik-dev@xml.apache.org with
> >> questions and suggestions.
> >>
> >> Regards,
> >>
> >> -Bill
> >>
> >> P.S. - I have CC'd batik-dev and mozilla-accessibility, so anyone who
> >> replies may want to be careful about the cross-posts :-)
> >>
> >>> That said, we don't want SVG just in the content area. We want to be
> >>> able to use SVG in place of .gif's and .png's in our UI chrome. This
> >>> would enable us to build a scaleable, high contrast chrome with simple
> >>> graphics. We'd be able to script the size and colors of the chrome and
> >>> icons through the DOM.
> >>>
> >>> - Aaron
> >>>
> >> --
> >> --------------
> >> Bill Haneman
> >> Gnome Accessibility / Batik SVG Toolkit
> >> Sun Microsystems Ireland
> >

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


Re: Batik SVG in Mozilla

Posted by Aaron Leventhal <aa...@chorus.net>.
Vincent:

Can you see any problem with using Batik SVG in the Mozilla chrome itself?
I'd like to see who you should be talking to here.

Aaron


Vincent Hardy wrote:

> Aaron, Bill,
> 
> Yes, we have indeed experimented and demonstrated integration of 
> Batik in Mozilla, using the pluglet architecture, which lets developers
> write Mozilla plugin in the Java language.
> 
> What we have shown (thanks to the help of the pluglet team) is that 
> you could use Batik to handle the SVG Mime Type in Mozilla and we 
> demonstrated that at an XML conference in Washington last December.
> 
> This is not distributed on the Batik web site because there is a fair
> amount of additional work to be done:
> 
> a. Packaging what we have done (documentation, installation
> instructions).
> b. Finer integration (there are some big things missing, such as 
>    a pop-up menu in the SVG canvas to change the zoom factor, etc...)
> 
> As Bill mentioned, we are finalizing the first version of Batik and 
> part of that effort includes a much improved JSVGCanvas that will
> make integration with Mozilla a lot easier.
> 
> Also, once we get scripting in, the integration work will have to 
> incorporate making the Batik SVG DOM visible to Mozilla so that, for
> example, a script embeded in an HTML page could access/modify an
> SVG document rendered by Batik.
> 
> We (the Batik team) are very short on resources for this integration
> work even though we realize it is quite important. Any help would be
> greatly appreciated.
> 
> Regards.
> Vincent. 
> 
> Bill Haneman wrote:
> 
>> Aaron Leventhal wrote:
>> 
>>> Bill,
>>> 
>>> I would love to see your Batik SVG project be integrated into Mozilla as
>>> a layout component. Our current SVG project is stalled, the developer
>>> has moved on, and no one wants to take over the code. SVG in Mozilla is
>>> a must!
>>> 
>> Hi Aaron:
>> 
>> This is great, we'd love to assist in any way we can.  I believe that
>> Vincent Hardy (vincent.hardy@eng.sun.com) of the SVG team has already
>> integrated Batik as a Mozilla pluglet, at least as an investigation,
>> and can give you feedback about his experience doing this.  I don't
>> believe that you'll encounter any significant problems, though
>> Batik does require Java2.  JDK 1.3 has a bunch of performance
>> improvements which are quite visible in Batik, so 1.3 is ideal.
>> 
>> I myself have been thinking, not too surprisingly :-), of adding
>> accessibility features to Batik (in addition to what comes
>> directly from using JFC/Swing components), which would make it
>> possibly the first fully accessible graphics display
>> engine/format.  Batik is getting pretty close to fully compliant
>> as a static rendering engine now, and scripting support is
>> on this year's roadmap as is completion of text support with
>> SVG fonts and text-on-a-path.
>> 
>> I don't see why Batik couldn't help with the chrome as well,
>> but bear in mind that it renders into a Java component.
>> It can create a number of different image buffer types, so
>> it's possible that it could be bridged to native image buffers
>> fairly effectively.
>> 
>> Please keep up posted on this front, and feel free to post to
>> batik-users@xml.apache.org or batik-dev@xml.apache.org with
>> questions and suggestions.
>> 
>> Regards,
>> 
>> -Bill
>> 
>> P.S. - I have CC'd batik-dev and mozilla-accessibility, so anyone who
>> replies may want to be careful about the cross-posts :-)
>> 
>>> That said, we don't want SVG just in the content area. We want to be
>>> able to use SVG in place of .gif's and .png's in our UI chrome. This
>>> would enable us to build a scaleable, high contrast chrome with simple
>>> graphics. We'd be able to script the size and colors of the chrome and
>>> icons through the DOM.
>>> 
>>> - Aaron
>>> 
>> --
>> --------------
>> Bill Haneman
>> Gnome Accessibility / Batik SVG Toolkit
>> Sun Microsystems Ireland
> 


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


Re: Batik SVG in Mozilla

Posted by Vincent Hardy <vh...@eng.sun.com>.
Aaron, Bill,

Yes, we have indeed experimented and demonstrated integration of 
Batik in Mozilla, using the pluglet architecture, which lets developers
write Mozilla plugin in the Java language.

What we have shown (thanks to the help of the pluglet team) is that 
you could use Batik to handle the SVG Mime Type in Mozilla and we 
demonstrated that at an XML conference in Washington last December.

This is not distributed on the Batik web site because there is a fair
amount of additional work to be done:

a. Packaging what we have done (documentation, installation
instructions).
b. Finer integration (there are some big things missing, such as 
   a pop-up menu in the SVG canvas to change the zoom factor, etc...)

As Bill mentioned, we are finalizing the first version of Batik and 
part of that effort includes a much improved JSVGCanvas that will
make integration with Mozilla a lot easier.

Also, once we get scripting in, the integration work will have to 
incorporate making the Batik SVG DOM visible to Mozilla so that, for
example, a script embeded in an HTML page could access/modify an
SVG document rendered by Batik.

We (the Batik team) are very short on resources for this integration
work even though we realize it is quite important. Any help would be
greatly appreciated.

Regards.
Vincent. 

Bill Haneman wrote:
> 
> Aaron Leventhal wrote:
> >
> > Bill,
> >
> > I would love to see your Batik SVG project be integrated into Mozilla as
> > a layout component. Our current SVG project is stalled, the developer
> > has moved on, and no one wants to take over the code. SVG in Mozilla is
> > a must!
> >
> 
> Hi Aaron:
> 
> This is great, we'd love to assist in any way we can.  I believe that
> Vincent Hardy (vincent.hardy@eng.sun.com) of the SVG team has already
> integrated Batik as a Mozilla pluglet, at least as an investigation,
> and can give you feedback about his experience doing this.  I don't
> believe that you'll encounter any significant problems, though
> Batik does require Java2.  JDK 1.3 has a bunch of performance
> improvements which are quite visible in Batik, so 1.3 is ideal.
> 
> I myself have been thinking, not too surprisingly :-), of adding
> accessibility features to Batik (in addition to what comes
> directly from using JFC/Swing components), which would make it
> possibly the first fully accessible graphics display
> engine/format.  Batik is getting pretty close to fully compliant
> as a static rendering engine now, and scripting support is
> on this year's roadmap as is completion of text support with
> SVG fonts and text-on-a-path.
> 
> I don't see why Batik couldn't help with the chrome as well,
> but bear in mind that it renders into a Java component.
> It can create a number of different image buffer types, so
> it's possible that it could be bridged to native image buffers
> fairly effectively.
> 
> Please keep up posted on this front, and feel free to post to
> batik-users@xml.apache.org or batik-dev@xml.apache.org with
> questions and suggestions.
> 
> Regards,
> 
> -Bill
> 
> P.S. - I have CC'd batik-dev and mozilla-accessibility, so anyone who
> replies may want to be careful about the cross-posts :-)
> 
> > That said, we don't want SVG just in the content area. We want to be
> > able to use SVG in place of .gif's and .png's in our UI chrome. This
> > would enable us to build a scaleable, high contrast chrome with simple
> > graphics. We'd be able to script the size and colors of the chrome and
> > icons through the DOM.
> >
> > - Aaron
> >
> 
> --
> --------------
> Bill Haneman
> Gnome Accessibility / Batik SVG Toolkit
> Sun Microsystems Ireland

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