Re: [Jeuclid-devel] Getting Batik to read SVG DTDs via catalog resolver

[Max Berger <ma...@berger.name>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Justus,


Justus-bulk@Piater.name schrieb:
> - Batik appears to preferentially read DTDs stored inside the jar. Not
>   a very clean solution, but it works out of the box.

JEuclid does the same, for the exact problem you mentioned: The default
parser tries to load the external entities (e.g. DTD), which causes
traffic and sometimes long delays. All MathML related dtd's are
therefore redirected to load from internal sources.

> - The culprit is - surprise! - the JEuclid Fop plugin, even though my
>   test document does not contain any MathML, and the problem goes away
>   if I remove the DOCTYPE declaration from the included SVG document:

I assume you have an external graphic? The JEuclid plugin tries to parse
it - since it is valid XML it has to follow all external entities for
correct parsing.

I could disable this (by returning invalid entities), but that would
disable entity handling alltogether, but that would violate the XML specs.

>   If I sever my Internet connection,
>   net.sourceforge.jeuclid.xmlgraphics.PreloaderMathML.parseSource()
>   hangs for 40 seconds. Or more precisely, it appears to be the
>   org.apache.xerces.impl.XMLEntityManager, called indirectly by that
>   method, that attempts to open a HTTP connection.
>   If I remove JEuclid from the classpath, the problem goes away.

As said, a Xerces problem. The same thing may happen the other way round
( when you have an external MathML file with DTD, when being parsed by
the SVG plugin).

> It seems that the Xerces parser used by JEuclid should somehow be
> convinced to use the EntityResolver available on the classpath. Or
> perhaps, one might abuse FOP's URIResolver, similarly to what I
> described above.

I could also convince JEuclid to use JEuclid's URI Resolver, but I am
not sure if that would solve the problem, or just move it.

You may want to play around with some Xerces parameters, especially the
feature http://apache.org/xml/features/nonvalidating/load-external-dtd

further info: http://xerces.apache.org/xerces-j/features.html

> Any comments or suggestions (Max)?
> Justus

hth

Max
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIdHgl+Gr+4pk71JwRAmFaAJoDDLeMiV/FrG5RdXxqx+ybMrBLOwCfZTen
gJLPuYHG+IlGMl4CjtiNkAc=
=WL4o
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Re: [Jeuclid-devel] Getting Batik to read SVG DTDs via catalog resolver

[Ju...@Piater.name]

Max Berger <ma...@berger.name> wrote on Wed, 09 Jul 2008 10:34:45 +0200:

> I assume you have an external graphic? The JEuclid plugin tries to parse
> it - since it is valid XML it has to follow all external entities for
> correct parsing.

Why does JEuclid need to parse external graphics? Is JEuclid able to
substitute MathML contained in XML content included via
fo:external-graphic?

> I could also convince JEuclid to use JEuclid's URI Resolver, but I am
> not sure if that would solve the problem, or just move it.

You mean Fop's? Otherwise I don't understand this remark.

The modularity of XML processing is great, but as a user, I normally
would not want to configure each module separately. I would like to be
able to simply throw any supported resolver into the classpath, and
all components use it (i.e., Fop and any plugins).

> You may want to play around with some Xerces parameters, especially the
> feature http://apache.org/xml/features/nonvalidating/load-external-dtd
>
> further info: http://xerces.apache.org/xerces-j/features.html

Just to avoid unnecessary work: This involves building the JEuclid Fop
plugin from sources, right? Or is there a way to configure this at run
time?

Thanks,
Justus

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org