Re: [xep-support] XEP 3.5.3 basic-link failure for file:// URL's

From: Werner Donné (werner.donne@re.be)
Date: Thu Aug 07 2003 - 02:38:37 PDT

  • Next message: i.de.jong@everest.nl: "Re: [xep-support] XEP 3.5.3 basic-link failure for file:// URL's"

    Johann,

    Looking at the URI grammar in RFC2396, I think the following rules reply to the two
    examples:

    absoluteURI = scheme ":" ( hier_part | opaque_part )
    hier_part = ( net_path | abs_path ) [ "?" query ]
    net_path = "//" authority [ abs_path ]
    abs_path = "/" path_segments

    Therefore, it seems to me that file://file.test should be either file:///file.test
    (net_path with empty authority) or file:/file.test (abs_path).

    In the example file:///\\someserver\somefolder\myfile.xml the authority is someserver.
    This would then result in the URL file://someserver/somefolder/my.xml (net_path). It
    is up to the file scheme handler on Windows to interpret this URL and convert it to
    the path name \\someserver\somefolder\myfile.xml.

    Regards,

    Werner.

    Johann Richard wrote:
    > Hello,
    >
    > I upgraded to XEP 3.5.3 (Cleint Stamped) and observed the following behaviour:
    >
    > My setup:
    >
    > OS: Windows 2000
    > java version "1.4.0"
    > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
    > Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
    >
    > Same on Mac OS X 10.2.6 (Jaguar) w/ latest JVM (don't remember the version, though (1.4.x))
    >
    > When I use DocBook stylesheets to produce PDf, using <ulink/> elements to local files (file://), XEP will crash, typically with the following Exception:
    >
    >
    > generate [output-format pdf][page-number 1]error: formatting failed: java.lang.NullPointerException
    >
    >
    > A typical fo:basic-link that causes such problems looks like the following:
    >
    > <fo:basic-link
    > external-destination="url(file:///\\someserver\somefolder\myfile.xml)">my basic link</fo:basic-link>
    >
    > Other file:// URL's like "url(file://file.test)" also failed, so I guess it's not the backslashes ... :)
    >
    > I also tried http:// URL's like "url(http://www.somedomain.that.does.not.exist)", but these didn't pose any problem.
    >
    > I think this might be a problem with the revised URL escaping, but of course, this is just an assumption.
    >
    > If you need some FO evidence, just le me know.
    >
    > Best regards,
    > Johann Richard 

    -- 
Werner Donné  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
-------------------
(*) 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/tos.html

    This archive was generated by hypermail 2.1.5 : Thu Aug 07 2003 - 02:40:45 PDT