Thomas, Thanks for your prompt response. I'm gutted by the content though. I didn't think it would be possible to deploy to 1.1. but I live in hope...
This whole issue around plug-ins is a real bug-bear. We recently developed an XML/XSLT (using JAXP) application for a utilities company. This company was using Solaris with Java 1.0!! As developers we are always aware of what are the latest and best developments, yet when we go into an organisation we find their IT infrastructure to be restrictive. This is bad news for SVG IMHO because, although SVG viewers will work on low spec machines, they don't work well and this reflects badly on SVG. That said I am still pushing to use Batik on the client-side because it offers the most extensible architecture - from applets to applications. Great work! Jamie ----- Original Message ----- From: "Thomas DeWeese" <[EMAIL PROTECTED]> To: "Batik Users" <[EMAIL PROTECTED]> Sent: Tuesday, July 22, 2003 2:24 PM Subject: Re: Using Batik w/out Plug-In > Jamie wrote: > > All, > > > > I am currently working on a proof of concept. Our company product only > > supports (and is dependent on) the Adobe SVG Viewer v.3. The > > reason being that the product was developed before Batik was fully > > mature. In order to make the case for switching to Batik I was hoping to > > be able to display SVG content in a Windows browser-based > > applet<em>without any</em> plug-ins i.e. just using the in-built Windows > > JVM. > > > > Accomplishing the same task to show the use of Swing is easy enough, > > just include the swing-all.jar in the archive tag. For Batik to work, > > I understand there is a dependency on Java 2D. > > > > Has anyone investigated this problem? Does anyone know a full list of > > dependencies to get JSVGCanvas to display in an applet without JRE1.3. > > If not, can anyone at Batik tell me whether what I am attempting is > > possible? If not, why? This application is intranet based so > > bandwidth/download times are not an issue. > > It is probably not feasable with the default Windows JVM. Aside > from the very heavy use of Java2D (which I am not aware of a 1.1 > implementation of) we also use features of the JVM like SoftReferences > which are essentially impossible to 'fake', another problem area is > text where we use the TextLayout/AttributedString classes for BIDI handling. > I certainly don't have a complete list of the non-1.1 dependencies but they > are likely extensive. > > > If I could deliver SVG to a browser without the java plug-in I would be > > in a strong position to argue for Java as basis for client-side > > architecture, with all the benefits that can bring. Don't bother telling > > me all the other benefits of Batik; I well aware, it is my boss I have > > to convince. At the moment I am trying to implement a ComboBox in > > JavaScript, which is like a broken pencil i.e. pointless. > > There are a few other SVG implementations in Java that are > generally targeted at PDA's/CellPhones since these are generally based > on Personal Java (a derivative of JDK 1.1) you might be able to > use one of those in your applet. TinyLine I think is one of them > most of these are targeting SVG Tiny as opposed to SVG Full so if you > need scripting/dynamic support you may need to do some significant work. > Fortunately I believe Rhino (the JavaScript engine we use) is able > to run on a 1.1 JVM. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
