On Sun, 11 May 2003, J.Pietschmann wrote:
> Robert P. J. Day wrote:
> > first, in terms of building, FOP is again sort of flexible
> > when it comes to recognizing a JIMI archive. despite what
> > the documentation ways, the JIMI file copied under {fop}/lib
> > doesn't *have* to be called jimi-1.0.jar. from my tests,
> > jimi.jar seems to work fine since that name still generates
> > the confirmation:
> >
> > "[echo] Jimi library is present. Installing Jimi support."
> >
> > however, it's *not* acceptable to just call it "Jimi.jar",
>
> A short look into build.xml would have saved you some experimentation:
> <path id="libs-build-classpath">
> <fileset dir="lib">
> <include name="xalan*.jar"/>
> <include name="xerces*.jar"/>
> <include name="xml-apis.jar"/>
> <include name="avalon-framework*.jar"/>
> <include name="batik*.jar"/>
> <include name="jimi*.jar"/>
> <include name="jai*.jar"/>
> </fileset>
> </path>
> These are all jars searched for build-time dependencies.
> The fop.sh is a bit more generous:
> # add in the dependency .jar files, which reside in $FOP_HOME/lib
> DIRLIBS=${FOP_HOME}/lib/*.jar
> while fop.bat isn't:
> set LOCALCLASSPATH=build/fop.jar
> set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xml-apis.jar
> set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xercesImpl-2.2.1.jar
> set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xalan-2.4.1.jar
> set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\batik.jar
> set
> LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\avalon-framework-cvs-20020806.jar
> set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jimi-1.0.jar
> set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jai_core.jar
> set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\jai_codec.jar
ah, that's useful to know. i'm new to this kind of build, and i didn't
appreciate the significance of build.xml. more reading.
> > anyway, the bigger problem is that, after the build,
> > any graphics that require JIMI just don't render.
> 1. If JAI is found, Jimi isn't used at all.
now *that* is not mentioned anywhere in the online docs, and would
have been useful to know. however, trying to get around that just
brought up a different (and very weird) problem.
just to test JIMI, i figured i'd rebuild fop.jar without JAI support
just to see what JIMI could do. so i removed the jai* files from
{fop}/lib, did a build, noticed that the "prepare-jai" step did
*not* echo that JAI support was being built in, rebuilt my PDF
file and ... JAI was called to process the PNG files. huh?
i explicitly tried to build fop.jar without JAI support and there
is was. go back, start over. remove the fop.jar file, make sure
lib/ contains no jai* files, do a build, confirm that JAI support
is not listed during the build, copy new fop.jar over top of the old
one and ... *still* have JAI support. WTF?
deliberately move my fop.jar out of the CLASSPATH, to make *sure*
i'm not picking up an older version of the fop.jar file, and sure
enough, my "make" fails as FOP cannot be found. put the fop.jar
back on the CLASSPATH, and i magically have JAI support again.
how the heck can i make JAI support go away at this point? it's
like, once i built with JAI support once, i have it forever no
matter what.
> 2. FOP supports only PNG, TGA, EPS and TIFF, all other formats
> fall into the SVG clause and cause errors.
but again, according to the online docs, SVG support is handled by
batik, which i definitely have on my CLASSPATH.
so, once again, the online docs suggest SVG support should be
easy with batik, and yet, it's not there (although i do realize
that the online docs list limitations with SVG processing at the
moment).
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
