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

[Nikolai Grigoriev]

Johann,

>  generate [output-format pdf][page-number 1]error: formatting failed:
> java.lang.NullPointerException

Yes, it is indeed a bug in XEP's PDF generator related to recent
URI unescaping changes: the exception is thrown when the fragment
identifier is missing. A fix is easy, and will be ready within days.
As a quick workaround, you can simply add a hash mark to your
file URLs to denote an empty fragment identifier:

"url(file://file.test#)"

> I also tried http:// URL's like "url(http://www.somedomain.that.does.not.exist)",
> but these didn't pose any problem.

File URLs are treated very differently from all other URLs: XEP PDF generator
produces a "remote go-to action" for them (i.e. a PDF-to-PDF jump). For other
URL types, an "URI action" is produced - the target file is opened in a browser.
This part is not affected by the bug.

Best regards,
Nikolai Grigoriev
RenderX

----- Original Message -----
From: "Johann Richard" <Johann.richard at dspfactory.ch>
To: "XEP Support" <xep-support at renderx.com>
Sent: Thursday, August 07, 2003 12:24 PM
Subject: [xep-support] XEP 3.5.3 basic-link failure for file:// URL's


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

********************************************
Johann Richard
IC & DSP Design Engineer
Dspfactory SA
Champs-Montants 12a
2074 Marin-Epagnier
Switzerland

Tel: +41 32 755 7400
Fax: +41 32 755 7401
e-mail: mailto:johann.richard at dspfactory.ch

http://www.dspfactory.com
********************************************
 <>< Re: deemed!

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo at 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

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo at 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