If I remove the following parameters, I found that profiling works:
* olink.debug * collect.xref.targets * targets.filename * target.database.document However, if I remove those parameters, all the olinks in my output are broken. I guess I can try two-pass profiling to get the job done, but I hoped one pass would work. Has anyone found a way to profile Eclipse Help with olinks in one pass? Regards, Jeff Powanda ----- Original Message ----- From: Mauritz Jeanson <mj <at> johanneberg.com> Subject: RE: RE: Using HTML profiling breaks olinks and HTML navigation <http://news.gmane.org/find-root.php?message_id=%3c000d01c7d60b%246f31d6 b0%2471ea1a51%40D7MZ171J%3e> Newsgroups: gmane.text.docbook.apps <http://news.gmane.org/gmane.text.docbook.apps> Date: 2007-08-03 20:18:19 GMT (2 days, 7 hours and 15 minutes ago) > -----Original Message----- > From: Jeff Powanda > > Thanks. I downloaded DocBook XSL 1.73.0 and tried importing > profile-eclipse.xsl instead of eclipse.xsl in my > customization layer, but the conditions don't seem to work > (that is, all DocBook elements with condition attributes are > excluded from the output). Is there something else I need to do? > > I'm using xsltproc to generate the output. All profile-*.xsl stylesheets rely on the exsl:node-set() extension function. The author of xsltproc has his own (valid, as I understand it) opinion on how that extension can be safely implemented, and that might be causing the problem you are seeing (but this is just a wild guess). You can try 1. Another XSLT processor, for example Saxon. 2. Two-pass profiling (using profiling/profile.xsl). If this does not help, you need to provide a complete but minimal test case (including an input XML file) that can be used to reproduce the problem, using the stock stylesheets. /MJ
