Hi Vasilev, that's funny: I worked on the same issue yesterday. :) On Donnerstag, 22. Februar 2007, Vasilev Max wrote:

SVG file from susedoc package (susedoc-4.2_20070221-1.noarch.rpm) includes external reference to DTD file on www.w3.org:

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd"> <!-- Created with Inkscape (http://www.inkscape.org/) -->

Yes, that's correct. The external reference is a DOCTYPE declaration to validate SVG files. It's the same method as with your DocBook XML files, but with a different declaration.

I tried to build documentation without Internet connect and get error:

[error] Failed to create image file:/usr/share/susedoc/xslt/images/svg/novell-logo.svg of type null [error] com.renderx.graphics.ImageFormatException: org.xml.sax.SAXParseException: Cannot read from http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd (www.w3.org)

This error is expected. :)

I open this svg file with Inkscape and save it in Plain SVG format, now build work fine in offline mode (without Internet).

Here is zip archive with resaved SVG: http://svn.team.org.ru:8000/trac/changeset/111/patch/susedoc_svg?ol d_path=%2F&format=zip

There are two options to avoid this difficulty: 1. Remove/disable the DOCTYPE declaration for your SVG files This is the easiest solution and you have done it already by saving it in plain SVG. 2. Use an XML catalog to resolve URLs This is a standard method in XML to resolve URIs/URLs to local paths. The main file /etc/xml/catalog contains entries to map a public identifier or any URI to a local path. Very convenient. Most time option 1 is enough. However, you can not guarantee to have a valid SVG file. Any (semantical) errors are probably not detected or may create unexpected results in your PDF. Option 2 is more difficult to implement, as you have to tell the FOP formatter the XML catalog resolver. However, you don't have to care for your SVG files (or any other possible XML source, like MathML). Any errors in a SVG file are shown. Depending on your used tools you end up with or without a DOCTYPE declaration. I general, I think it is a good thing to have one as it helps to detect errors and the process doesn't proceed silently. At the moment I am implementing option 2. This should solve also the long formatting time for FOP. I plan to update the susedoc RPM package in the near future. This will contain Russian translations from Nikolay and fix the above problem. For the time being disable the DOCTYPE declaration. Thanks for the report, Tom -- Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX GmbH >o) Documentation Specialist Maxfeldstrasse 5 /\\ 90409 Nuernberg _\_v http://en.opensuse.org/Documentation_Team --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-doc+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-doc+help@opensuse.org