docbook / xslTNG

DocBook xslTNG Stylesheets
https://xsltng.docbook.org
MIT License
41 stars 20 forks source link

Wrong base-uri when using a preprocessing pipeline? #418

Closed frank-steimke closed 9 months ago

frank-steimke commented 9 months ago

I use the xslTNG Stylesheets 2.1.9 (no-saxon release) within Oxygen. I dont use JAVA, but i am doing a XSLT Transformation with a customization layer, which sets some paramaters and imports xslt/print.xsl. I make use of the pre- and post-processing pipeline as described in Section 5.7 in the Manual. There is a custom stylesheet which acts as a preprocessor, set in transform-original.

I observe errors in handling of image URI, which are given as relative URI in the source. Turning on debug infos i find that the template for mode mp:imagedata in objects.xsl assumes the wrong base-uri property. It seems to be the base uri of the static context, the place where the XSL Stylesheets are found.

When i use the xslt/print.xsl directly (that is: still in Oxygen as XSLT transformation scenario, but without my customization layer and without any preprocessing) everything is fine, and the base-uri is calculated as expected.

Maybe the preprocessing constructs a new document-node and the base-uri from the original sources has vanished?

Greetings, Frank

ndw commented 9 months ago

Do the problems occur if you use your customization outside of Oxygen?

frank-steimke commented 9 months ago

No, i dont think so. It took some time to find out, and i was unable to check with my customization. . My stylesheets require some Saxon EE features, and i dont have a standalone licence, so they dont run outside oxygen. I had to write a simple test scenario especially for this suspected issue. I did that today, and the result is that i can't reproduce the error. Neither outside Oxygen nor within. Maybe my test scenario is to simple, i don't know.

I have a vague suspicion that it might have been a problem with file paths. We work in Windows 10 and had a directory structure where the names of the directories contained german umlaut characters (and whitespace), e. g. intermediäre Plattform/src. It had strange effects when working with xml collections within this directory structure, so we renamed file and directory names and use only ascii characters.

I have to admit that i am not fully convinced. Maybe there is a problem related to the base-uri(). I did observe a very strange effect with dimensions of svg images. In the source file i gave only the imagedata/@width attribute. It showed up correctly in the generated HTML when the @fileref was an absolute path. But when @fileref was given as an relative path, there @width attribute disappeared in the HTML file. I remembered this issue here, and that i saw the comment "This is the very first transformation in a long pipeline, so make sure we have the correct xml:base attribute" somewhere in your sourcecode. So i added the xml:base attribute to the document in my preprocessor ($transform-original), and the problem with the dimensions for svg images was solved. I dont understand neither the problem nor the solution, but it works. I seems to be a good idea to set the @xml:base explicit in the very first stylesheet.

However, since i am unable to reproduce the issue, i will close it now.

Greetings, Frank