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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to