Re: [xep-support] EntityResolver, PDF and SVG support in XEP 3.0.2

From: Nikolai Grigoriev (grig@renderx.com)
Date: Fri Oct 25 2002 - 03:45:45 PDT


Johann,

> 1.) What kind of Entity Resolver do you use in XEP?
> Is there any chance to override this somehow?
> It would, for example, being interesting to use
> Norman Wlash's Entity Resolver with Catalog support

Strictly speaking, it's not a formatter's business. On the API level,
XEP accepts an arbitary SAX2 parser in an argument to
Driver.render() method; you can specify a parser of your
own and set your preferred EntityResolver on it.

There is no method to specify an explicit entity resolver
for command-line operation. However, you can make use
of the fact that XEP selects its default SAX parser via JAXP.
Create a jar containing an implementation of SAXParserFactory
that sets the desired EntityResolver on each XMLReader
returned by its newSAXParser() method, and put it into
the classpath instead of saxon.jar; it should work.

> 2.) What is the current status for PDF as vector image format?
> I saw a Post dating from Nov 2001 where this was announced
> as a TODO. Any significant changes to expect in the near future
> on this topic (i.e. PDF available as vector input)?

I can reassure that we are working in that direction. It may appear
in the next release if we decide that the implementation is already
mature.

> (These guys from NTS (JAVA successor to LaTeX) are doing
> this, if I am right.)

Maybe. Putting PDF into PDF is not like putting EPS into PS:
you have to parse the whole PDF document, and renumber all
objects. Not a slack, please believe me.

> 3.) Is it correct that SVG vector support dropped out in the
> current 3.0.2 version of XEP? And for what reason?
> And, will it be back soon?

Yes. SVG support in XEP 2.77 was based on CSIRO toolkit;
this solution gave us a possibility to fill SVG in quckly, but
turned out to be too restrictive in a long-term perspective:
  - it requires a specific version of Xerces to be present
    (the rest of XEP is parser-agnostic, and depends only on SAX2 classes);
  - it does not work under old versions of Java.
In other words, we faced the same problem as for the graphics: Sun's
Jimi was a good start, but became a burden on further stages. Like graphics,
SVG part is reingeneered from scratch; we didn't make in time to complete
this job for the release of XEP 3.0.

The work of reimplementing SVG is underway: we expect that the
result will be faster and cover a larger SVG subset than it was in 2.77.
However, I cannot promise any specific release date now.

Best regards,
Nikolai Grigoriev
RenderX

-------------------
By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html



This archive was generated by hypermail 2.1.5 : Wed Dec 18 2002 - 08:41:28 PST