From: Nikolai Grigoriev (grig@renderx.com)
Date: Thu Aug 07 2003 - 03:00:47 PDT
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@dspfactory.ch>
To: "XEP Support" <xep-support@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@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@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@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 - 03:00:33 PDT