From: Kenneth J. Hughes (kjh@entel.com)
Date: Wed Jan 21 2004 - 12:06:08 PST
I'm using the latest versions of XEP (3.7.1) and XEPTask (1.3).
I've found that if I change the form of the URL in the input file,
I can resolve the problem. Consider the following two forms of
the specification of a relative URL:
(1) background-image="url(file:../graphics/smile.gif)"
(2) background-image="url(../graphics/smile.gif)"
Form 1 may well be wrong, but it was confusing in that it worked with
an ant java task calling XSLDriver but failed with the ant xep task.
Form 2 works with both.
Attached is a small test case that demonstrates the above results.
I'm happy to use form 2. I just wanted to follow-up for the benefit
of anyone who happens across this thread with a similar problem.
Thanks for your help, Alexander.
Cheers,
Ken
At 12:16 AM 1/21/2004, Alexander Peshkov wrote:
>Hello Kenneth,
>
>I was not able to reproduce your problem. Everything is working as
>expected at my side. What version of XEP are you using? Do you have
>latest version of XEP Ant Task? Could you please report values of
>${base.dir} and ${xep.dir}, path to the directory from which Ant was
>run and all the log messages issued by XEP?
>
>Best regards,
>Alexander Peshkov mailto:peshkov@renderx.com
>RenderX
>
>
>KJH> Hi Alexander, thanks for your reply.
>
>KJH> I agree with everything you write, yet I still am observing that XEP,
>KJH> when used via the xep ant task, is trying to resolve URLs (graphics in
>KJH> particular) relative to the location from which ant is run rather than
>KJH> relative to the location of the FO input document.
>
>KJH> Using an ant target such as the following,
>
>KJH> <target name="pdf" depends="fo">
>KJH> <xep format="PDF">
>KJH> <classpath refid="xep-classpath"/>
>KJH> <sysproperty key="com.renderx.xep.ROOT" value="${xep.dir}"/>
>KJH> <sysproperty key="com.renderx.xep.BASE" value="${base.dir}"/>
>KJH> <fileset dir="${base.dir}">
>KJH> <include name="*.fo"/>
>KJH> </fileset>
>KJH> </xep>
>KJH> </target>
>
>KJH> I'm seeing an error, "Failed to create image," where the message goes
>KJH> on to explain that the graphic file did not exist relative to the
>KJH> directory from which ant was run. I believe that it should be trying
>KJH> to resolve it relative to the location of the FO file in which the URL
>KJH> exists.
>
>KJH> Am I wrong?
>
>KJH> Cheers,
>
>KJH> Ken
>
>
>KJH> At 12:23 AM 1/20/2004, Alexander Peshkov wrote:
>>>Hello Kenneth,
>>>
>>>XSL FO spec prescribes that relative URLs within the doc should be
>>>resolved with respect to the location of the document. For the cases
>>>when the source document has no systemId (i.e. it was created in
>>>memory) we provide special facility - BASE property that defines basic
>>>directory for such a files. As it is clearly stated in "XEP User
>>>Guide", it's applicable only for the files without systemId.
>>>There is another feature that allows you explicitly define base
>>>directory for the URL resolution inside given FO file - it is xml:base
>>>property. This property makes effect no matter if systemId is present
>>>or not. Setting its value using XSLT stylesheet parameter at the
>>>transformation stage proved to be quite convenient.
>>>
>>>Best regards,
>>>Alexander Peshkov mailto:peshkov@renderx.com
>>>RenderX
>>>
>>>KJH> I expected that setting com.renderx.xep.BASE would cause relative URL
>>>KJH> references within the input file (to images, for example) to be
>>>KJH> resolved relative to its value, however I'm not seeing that. It
>>>KJH> appears that BASE is only being used to determine the input file
>>>KJH> locations. Should it not also be used to resolve relative URLs within
>>>KJH> the doc? If not, what's the proper way of telling XEP that relative
>>>KJH> URLs are to be resolved with respect to the directory of the document
>>>KJH> that contains the URL?
>>>
>>>KJH> If I forgo the xep ant task and instead set the dir attribute on a
>>>KJH> java task calling XEP directly, input files and their containing
>>>KJH> relative URLs do resolve successfully. However, to make that approach
>>>KJH> work from ant over a directory of input files is messy and
>>>KJH> inefficient; the xep ant task handles that better.
>>>
>>>KJH> Thanks for any answers or suggestions.
>>>
>>>KJH> Cheers,
>>>
>>>KJH> Kenneth J. Hughes kjh@entel.com
>>>KJH> Entelechy Corporation http://www.entel.com/
>>>
>>>KJH> -------------------
>>>KJH> (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
>>>KJH> in the body of the message to majordomo@renderx.com from the address
>>>KJH> you are subscribed from.
>>>KJH> (*) 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
>
>KJH> -------------------
>KJH> (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
>KJH> in the body of the message to majordomo@renderx.com from the address
>KJH> you are subscribed from.
>KJH> (*) 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
-------------------
(*) 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 : Wed Jan 21 2004 - 12:19:11 PST