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,