Bug 44902 - FOP 0.95 does not resolve server path names.
Summary: FOP 0.95 does not resolve server path names.
Status: CLOSED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: all
Hardware: PC Windows XP
: P1 normal
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
: 45100 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-29 06:16 UTC by Sudesna Pati
Modified: 2012-04-01 07:07 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sudesna Pati 2008-04-29 06:16:14 UTC
When we work with our stylesheets to load images, FOP 0.95 works well with local drive addresses,but does not work with server drive addresses. For your convenience in understanding, let me give you a code snippet:

What works using fop0.95:

(network share connected via command net use Z: \\Dimari-server4\variobill):
 
<fo:block>
 <fo:external-graphic scaling="inherit" height="4.0cm" width="21cm" src="Z:\shared\images\Briefkopf2005_08.PNG"/>
</fo:block>



What does not work:

<fo:block>
 <fo:external-graphic scaling="inherit" height="4.0cm" width="21cm" src="\\Dimari-server4\variobill\shared\images\Briefkopf2005_08.PNG"/>
</fo:block>

So it is not able to resolve the server names. Drive like one with \\,u drive, c drive does no more work with the old stylesheets. But this problem never occured with the old version of fop.
Comment 1 J.Pietschmann 2008-04-29 14:45:48 UTC
The src attribute of an external graphic takes an URL. Both Z:\shared\images\Briefkopf2005_08.PNG and \\Dimari-server4\variobill\shared\images\Briefkopf2005_08.PNG are file names, not URLs, and technically invalid as the value for a src attribute. Because many people are somewhat sloppy distinguishing the two concepts, FOP attempts to detect and convert file names to URLs. This is messy for Windows file names, and apparently nobody bothered yet to extend the usual hacks to include the conversion of UNC paths.
The correct value to use in the second case should probably be file:////Dimari-server4\variobill\shared\images\Briefkopf2005_08.PNG (note: exactly four slashes after the file: prefix), but this may be unsupported by the underlying library.

I'm tempted to close this as invalid, but someone else may want to add UNC uplifting to the URL processing code.
Comment 2 Andreas L. Delmelle 2008-05-29 10:16:36 UTC
*** Bug 45100 has been marked as a duplicate of this bug. ***
Comment 3 Andreas L. Delmelle 2008-05-31 03:11:11 UTC
*** Bug 45100 has been marked as a duplicate of this bug. ***
Comment 4 Andreas L. Delmelle 2008-05-31 14:32:23 UTC
Additional info, as I've been looking at what can be done at the FOP-side to solve this issue.

AFAICT, currently the specified URL for the 'src' property is passed as-is to the XG Commons ImageManager. I assume Commons uses standard java.net.URL operations when it tries to open the stream, so it seems to be a question of whether the following would work:

new java.net.URL("file:////servername/dir/image.png").openStream();

If you can find a variant for which the above works, then the same string-value should work if specified in the FO.
Comment 5 Jeremias Maerki 2008-06-02 10:01:23 UTC
It was an issue of Apache Commons IO's FileUtils.toFile(URL) not supporting file URLs constructed from UNC paths. With the change below I'm able to access files via UNC paths.

Change in XML Graphics Commons Trunk:
http://svn.apache.org/viewvc?rev=662487&view=rev

BTW, it's interesting to note that File.toURL().toExternalForm() yields:
file://myserver/myshare/mypath/myfile.bmp
And File.toURI().toASCIIString() yields:
file:////myserver/myshare/mypath/myfile.bmp
Comment 6 Glenn Adams 2012-04-01 07:07:05 UTC
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed