[Fwd: RE: Problem with Batik source code]

[Keven Ring]

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

Subject:	RE: Problem with Batik source code
Date:	Mon, 3 Feb 2003 13:27:00 -0500
From:	Thomas E Deweese <[EMAIL PROTECTED]>
To:	Keven Ring <[EMAIL PROTECTED]>
CC:	[EMAIL PROTECTED]
References:	<[EMAIL PROTECTED]>

Hi Keven,

   I would rather discuss this on batik-dev than off list, if
possible.

>>>>> "KR" == Keven Ring  writes:

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

    Sounds cool.

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

KR>   When we put the icons in a JAR file, the previous directory
KR> notation ['..'] no longer applied.  

    Why?  I'm under the impression that relative references should
work within a JAR URL...

KR> We converted all of the references to use absolute paths from the
KR> context of the jar file itself.  Thus, all xlink targets start
KR> with a 'root directory' notation, or '/'.

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

    Thanks, I'm more or less happy to accept a change (I have some
comments on it below).  I knew that I wasn't really handling the
absolute case.

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

    Well I'm 99% certain that relative paths work just as you
describe.  There are a bunch of existing tests for this in the
ParsedURL testSuite (see
'xml-batik/test-resources/org/apache/batik/util/unitTesting.xml' tests
'ParsedURL.15' -> 'ParsedURL.21').  

    Could you please provide additional tests for absolute JAR sub
URL's?  This will help ensure that you have covered all cases and that
we don't break anything you are depending on in the future.

    In order to run regard (our test tool) you will need to do
one of two things.

    1) comment out the line:

    

    In 'xml-batik/test-resources/org/apache/batik/test/regard.xml'.

    2) Get a copy of the SVG Working Groups BE test suite. and unpack
       it in the same directory as xml-batik (so beSuite is a sibling
       of xml-batik).

    Then to run the ParsedURL tests simply use:

    % build.sh regard ParsedURL

---

Comments on the code:

    I'm a little disappointed with the use of java.net.URL here (as
opposed to directly handling the absolute and relative cases),
although I've most convinced myself that this doesn't introduce a
significant compatability issue (given the data protocol URL
requiremenst of SVG, java.net.URL makes me twichy :).

    As you seem to suspect I might, I really don't like the openStream
call.  Do you have a case that you expect to encounter here? If not I
would rather drop it.

    Finally, you are better off using 'constructParsedURLData(url)'
rather than calling 'parseURL(url.toExternalForm())'.

+	  // It's relative so base it off baseURL
+	  try {
+	    java.net.URL context = new java.net.URL(baseURL.toString());
+	    java.net.URL url = "" java.net.URL(context, urlStr);
+	    // The following two lines simply verify that the URL is valid.
+	    // Strictly speaking, they are not required, although it allows
+	    // us to have a fallback position.
+	    java.io.InputStream is = url.openStream();
+	    is.close();
+	    pd = parseURL(url.toExternalForm());
+	  }
+	  catch (Exception e) {
+	    pd = super.parseURL(baseURL, urlStr);
+	  }

-- 
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