Re: [xep-support] SVG, identifiers, xml catalogs, resolver, net access

Steve Whitlatch wrote:
> Can anyone state from their own experience that XEP does indeed properly use
> xml-commons-resolver?
>
My use case is that I have an XSL-FO document whith an
fo:external-graphic referencing an SVG document which contains a DOCTYPE
with both public and system id's, the system id being a URL to somewhere
in w3.org. In this configuration, I manage to have XEP use a catalog to
resolve the SVG public id to my local copy of the SVG DTD, instead of
fetching it from w3.org.

I posted some time ago on the list the commands that I use for this
wizardry to happen ;-)

Maybe try to debug XEP (using xep-debug.jar, I guess, I've never had the
need myself) just when it launches to see if it loads the CatalogManager
properly.

I don't use XEP to convert XML sources to XSL-FO: I prefer to control
what happens and use Saxon or others directly.

Benoit

> Thanks,
>
> Steve Whitlatch
>
>
>
>> Hoping this helps.
>> Benoit
>>
>> Steve Whitlatch wrote:
>>
>>> Hello,
>>>
>>> Thanks to all who previously discussed similar subjects on this and other
>>> mailing lists. The archives of those discussions almost allowed me to
>>> solve my problem.
>>>
>>> I am trying to use some SVG graphics with XEP. These SVG graphics were
>>> exported from Adobe Illustrator and each includes the following
>>> identifiers: PUBLIC "-//W3C//DTD SVG 1.0//EN"
>>> "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd"
>>>
>>> XEP attempts to access svg10.dtd over the Internet, and of course fails
>>> when the local system is not connected. XML Catalogs
>>> (xml-commons-resolver-1.1) cures the same/similar problem for other apps,
>>> like Saxon, but not yet for XEP. I expect that the error is mine, but I
>>> don't know what else to try. Help?
>>>
>>> I believe I have xml catalogs properly working, for example:
>>> ************
>>> % java org.apache.xml.resolver.apps.xparse file.svg
>>> Parse catalog: file:///c:/etc/xml/catalog
>>> Loading catalog: file:///c:/etc/xml/catalog
>>> Default BASE: file:/c:/etc/xml/catalog
>>> rewriteSystem: http://www.oasis-open.org/docbook/xml/4.2/
>>> file:///D:/cygwin/usr/share/xml/docbook/xml-dtd-4.2/
>>> .
>>> .
>>> .
>>> rewriteSystem: http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd
>>> file:///C:/RenderX/XEP/lib/DTDs/svg10.dtd
>>> REWRITE_SYSTEM: http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd
>>> file:/C:/RenderX/XEP/lib/DTDs/svg10.dtd
>>> .
>>> .
>>> .
>>> public: -//W3C//DTD SVG 1.0//EN
>>> file:///C:/RenderX/XEP/lib/DTDs/svg10.dtd
>>> PUBLIC: -//W3C//DTD SVG 1.0//EN
>>> file:/C:/RenderX/XEP/lib/DTDs/svg10.dtd
>>> .
>>> .
>>> .
>>>
>>> Attempting validating, namespace-aware parse
>>> resolveSystem(http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd)
>>> Resolved system: http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd
>>> file:/C:/RenderX/XEP/lib/DTDs/svg10.dtd
>>> .
>>> .
>>> .
>>> ***************
>>>
>>> Is it necessary to provide additional examples showing xml catalogs
>>> working on this system? I think I could provide an infinite number of
>>> them. However, still, XEP insists on accessing the SVG files' SYSTEM
>>> identifiers over the Internet. For example, when using the following
>>> command
>>>
>>> % java com.renderx.xep.XSLDriver -DCONFIG=C:\\RenderX\\XEP\\xep.xml \
>>>
>>> -Dcom.renderx.sax.entityresolver=org.apache.xml.resolver.tools.CatalogRes
>>> olver \
>>> -Dcom.renderx.jaxp.uriresolver=org.apache.xml.resolver.tools.CatalogResol
>>> ver \ -fo file.fo -pdf file.pdf
>>>
>>> for each SVG graphic, XEP produces an error message similar to this:
>>>
>>> ********
>>> [error] Failed to create image
>>> file:/D:/cygwin/home/steve/CurrentWork/ArchDoc/DocBookXSL/RenderX/graphic
>>> s/IITP-1155_scaled_no_fonts.svg of type image/svg+xml [error]
>>> java.net.UnknownHostException: www.w3.org
>>> *********
>>>
>>> What next?
>>>
>>> Thanks,
>>>
>>> Steve Whitlatch
>>>
>>>
>>>
>>> -------------------
>>> (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
>>> in the body of the message to majordomo@renderx.com from the address
>>> you are subscribed from.
>>> (*) By using the Service, you expressly agree to these Terms of Service
>>> http://www.renderx.com/terms-of-service.html
>>>
> -------------------
> (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
> in the body of the message to majordomo@renderx.com from the address
> you are subscribed from.
> (*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html
>

-- 
Benoit Maisonny                benoit@synclude.com
Director & Consultant          http://synclude.com
Synclude
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html