[oXygen-user] XSLTHL with DocBook on oXygen 14 (built-in support throws error)

[Florent Georges]

  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,
>> 
>> 
>