I've looked into the code and can give more specifics as to what actually goes wrong in my case. Spoiler: It's not what I originally thought…
The issue arises when source and output files are passed in a 'file:' URL like file:///path/to/file.xml instead of the equivalent file:/path/to/file.xml What then happens in chunk-cleanup.xsl, template for "h:head/h:link[@href]", is that there's a call (in my case) of fp:relative-uri( 'file:///Users/chris/dev/workspace/roundtrip/ignore/build/dist/doc/manual/html/upl-2.xml', 'file:///Users/chris/dev/workspace/roundtrip/ignore/build/dist/doc/manual/html/upl-2.xml', './my.css' ) which results in a "relativized" value of '../../../../../../../../../../../../../Users/chris/dev/workspace/roundtrip/ignore/build/dist/doc/manual/html/my.css' for the link/@href attribute. Note that it goes 13(!) steps up, but then only 11 down. The reason why this happens - at least, as far as I could track it down - is that somewhere in that function, *one* input parameter is normalized by resolve-uri() to 'file:/Users/chris/Beruf/infinity-loop/dev/workspace/roundtrip/ignore/build/dist/doc/manual/html/my.css' which is then prefix token-matched against 'file:///Users/chris/Beruf/infinity-loop/dev/workspace/roundtrip/ignore/build/dist/doc/manual/html/upl-2.xml' where the tokens are generated by splitting the string at '/'. Because the former string now has only one slash after its protocol, prefixes no longer match already right after the protocol name, hence the awkward relativization result shown above (with two erroneous, bogus step ups added for the double slashes of the empty host spec). One idea to resolve this would be to - early in the xslTNG stylesheets - normalize equivalent "file:" base uris to a common form so that string-based prefix matching works, but I'm not confident in doing this. Any suggestions on how to resolve (I don't know if this should be considered a bug) this issue? Thanks, Christian > On 1. Apr 2021, at 23:22, Christian Roth <r...@visualclick.de> wrote: > > Hello, > > using I'm using xslTNG. > > How do I pass the link to my CSS stylesheet override verbatimly to the output? > > E.g., > > $css-links := "my.css" > > should result in > > <link href="my.css" rel="stylesheet"> > > in the final output. However, since DocBook source XML and transformation > output file live in different directories, the xslTNG stylesheets try to be > smart and do a fixup on the the relative link "my.css" so that it works from > the destination location, pointing to the source folder. Since I do copy all > needed resources to the destination location, there's no fixup to do for the > stylesheets at this place. > > I tried > > $css-links := "file:my.css" > > which works - however only as long as I'm opening the file locally. After > uploading the file to my webserver, the 'file:' protocol of course won't work. > > Is there a parameter to prevent this URL fixup, or how do I need to specify > the $css-links parameter to result in my desired output? > > > Thanks, Christian --------------------------------------------------------------------- To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
