[xep-support] XEPTask: BASE for resolving contained URLs?

[Kenneth J. Hughes]

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 at 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 at 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 at 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 at 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 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 
>
>KJH> -------------------
>KJH> (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
>KJH> in the body of the message to majordomo at 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 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 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XEPTaskDirProblem.zip
Type: application/zip
Size: 8838 bytes
Desc: not available
URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20040121/33f36ee1/attachment.zip>