keep.relative.image.uris 0 being disrespected (???)
Hi, I have a stylesheet customization layer that sets the keep.relative.image.uris parameter to zero. (therfore, they are resolved against xml:base) I verified that the customization layer works by using xsltproc (I have it on the Samba server that hosts my Windows files) on the xml source files and xsl customization layer (and yes, the xml catalog on the server points to docbook-xsl 1.70.1 as the current release). xsltproc --xinclude -o Engineering_Optimization.xhtml ~/.xml/alpha/xhtml.xsl Engineering_Optimization.xml When I transform with oXygen 7.2 and saxon 6.5.5 using the same customization layer (by placing file:/Z:/.xml/alpha/xhtml.xsl in the XSL url field), the file comes out ok, with the exception that the uris have not taken xml:base into account, so they don't point to the correct folder (and thus the images don't show in Firefox). I have tried setting the parameter keep.relative.image.uris to 0 inside oXygen, which doesn't work either. I created my transformation by cloning the DocBook HTML one and editing it to point to my xsl layer along with outputting to ${cfn}.xhtml. I am going to go download the regular Eclipse distribution instead of the Eclipse + Web Platform Tools distribution. If that fixes it, then I'll post to this thread again. -- http://chris.chiasson.name/
Hello Chris, It works for me with oXygen 7.2 and Saxon 6.5.5. If I use the default value 1 for keep.relative.image.uris the value of the graphic/@fileref attribute present in the DocBook source document is preserved as the value of img/@src in the XHTML result. If I set keep.relative.image.uris to 0 and one of the ancestors of graphic/@fileref has an xml:base attribute then the value of the xml:base attribute of the topmost ancestor with this attribute is used as base URL to resolve the graphic/@fileref value. The resolved path is placed in img/@src in the XHTML result as with the default value of keep.relative.image.uris. If there is no ancestor with an xml:base attribute then the graphic/@fileref value is preserved. This algorithm is executed by the template called "relative-uri" in [oXygen-frameworks-folder]/docbook/xsl/common/common.xsl. This is true for both the oXygen standalone distribution and the Eclipse plugin one. Regards, Sorin Chris Chiasson wrote:
Hi, I have a stylesheet customization layer that sets the keep.relative.image.uris parameter to zero. (therfore, they are resolved against xml:base)
I verified that the customization layer works by using xsltproc (I have it on the Samba server that hosts my Windows files) on the xml source files and xsl customization layer (and yes, the xml catalog on the server points to docbook-xsl 1.70.1 as the current release).
xsltproc --xinclude -o Engineering_Optimization.xhtml ~/.xml/alpha/xhtml.xsl Engineering_Optimization.xml
When I transform with oXygen 7.2 and saxon 6.5.5 using the same customization layer (by placing file:/Z:/.xml/alpha/xhtml.xsl in the XSL url field), the file comes out ok, with the exception that the uris have not taken xml:base into account, so they don't point to the correct folder (and thus the images don't show in Firefox).
I have tried setting the parameter keep.relative.image.uris to 0 inside oXygen, which doesn't work either.
I created my transformation by cloning the DocBook HTML one and editing it to point to my xsl layer along with outputting to ${cfn}.xhtml.
I am going to go download the regular Eclipse distribution instead of the Eclipse + Web Platform Tools distribution. If that fixes it, then I'll post to this thread again.
I reinstalled Eclipse from the official page without WPT. It seems oXygen retained its transformations (which makes sense given what George Cristian Bina said about where transformation data is stored). I made new ones from scratch just to be sure. After further reading of the help, it seems that the parameters and default listed in oXygen's transformation dialog are programatically extracted from the referenced xsl stylesheet. I notice that it always lists keep.relative.image.uris as 1, despite what my customization layer says in common.xsl. The transformation still results in broken image uris. I have moved my stylesheets and auxiliary files into a subdirectory of the project and placed the whole thing online (less than 100 KiB uncompressed) at http://chris.chiasson.name/temp/Engineering_Optimization_Documentation/ If a local copy would work better, I also made: http://chris.chiasson.name/temp/Engineering_Optimization_Documentation.zip I included a scenarios.properties file with all of my transformation information. The xml file being transformed is TestHarness.xml. The ./xml/xhtml.xsl file is the one that serves as the entry to the customization layer for unchunked xhtml output. The two transformations I used to create TestHarness.xhtml and TestHarness.html start with the name TestHarness. Does any of this data indicate what I did wrong or what's going wrong? How does the transformation turn out when you use xsltproc directly? On 8/18/06, Sorin Ristache <sorin@oxygenxml.com> wrote:
Hello Chris,
It works for me with oXygen 7.2 and Saxon 6.5.5. If I use the default value 1 for keep.relative.image.uris the value of the graphic/@fileref attribute present in the DocBook source document is preserved as the value of img/@src in the XHTML result. If I set keep.relative.image.uris to 0 and one of the ancestors of graphic/@fileref has an xml:base attribute then the value of the xml:base attribute of the topmost ancestor with this attribute is used as base URL to resolve the graphic/@fileref value. The resolved path is placed in img/@src in the XHTML result as with the default value of keep.relative.image.uris. If there is no ancestor with an xml:base attribute then the graphic/@fileref value is preserved. This algorithm is executed by the template called "relative-uri" in [oXygen-frameworks-folder]/docbook/xsl/common/common.xsl. This is true for both the oXygen standalone distribution and the Eclipse plugin one.
Regards, Sorin
Chris Chiasson wrote:
Hi, I have a stylesheet customization layer that sets the keep.relative.image.uris parameter to zero. (therfore, they are resolved against xml:base)
I verified that the customization layer works by using xsltproc (I have it on the Samba server that hosts my Windows files) on the xml source files and xsl customization layer (and yes, the xml catalog on the server points to docbook-xsl 1.70.1 as the current release).
xsltproc --xinclude -o Engineering_Optimization.xhtml ~/.xml/alpha/xhtml.xsl Engineering_Optimization.xml
When I transform with oXygen 7.2 and saxon 6.5.5 using the same customization layer (by placing file:/Z:/.xml/alpha/xhtml.xsl in the XSL url field), the file comes out ok, with the exception that the uris have not taken xml:base into account, so they don't point to the correct folder (and thus the images don't show in Firefox).
I have tried setting the parameter keep.relative.image.uris to 0 inside oXygen, which doesn't work either.
I created my transformation by cloning the DocBook HTML one and editing it to point to my xsl layer along with outputting to ${cfn}.xhtml.
I am going to go download the regular Eclipse distribution instead of the Eclipse + Web Platform Tools distribution. If that fixes it, then I'll post to this thread again.
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
Hello Chris, The XSLT parameters and their default values are extracted from the stylesheet specified in the scenario in the XSL URL field. If that stylesheet specifies other value than the default value 1 set by the original DocBook stylesheet then that other value is listed in the Parameters dialog as default value. Default value means generally the value of the parameter if you do not set other value explicitly in the Parameters dialog, not the default set by the original DocBook stylesheet. I downloaded http://chris.chiasson.name/temp/Engineering_Optimization_Documentation.zip and I applied your scenarios "TestHarness DocBook HTML" and "TestHarness DocBook XHTML" to TestHarness.xml with oXygen 7.2. I obtained a .html file and a .xhtml file which point to the low DPI images (html role) with correct paths (C:/path/to/Engineering_Optimization_Documentation/mote/*.png). That means the PNG images located in the Engineering_Optimization_Documentation\mout folder are displayed just fine. This happened in both oXygen standalone and in Eclipse. I see that in your files TestHarness.html and TestHarness.xhtml the paths do not contain the mout folder name. How did you generate these files ? Best regards, Sorin Chris Chiasson wrote:
After further reading of the help, it seems that the parameters and default listed in oXygen's transformation dialog are programatically extracted from the referenced xsl stylesheet. I notice that it always lists keep.relative.image.uris as 1, despite what my customization layer says in common.xsl.
The transformation still results in broken image uris.
I wish I could solve this problem :-[ At least the parameter detection routine in oXygen now shows the paramter value I've set, though I don't know why that changed. The TestHarness.html and TestHarness.xhtml were made by executing the TestHarness HTML and XHTML transforms in oXygen. I made a 7 MiB video of me using a tool to generate the XML, verifying the oXygen transformation, executing the transform, viewing the output (which didn't respect xml:base), exporting the project to a temp folder on my website, executing the same transform with xsltproc, and comparing both outputs. I can get xsltproc to work, but not oXygen :-( I am hoping you will watch the video and be able to catch whatever I might have messed up. http://chris.chiasson.name/temp/C38951408874-transcoded.avi http://chris.chiasson.name/temp/Engineering_Optimization_Documentation.zip http://chris.chiasson.name/temp/Engineering_Optimization_Documentation/ Thanks, On 8/22/06, Sorin Ristache <sorin@oxygenxml.com> wrote:
Hello Chris,
The XSLT parameters and their default values are extracted from the stylesheet specified in the scenario in the XSL URL field. If that stylesheet specifies other value than the default value 1 set by the original DocBook stylesheet then that other value is listed in the Parameters dialog as default value. Default value means generally the value of the parameter if you do not set other value explicitly in the Parameters dialog, not the default set by the original DocBook stylesheet.
I downloaded
http://chris.chiasson.name/temp/Engineering_Optimization_Documentation.zip
and I applied your scenarios "TestHarness DocBook HTML" and "TestHarness DocBook XHTML" to TestHarness.xml with oXygen 7.2. I obtained a .html file and a .xhtml file which point to the low DPI images (html role) with correct paths (C:/path/to/Engineering_Optimization_Documentation/mote/*.png). That means the PNG images located in the Engineering_Optimization_Documentation\mout folder are displayed just fine. This happened in both oXygen standalone and in Eclipse. I see that in your files TestHarness.html and TestHarness.xhtml the paths do not contain the mout folder name. How did you generate these files ?
Best regards, Sorin
Chris Chiasson wrote:
After further reading of the help, it seems that the parameters and default listed in oXygen's transformation dialog are programatically extracted from the referenced xsl stylesheet. I notice that it always lists keep.relative.image.uris as 1, despite what my customization layer says in common.xsl.
The transformation still results in broken image uris.
oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
To the other people on the list - please don't download that video if you are just curious - my server only has 70 KiB/s upstream bandwidth (but it is a business line, so I am not violating my service agreement). -- http://chris.chiasson.name/
Hello Chris, I think I finally figured out what you did wrong. Your movie does not show it but the only change in my configuration which duplicates your error (the XInclude is resolved but the base URI is not correct in the included fragment) is to enable XInclude processing in Preferences *but disable Base URI fix-up*. Can you check please that Base URI fix-up is also enabled in Options -> Preferences -> XML / XML Parser ? I do not really understand why you would want to disable it. When you enable XInclude the two related options are also enabled by default (Base URI fix-up and Language fix-up) so I think you disabled Base URI fix-up manually by unchecking the checkbox. Best regards, Sorin Chris Chiasson wrote:
I wish I could solve this problem :-[
At least the parameter detection routine in oXygen now shows the paramter value I've set, though I don't know why that changed.
The TestHarness.html and TestHarness.xhtml were made by executing the TestHarness HTML and XHTML transforms in oXygen.
I made a 7 MiB video of me using a tool to generate the XML, verifying the oXygen transformation, executing the transform, viewing the output (which didn't respect xml:base), exporting the project to a temp folder on my website, executing the same transform with xsltproc, and comparing both outputs. I can get xsltproc to work, but not oXygen :-(
I am hoping you will watch the video and be able to catch whatever I might have messed up.
http://chris.chiasson.name/temp/C38951408874-transcoded.avi
http://chris.chiasson.name/temp/Engineering_Optimization_Documentation.zip
http://chris.chiasson.name/temp/Engineering_Optimization_Documentation/
Thanks,
On 8/22/06, Sorin Ristache <sorin@oxygenxml.com> wrote:
Hello Chris,
The XSLT parameters and their default values are extracted from the stylesheet specified in the scenario in the XSL URL field. If that stylesheet specifies other value than the default value 1 set by the original DocBook stylesheet then that other value is listed in the Parameters dialog as default value. Default value means generally the value of the parameter if you do not set other value explicitly in the Parameters dialog, not the default set by the original DocBook stylesheet.
I downloaded
http://chris.chiasson.name/temp/Engineering_Optimization_Documentation.zip
and I applied your scenarios "TestHarness DocBook HTML" and "TestHarness DocBook XHTML" to TestHarness.xml with oXygen 7.2. I obtained a .html file and a .xhtml file which point to the low DPI images (html role) with correct paths (C:/path/to/Engineering_Optimization_Documentation/mote/*.png). That means the PNG images located in the Engineering_Optimization_Documentation\mout folder are displayed just fine. This happened in both oXygen standalone and in Eclipse. I see that in your files TestHarness.html and TestHarness.xhtml the paths do not contain the mout folder name. How did you generate these files ?
Best regards, Sorin
Chris Chiasson wrote:
After further reading of the help, it seems that the parameters and default listed in oXygen's transformation dialog are programatically extracted from the referenced xsl stylesheet. I notice that it always lists keep.relative.image.uris as 1, despite what my customization layer says in common.xsl.
The transformation still results in broken image uris.
oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
You are right. I must have disabled it :-[ After enabling it, the images showed up just fine. I feel bad for taking up so many resources to solve such a simple problem. Does SyncRO Soft/oXygen have a donation link? On 8/23/06, Sorin Ristache <sorin@oxygenxml.com> wrote:
Hello Chris,
I think I finally figured out what you did wrong. Your movie does not show it but the only change in my configuration which duplicates your error (the XInclude is resolved but the base URI is not correct in the included fragment) is to enable XInclude processing in Preferences *but disable Base URI fix-up*. Can you check please that Base URI fix-up is also enabled in Options -> Preferences -> XML / XML Parser ? I do not really understand why you would want to disable it. When you enable XInclude the two related options are also enabled by default (Base URI fix-up and Language fix-up) so I think you disabled Base URI fix-up manually by unchecking the checkbox.
Best regards, Sorin
Chris Chiasson wrote:
I wish I could solve this problem :-[
At least the parameter detection routine in oXygen now shows the paramter value I've set, though I don't know why that changed.
The TestHarness.html and TestHarness.xhtml were made by executing the TestHarness HTML and XHTML transforms in oXygen.
I made a 7 MiB video of me using a tool to generate the XML, verifying the oXygen transformation, executing the transform, viewing the output (which didn't respect xml:base), exporting the project to a temp folder on my website, executing the same transform with xsltproc, and comparing both outputs. I can get xsltproc to work, but not oXygen :-(
I am hoping you will watch the video and be able to catch whatever I might have messed up.
http://chris.chiasson.name/temp/C38951408874-transcoded.avi
http://chris.chiasson.name/temp/Engineering_Optimization_Documentation.zip
http://chris.chiasson.name/temp/Engineering_Optimization_Documentation/
Thanks,
On 8/22/06, Sorin Ristache <sorin@oxygenxml.com> wrote:
Hello Chris,
The XSLT parameters and their default values are extracted from the stylesheet specified in the scenario in the XSL URL field. If that stylesheet specifies other value than the default value 1 set by the original DocBook stylesheet then that other value is listed in the Parameters dialog as default value. Default value means generally the value of the parameter if you do not set other value explicitly in the Parameters dialog, not the default set by the original DocBook stylesheet.
I downloaded
http://chris.chiasson.name/temp/Engineering_Optimization_Documentation.zip
and I applied your scenarios "TestHarness DocBook HTML" and "TestHarness DocBook XHTML" to TestHarness.xml with oXygen 7.2. I obtained a .html file and a .xhtml file which point to the low DPI images (html role) with correct paths (C:/path/to/Engineering_Optimization_Documentation/mote/*.png). That means the PNG images located in the Engineering_Optimization_Documentation\mout folder are displayed just fine. This happened in both oXygen standalone and in Eclipse. I see that in your files TestHarness.html and TestHarness.xhtml the paths do not contain the mout folder name. How did you generate these files ?
Best regards, Sorin
Chris Chiasson wrote:
After further reading of the help, it seems that the parameters and default listed in oXygen's transformation dialog are programatically extracted from the referenced xsl stylesheet. I notice that it always lists keep.relative.image.uris as 1, despite what my customization layer says in common.xsl.
The transformation still results in broken image uris.
oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
participants (2)
-
Chris Chiasson -
Sorin Ristache