Robert P. J. Day wrote:

>   oh, i'm *long* past the point of personal embarrassment here.
> although i'm willing to admit that some of my difficulties were
> my fault, i think i've also established that there are some definite
> deficiencies in the docs for graphics support.  where to start?

Sorry Robert, Joerg is right. There may be some deficiencies in the doc, and
I am considering what further changes we should make to clean it up, but the
bottom line is that you are asking us to make it "stupid-proof", and I don't
think we can do that.

>   (first, since i made it clear that i was working with the CVS
> tree, to clean that tree requires "build.sh clean", not
> "build clean" as you wrote above.  a picky detail, but the sort
> of thing that has been costing me time and forced me to dig
> around when i didn't have to.)

Wrong. If you were running in a Windows environment, it would be
"build.bat". Joerg's answer was the correct generic answer. The fact that
you are digging around is your fault. The fact that you blame it on Joerg
should be yet another cause for embarrassment.

>   next, and as i've already mentioned, there is *nothing* i can see
> in the docs that suggest that, if you build in JAI support, JIMI
> support is simply dropped.  *that* really deserves a prominent
> place in the docs.

Duly noted.

>   next, regarding a build, there's *nothing* that suggests you need
> to do a "build.sh clean" to actually get a new "fop.jar".  early on,
> as part of my tests, i explicitly deleted {fop}/build/fop.jar,
> and watched the output from "build.sh" carefully to confirm that,
> yes, the support i wanted was being built in.  afterwards, i
> verified that a new "fop.jar" had been created under {fop}/build.
> was i really supposed to suspect that the messages being printed
> by the build process didn't actually correspond to the new fop.jar
> file?  this is pretty thoroughly non-intuitive for anyone used to
> the "make" system.

First, please see:
http://xml.apache.org/fop/compiling.html#Troubleshooting
Second, you seem to think that we should know that you are familiar with
"make". That would be a documentation failure on your part. Third, you want
Ant to conform its behavior to make. That's not going to happen. You
embarrass yourself to suggest that it should.

> > > but again, according to the online docs, SVG support is handled by
> > > batik, which i definitely have on my CLASSPATH.
> >
> > PCX files are not SVG, and can't be handled by Batik, therefore
> > the errors.
> > Take a closer look at the output.
>
> and once i did a clean, and built with only JIMI support, here's
> the output (or at least an excerpt of it):
>
> [INFO] Failed to load JAI, using Jimi instead     <-- looks good ...
>
> ....
>
> [ERROR] Could not load external SVG: Content is not allowed in prolog.
> [ERROR] Error while creating area : No ImageReader for this type
> of image (file:xclock.pcx)
> [INFO] [30]
> [ERROR] Could not load external SVG: Content is not allowed in prolog.
> [ERROR] Error while creating area : No ImageReader for this type
> of image (file:xclock.pict)
> [INFO] [31]
> [INFO] [32]
> [ERROR] Could not load external SVG: Content is not allowed in prolog.
> [ERROR] Error while creating area : No ImageReader for this type
> of image (file:xclock.pnm)
> [INFO] [33]
> [ERROR] Could not load external SVG: Content is not allowed in prolog.
> [ERROR] Error while creating area : No ImageReader for this type
> of image (file:xclock.psd)
> [INFO] [34]
> [ERROR] Could not load external SVG: Content is not allowed in prolog.
> [ERROR] Error while creating area : No ImageReader for this type
> of image (file:xclock.ras)
> [INFO] [35]
> [ERROR] Could not load external SVG: Content is not allowed in prolog.
> [ERROR] Error while creating area : No ImageReader for this type
> of image (file:xclock.tga)
> [INFO] [36]
> [ERROR] Error while creating area : Error while loading image
> file:xclock.tiff : class java.lang.Exception - Image error
> [INFO] [37]
> [ERROR] Could not load external SVG: Content is not allowed in prolog.
> [ERROR] Error while creating area : No ImageReader for this type of image
> (file:xclock.xbm)
> [INFO] [38]
> [ERROR] Could not load external SVG: Content is not allowed in prolog.
> [ERROR] Error while creating area : No ImageReader for this type of image
> (file:xclock.xpm)
>
>
> and you can see that a number of formats that are documented as being
> supported through JIMI failed to be rendered.

The messages being generated here probably need some work. The normal
approach with open source is to submit a patch.

>   i'm using, as my guide, http://xml.apache.org/fop/graphics.html, so if
> something in that table suggests it's supported by JIMI, i figure i have a
> right to be confused if it doesn't work.

Only if you follow the instructions everywhere else. You still have a
problem either in your build or in your runtime environment. I frankly will
not take the time to help you find it.

>   while i appreciate your assistance thus far, i could really do without
>the smug, condescending tone about how i'm embarrassing myself.
>
>   i'm trying *really* hard to point out deficiencies in the docs so that
> others after me don't have to go throught what i went through.  and your
> attitude i can really live without.

What you are asking us to do is to place a sign in the windshield of the car
saying "do not drive this car off the cliff." That might be useful, but it
would also obscure the vision of the driver which can cause a lot of other
problems.

What you have no way of knowing is that a few weeks ago, the graphics doc
for bitmap formats was almost non-existent. IMO, it is much better today
than it was then. Your comments will likely help make it better. However,
the path was unnecessarily bloody and painful. FOP is an open source
project. If it doesn't work that way it should, it is just as much your
fault as it is mine or Joerg's. I recommend taking a more constructive
approach. At some point it becomes a disservice to other FOP users to spend
time dealing with threads like this.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to