[Fwd: Problem with Batik source code]

[Keven Ring]

-------- Original Message --------

Subject:	Problem with Batik source code
Date:	Mon, 03 Feb 2003 11:52:47 -0500
From:	Keven Ring <[EMAIL PROTECTED]>
To:	[EMAIL PROTECTED]

Tom:

  We are using batik to render a large (>2000) SVG image set.  These 
images consist of references to other SVGs, for compositional purposes. 
 We plan on distributing the SVGs in a jar file, due both to the large 
number of images, and because we plan on utilizing JNLP for distribution 
purposes.  The images are grouped into categories and subcategories 
appropriately, with each category represented by a directory.

  When we originally developed the image set, we were rendering the 
icons as they resided on the filesystem, ie, not in a JAR file.  As a 
result, the icons had relative path locations to the other SVG 
components.  These relative paths often went up one or more directories, 
via the standard '..' notation.

  When we put the icons in a JAR file, the previous directory notation 
['..'] no longer applied.  We converted all of the references to use 
absolute paths from the context of the jar file itself.  Thus, all xlink 
targets start with a 'root directory' notation, or '/'.

  None of the icons rendered appropriately in batik when we did this. 
 We tracked it down to the way that the ParsedURLDefaultProtocolHandler 
constructed 'relative' URLs, specifically relating to jar files. 
 Because it appeared that only jar files were affected, we made a change 
to the ParsedURLJarProtocolHandler.  The patch for this file is attached.

  Specifically, the default protocol handler removed the jar file 
reference (ie, the  in the syntax:  jar:!) when a relative path was provided.  We believe 
this to be incorrect, and instead, the  should be 
replaced or appended to (depending on the absolute or relative nature of 
the path provided).

  For instance, if the original JAR url was:

jar:/path/to/jar!/path/to/file

and the new URL string is
/newpath/to/different/file

then the current code produces the following URL:
jar:/newpath/to/different/file rather than
jar:/path/to/jar!/newpath/to/different/file

The same was true if a relative path was provided, thus a new URL string of
additional/file
would become
jar:additional/file
rather than
jar:/path/to/jar!/path/to/additional/file

For now, we are working with a modified batik 1.5b4.  However, if this 
change (or a modification producing similar results) were incorporated 
into the baseline, it would be appreciated.

If you have any questions, or would like the set (or subset) of images, 
please let me know.

Thanks for you assistance with this matter.

-- 
Keven Ring                     | They called it Paradise, I don't know why
Lead Software Systems Engineer | When you call someplace Paradise
The MITRE Corporation          | Kiss it goodbye....
(703)883-7026                  |   The Eagles, The Last Resort 

-- 
Keven Ring                     | They called it Paradise, I don't know why
Lead Software Systems Engineer | When you call someplace Paradise
The MITRE Corporation          | Kiss it goodbye....
(703)883-7026                  |   The Eagles, The Last Resort