Let me see if I understand this. For both PDF and HTML outputs, you first resolve
your XIncludes using xmllint --xinclude and save that to a temporary file. Then you
process that file with either xsltproc or Xalan or Saxon to format the output. Is
that the situation?
If so, then I'm not understanding how you are getting different paths from xsltproc
and Saxon/Xalan. I would expect different paths if you were using different
processors to resolve the XIncludes, because my experience has shown that different
XInclude resolvers sometimes produce different xml:base attributes for the resolved
elements. But in your case, the XIncludes are resolved first, and you say the
xml:base attributes are correct. Saxon and xsltproc should produce the same result
from that point on.
Can you send me a short resolved XML with xml:base attributes, and a list of the
processor versions you are running?
Bob Stayton
Sagehill Enterprises
[email protected]
----- Original Message -----
From: "Georges Schmitz" <[email protected]>
To: <[email protected]>
Sent: Tuesday, May 11, 2010 2:55 AM
Subject: [docbook-apps] relative paths in HTML generation with xinclude and
figures
We work with a modular structure and are reusing content many times.
/doc
|_ /app
| | chapter1.xml ...
| | tb-audit-icon-overview-tree.xml
| |_ /images
| |_ /icons
|
|_ /oas
| | book.xml
| | intro.xml
| | chapter1.xml ...
| | ax-icon-overview.xml
| |_ /images
| |_ /icons
|
|_ /fstd
| | book.xml
In the appendix chapter ax-icon-overview.xml of "oas" I xinclude the file
../app/tb-audit-icon-overview-tree.xml which contains references to "app"
icons. After resolving book.xml in "oas" with the latest xmllint version I also
get a correct xml:base="../app/tb-audit-icon-overview-tree.xml".
Now the facts:
FO -> PDF everything fine concerning image inclusion.
HTML with keep.relative.image.uris=1 produces incorrect relative paths for the
"app" icons
<img src="images/icons/treeNodeAuditInitial.png"/>
when using xalan 2.7 or saxon 6.5.5. Only xsltproc gives me
<img src="../app/images/icons/treeNodeAuditInitial.png"/>
With keep.relative.image.uris=0 the resulting absolute paths to the image files
are all correct, but they are of no new use because JavaHelp is to be generated
afterwards.
So I really wonder how xsltproc manages to get the relative paths correctly
calculated, because I can't see a distinction between html or fo processing in
common.xsl when xsl:template "relative-uri" is called from graphics.xsl.
Thanks for clarification on this issue (which is chasing me since 5 years every
now and then in different constellations). Unfortunately xsltproc is not THE
solution for me because of other problems we have with it.
Kind regards,
Georges
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
