XSLTHL with DocBook on oXygen 14 (built-in support throws error)
Hi, With the latest oXygen 14.0, I tried to use XSLTHL with DocBook. So I created a simple DocBook article using the built-in oXygen template. I added a programlisting with a language="xml" attribute. A complete example is: When I run the built-in DocBook to PDF scenario, I get an error. If I duplicate it and disable FOP processing (to keep just the XSL-FO as the output), I have something like the following: <fo:block ...> <http://xslthl.sf.net:tag xmlns:http://xslthl.sf.net="xslthl"><hello></http://xslthl.sf.net:tag>World!<http://xslthl.sf.net:tag xmlns:http://xslthl.sf.net="xslthl"></hello></http://xslthl.sf.net:tag> </fo:block> That is, it seems like at some point, the piece of code that is generating (or serializing?) the above element is mixing up the xslthl prefix and the URI "http://xslthl.sf.net". If you replace each of them by the other (prefix and URI), you get the following (I guess correct) element: <fo:block ...> <xslthl:tag xmlns:xslthl="http://xslthl.sf.net"><hello></xslthl:tag>World!<xslthl:tag xmlns:xslthl="http://xslthl.sf.net"></hello></xslthl:tag> </fo:block> I've tried to track it a bit further down using the debugger, but could not find anything more, really. Do you have any idea? Did I miss anything? Regards, -- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/
On 2.7.2012 16:46, Florent Georges wrote:
With the latest oXygen 14.0, I tried to use XSLTHL with DocBook. So I created a simple DocBook article using the built-in oXygen template. I added a programlisting with a language="xml" attribute. A complete example is:
When I run the built-in DocBook to PDF scenario, I get an error. If I duplicate it and disable FOP processing (to keep just the XSL-FO as the output), I have something like the following:
I've tried to track it a bit further down using the debugger, but could not find anything more, really. Do you have any idea? Did I miss anything?
Hi, I don't have v14 installed yet. Is Saxon6.5x set as a transformation engine? Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member ------------------------------------------------------------------
Jirka Kosek wrote Hi Jirka,
I don't have v14 installed yet. Is Saxon6.5x set as a transformation engine?
Yes, 6.5.5 precisely. I did not think it could matter, but I've just tested with 13.2 and it works well with the exact same file... So 14.0 seems definitely to have changed something... Regards, -- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/
Hi, In version 14.0 the built-in frameworks like Docbook, DITA, etc use the editor variable ${frameworkDir} in the values of some XSLT parameters but version 13.2 used ${frameworks}/docbook, ${frameworks}/dita, etc. For example the Docbook transformations have a parameter highlight.xslthl.config=${frameworkDir}/xsl/highlighting/xslthl-config.xml The problem is that ${frameworkDir} is not good for all parameters because it is expanded to a filepath. In this case the ${framework} variable should be used for expanding it to a URL: highlight.xslthl.config=${framework}/xsl/highlighting/xslthl-config.xml Please edit the Docbook scenarios from Options -> Preferences -> Document Type Association -> Docbook -- Edit -- Transformations and change the value of the highlight.xslthl.config parameter. We will apply this change in the next maintenance build of Oxygen 14.0. Regards, Sorin Florent Georges wrote:
Hi,
With the latest oXygen 14.0, I tried to use XSLTHL with DocBook. So I created a simple DocBook article using the built-in oXygen template. I added a programlisting with a language="xml" attribute. A complete example is:
When I run the built-in DocBook to PDF scenario, I get an error. If I duplicate it and disable FOP processing (to keep just the XSL-FO as the output), I have something like the following:
<fo:block ...> <http://xslthl.sf.net:tag xmlns:http://xslthl.sf.net="xslthl"><hello></http://xslthl.sf.net:tag>World!<http://xslthl.sf.net:tag xmlns:http://xslthl.sf.net="xslthl"></hello></http://xslthl.sf.net:tag> </fo:block>
That is, it seems like at some point, the piece of code that is generating (or serializing?) the above element is mixing up the xslthl prefix and the URI "http://xslthl.sf.net". If you replace each of them by the other (prefix and URI), you get the following (I guess correct) element:
<fo:block ...> <xslthl:tag xmlns:xslthl="http://xslthl.sf.net"><hello></xslthl:tag>World!<xslthl:tag xmlns:xslthl="http://xslthl.sf.net"></hello></xslthl:tag> </fo:block>
I've tried to track it a bit further down using the debugger, but could not find anything more, really. Do you have any idea? Did I miss anything?
Regards,
Sorin Ristache wrote: Hi Sorin, Thanks for your response.
highlight.xslthl.config=${framework}/xsl/highlighting/xslthl-config.xml Please edit the Docbook scenarios [...]
I did. Unfortunately, I still have the same problem. Just to be sure the file is correctly found, I added an xsl:message to fo/profile-docbook.xsl in order to output the value of the param: ${framework}/xsl/highlighting/xslthl-config.xml See? It hasn't been expanded. If I change it to ${frameworkDir}, I get an error (which by the way says it has been generated by an xsl:message, but does not point to the coresponding stylesheet). Finally, if I change it to ${frameworks}/docbook/, then everything looks fine now. So it seems there is something wrong with the expanding of the current framework dir (either as a URI or a path), but I am not blocked anymore. Thanks! Regards, -- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/
Hi, Did Oxygen display a warning message about write permissions on the .framework file when you tried to edit the built-in document type? Do you run Oxygen on Windows? In Windows Vista and Windows 7 usually the C:\Program Files folder is read-only, the .framework file cannot be edited so Oxygen displays this warning message and creates a duplicate framework with the same settings and replaces automatically ${framework} and ${frameworkDir} with ${frameworks}/name_of_framework_folder, in your case ${frameworks}/docbook. This replace operation is necessary because the duplicate framework will be stored in the user options, not in a .framework file. Creating a duplicate framework is enough for you for fixing the error. The alternative is to edit the docbook5.framework file (or the docbook4.framework file), replace the ${frameworkDir} variable with ${framework} and use the built-in Docbook framework. This is the modification that we will include in the next maintenance build. Regards, Sorin Florent Georges wrote:
Sorin Ristache wrote:
Hi Sorin,
Thanks for your response.
highlight.xslthl.config=${framework}/xsl/highlighting/xslthl-config.xml Please edit the Docbook scenarios [...]
I did. Unfortunately, I still have the same problem. Just to be sure the file is correctly found, I added an xsl:message to fo/profile-docbook.xsl in order to output the value of the param:
${framework}/xsl/highlighting/xslthl-config.xml
See? It hasn't been expanded. If I change it to ${frameworkDir}, I get an error (which by the way says it has been generated by an xsl:message, but does not point to the coresponding stylesheet).
Finally, if I change it to ${frameworks}/docbook/, then everything looks fine now. So it seems there is something wrong with the expanding of the current framework dir (either as a URI or a path), but I am not blocked anymore. Thanks!
Regards,
Hi Sorin, Well, this is not a right issue, because the scenario IS updated, but the variable reference in the updated value is not expanded if I log it from within the XSLT (but because I see the new value, I know the scenario has been updated). I am on "Windows 7 Enterprise, Service Pack 1", oXygen is installed in c:/apps/oxygen-14.0/ (precisely because I don't have admin rights to install it on Program Files). I did try to restart oXygen, just in case, but the behavior is the same. I am not quite sure what more info I can provide. As I said, I am not blocked anymore (by using ${frameworks}/docbook/ instead of ${framework}), so I don't care to pursue this one if you want to leave it there, but I am glad to help you further if you want to resolve it. But then you'll have to ask me what to do :-) By the way, I am going to activate logging, just to be sure there is nothing interesting in there. But it is so much pain to activate it (looking for an example on the Internet, download it, create the file, adapt it, and last but not least, restart oXygen). It would be sooo handy to have a preference panel dedicated to logging (enable/disable button, levels, even maybe introspecting existing logger names...) But that's another story ;-) Regards, -- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/ ----- Mail original -----
De : Sorin Ristache À : Florent Georges Cc : oXygen User ML Envoyé le : Mardi 3 juillet 2012 13h09 Objet : Re: [oXygen-user] XSLTHL with DocBook on oXygen 14 (built-in support throws error)
Hi,
Did Oxygen display a warning message about write permissions on the .framework file when you tried to edit the built-in document type? Do you run Oxygen on Windows? In Windows Vista and Windows 7 usually the C:\Program Files folder is read-only, the .framework file cannot be edited so Oxygen displays this warning message and creates a duplicate framework with the same settings and replaces automatically ${framework} and ${frameworkDir} with ${frameworks}/name_of_framework_folder, in your case ${frameworks}/docbook. This replace operation is necessary because the duplicate framework will be stored in the user options, not in a .framework file.
Creating a duplicate framework is enough for you for fixing the error. The alternative is to edit the docbook5.framework file (or the docbook4.framework file), replace the ${frameworkDir} variable with ${framework} and use the built-in Docbook framework. This is the modification that we will include in the next maintenance build.
Regards, Sorin
Florent Georges wrote:
Sorin Ristache wrote:
Hi Sorin,
Thanks for your response.
highlight.xslthl.config=${framework}/xsl/highlighting/xslthl-config.xml Please edit the Docbook scenarios [...]
I did. Unfortunately, I still have the same problem. Just to be sure the file is correctly found, I added an xsl:message to fo/profile-docbook.xsl in order to output the value of the param:
${framework}/xsl/highlighting/xslthl-config.xml
See? It hasn't been expanded. If I change it to ${frameworkDir}, I get an error (which by the way says it has been generated by an xsl:message, but does not point to the coresponding stylesheet).
Finally, if I change it to ${frameworks}/docbook/, then everything looks fine now. So it seems there is something wrong with the expanding of the current framework dir (either as a URI or a path), but I am not blocked anymore. Thanks!
Regards,
Hi, You can find the instructions for enabling logging in the Oxygen User Manual: http://www.oxygenxml.com/doc/ug-editor/index.html?q=/doc/ug-editor/topics/pr... You can find it by searching for "logging" in the User Manual. Regards, Sorin Florent Georges wrote:
By the way, I am going to activate logging, just to be sure there is nothing interesting in there. But it is so much pain to activate it (looking for an example on the Internet, download it, create the file, adapt it, and last but not least, restart oXygen). It would be sooo handy to have a preference panel dedicated to logging (enable/disable button, levels, even maybe introspecting existing logger names...) But that's another story ;-)
participants (3)
-
Florent Georges -
Jirka Kosek -
Sorin Ristache