Relative paths

[EricR]

I've been using Docbook 5.0 with XIncludes to create a very nested document so as to avoid repetitive work especially with screenshots etc.

When processing this the text comes out just fine. However the images are not coming out. I know why but I don't know how to fix it.

This is not the problem of loading the additional libraries to support PNG images in PDF.

The requirement is to locate the image file in the same directory as it is used. There are many images (100's) which potentially all have the same name but are distinguished by their position in the path hierarchy.

If I transform from the directory where the images live then all is OK but if I transform from above that or adjacent to it, then the images do not come out. In fact they are included as if there are in the current directory.

For example :-

Code: Select all

<mediaobject>

	<imageobject>

		<imagedata fileref="rs-001.png"></imagedata>

	</imageobject>

</mediaobject>

Now, I know that a relative fileref processed with XInclude and with the parameter keep.relative.image.uris="0" is changed to account for any xml:base attributes. I also know that there is a preference to enable or disable the base URI fixup.

However, all permutations seem to fail in one way or another.

If 'Base URI fix-up' is ticked and keep.relative.image.uris is '1' the image location is the document root.

If 'Base URI fix-up' is ticked and keep.relative.image.uris is '0' the image location is the pathname twice, i.e. one appended after the other.

If 'Base URI fix-up' is unticked and keep.relative.image.uris is '0' the image location is the document root.

If 'Base URI fix-up' is unticked and keep.relative.image.uris is '1' the image location is the document root.

Is there something else I should be doing?

[sorin_ristache]

Hello,

The requirement is to locate the image file in the same directory as it is used. There are many images (100's) which potentially all have the same name but are distinguished by their position in the path hierarchy.

...

all permutations seem to fail in one way or another.

...

If 'Base URI fix-up' is ticked and keep.relative.image.uris is '0' the image location is the pathname twice, i.e. one appended after the other.

Taking your requirement into account the xml:base value that results from the inclusion should not be ignored so this is the permutation that you should use: Base URI fix-up selected and the DocBook parameter keep.relative.image.uris set to the default value (zero). In versions older than 9.3 the path was not computed correctly starting from the second level of inclusion (you said you had a very nested document). The cause was a Xerces bug which we reported to the Xerces team and which we fixed in Oxygen 9.3 (the current version available on the Download page). What Oxygen version do you use?

Is there something else I should be doing?

Use Oxygen version 9.3 which fixes the Xerces bug. If version 9.3 does not use the image file from the same directory as the included XML file which points to this image I can send you my test files with 4 levels of inclusion or you can post sample files for reproducing the problem.


Regards,
Sorin

[EricR]

I am now using v9.3 build 2008070211.

That solved it.

One thing; I note that the default value of keep.relative.image.uris for PDF output is 0 but for HTML is it 1. I think this is in line with the spec but I don't see the logic behind it.

[sorin_ristache]

I see that the default value of keep.relative.image.uris is 1 for HTML output but I agree that it seems strange.


Regards,
Sorin