KDE Help Center calls the equivalent of { xsltproc /usr/share/kde4/apps/ksgmltools2/customization/kde-nochunk.xsl /usr/share/scrollkeeper/doc/writing_scrollkeeper_omf_files/C/writing_scrollkeeper_omf_files.xml; } but the result is an empty document without any error message. If you run xsltproc from the command line, the result is the book "Writing ScrollKeeper OMF Files V1.1". Reproducible: Always Steps to Reproduce: 1. { scrollkeeper-install /usr/share/scrollkeeper/doc/writing_scrollkeeper_omf_files/C/writing_scrollkeeper_omf_files.xml; } 2. Tell KDE Help Center to display the document "Writing ScrollKeeper OMF Files". Actual Results: 2. (empty) Expected Results: 2. Writing ScrollKeeper OMF Files V1.1 KDE Help Center calls ghelp I/O slave which calls xsltApplyStylesheet from libxml1. The command xsltproc uses libxml2.
(In reply to comment #0) > KDE Help Center calls ghelp I/O slave which calls xsltApplyStylesheet from > libxml1. > The command xsltproc uses libxml2. I'm pretty sure libxml1 is not used. See kdoctools/CMakeLists.txt.
Luigi he's speaking about a "ghelp ioslave", that's not part of kdoctools/CMakeLists.txt. Christopher do you know where that "ghelp ioslave" lives code-wise?
It seems that kio_ghelp is a part of kdoctools/CMakeLists.txt (line 66). KIO does not work because it cannot find GNOME help in the new directories. yelp ghelp:ekiga - works konqueror ghelp:ekiga - does not work (File not found) Standard kioslaves debugging procedures [1] for port 7101 show nothing interesting. The GNOME XSL does not apply correctly for the DocBook help files: konqueror ghelp:/usr/share/gnome/help/ekiga/C/ekiga.xml shows "Parsing document" then "Applying stylesheet" from xslt.cpp (both untranslatable btw, the translations from kio_help4.po do not load) then shows a blank document. [1] http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves
(In reply to comment #3) > Standard kioslaves debugging procedures [1] for port 7101 show nothing > interesting. Just the opposite, they show that xsltApplyStylesheet from libxml1 gets called and returns an empty document.
(In reply to comment #2) > Christopher do you know where that "ghelp ioslave" lives code-wise? kdoctools/main_ghelp.cpp
Ok, so there's two bugs here: * first one that you need to specify the full path (is this a bug? i.e. what or who invokes the ghelp slave?) * second that even if you give it a full path it gives nothing. I think this may be related to the use of customization/kde-nochunk.xsl that we recently discovered it's broken if ( mGhelp ) { QString xsl = "customization/kde-nochunk.xsl"; ... } Luigi was having a look on the nochunk stuff. Luigi any hint?
I still hold that libxml1 is not used. If we talk about libxslt1, it's another story. (In reply to comment #6) > Ok, so there's two bugs here: > * first one that you need to specify the full path (is this a bug? i.e. > what or who invokes the ghelp slave?) > * second that even if you give it a full path it gives nothing. I think > this may be related to the use of customization/kde-nochunk.xsl that we > recently discovered it's broken > > if ( mGhelp ) { > QString xsl = "customization/kde-nochunk.xsl"; > ... > } > > Luigi was having a look on the nochunk stuff. Luigi any hint? I thought it was used only for the web document. Right now is broken, I can't work for another week at least on it, and the solution I was working on made it good for generating the document on the website, but not for documentation. The big problem I found is that kde-nochunk was relying on a parameter for the "no-chunk" which was removed from docbook-xsl long time ago, but another solution is possible using onechunk.xsl as inspiration, but it's no straightforward. On the other side, the file mentioned in the title seems to not be included in recent distribution (I can't see it in Debian *old*stable, for example); would it be possible to find a different reproducer?
Yeah, didn't realize we use nochunk anywhere else :-/ Maybe onechunk like /usr/share/xml/docbook/stylesheet/docbook-xsl/html/onechunk.xsl can help us here? Luigi you can use konqueror ghelp:/usr/share/gnome/help/ekiga/C/ekiga.xml as testcase i guess
(In reply to comment #6) > Ok, so there's two bugs here: > * first one that you need to specify the full path (is this a bug? i.e. > what or who invokes the ghelp slave?) Scrollkeeper. > * second that even if you give it a full path it gives nothing. I think > this may be related to the use of customization/kde-nochunk.xsl that we > recently discovered it's broken > > if ( mGhelp ) { > QString xsl = "customization/kde-nochunk.xsl"; > ... > } > Please note that xsltproc has no problem with this sheet.
(In reply to comment #7) > I still hold that libxml1 is not used. If we talk about libxslt1, it's > another story. Of course, my bad. > On the other side, the file mentioned in the title seems to not be included > in recent distribution (I can't see it in Debian *old*stable, for example); > would it be possible to find a different reproducer? The file comes with scrollkeeper.
Hmm, the funny thing is that xsltproc does not call xsltApplyStylesheet at all. Instead, it produces index.html from /usr/share/xml/docbook/stylesheet/nwalsh/current/html/chunker.xsl line 238. No wonder the result returned from xsltApplyStylesheet is empty. chunk.xsl is included by kde-include-common.xsl by kde-chunk-common.xsl by kde-nochunk.xsl; that seems to enable chunking mode unconditionally. The script kde-nochunk.xsl sets parameter using.chunker=0 but it does not help; this parameter is not evaluated afterwards. I think kde-include-common.xsl should include docbook.xsl instead of chunk.xsl if $using.chunker=0; this, however, is not possible because import is unconditional. I replaced <xsl:import href="/usr/share/xml/docbook/stylesheet/nwalsh/current/html/chunk.xsl"/> with docbook.xsl in (a local copy of) kde-include-common.xsl and ghelp started working.
(In reply to comment #8) > Yeah, didn't realize we use nochunk anywhere else :-/ > > Maybe onechunk like > /usr/share/xml/docbook/stylesheet/docbook-xsl/html/onechunk.xsl can help us > here? > No.
(In reply to comment #12) > (In reply to comment #8) > > Yeah, didn't realize we use nochunk anywhere else :-/ > > > > Maybe onechunk like > > /usr/share/xml/docbook/stylesheet/docbook-xsl/html/onechunk.xsl can help us > > here? > > > > No. I disagree. onechunk.xsl is the proper way. It includes chunk.xsl, but it sets some parameters. I was investigating if is more feasible to use onechunk.xsl directly or to replicate its behavior (I had other real-life priorities, but the work is still ongoing).
The purpose of onechunk.xsl is to store the result in a file, in which case the result is an empty document, whereas ghelp expects the result to be a DOM tree.
"ghelp expects the result to be a DOM tree" what does that mean?
The protocol ghelp is implemented via an input slave. An input slave generates document content as a character stream (actually, it is a material character array, which is why KDE Help Centre is so slow). The slave generates calling an external library to perform the transformation. The result of the observation used by the slave is not a character stream though; it is a document (TODO: it should be a stream of XML events instead). The document internally contains a tree of nodes. A tree is an in-memory structure with nodes containing pointers to other nodes; in particular, this representation does not live in a contiguous memory block and cannot be directly stored or sent over the pipeline (wire). All XML documents are built from pointers to objects arranged in a hierarchical way; the objects have a well-defined common interface you can rely upon; this is called the Document Object Model, which is what the acronym DOM stands for. The input slave examines the document returned by the library and generates its textual representation which it sends back to the client.
The protocol ghelp is implemented via an input slave. An input slave generates document content as a character stream (actually, it is a material character array, which is why KDE Help Centre is so slow). The slave calls an external library to perform the transformation. The result of the transformation used by the slave is not a character stream though; it is a document (TODO: it should be a stream of XML events instead). The document internally contains a tree of nodes. A tree is an in-memory structure with nodes containing pointers to other nodes; in particular, this representation does not live in a contiguous memory block and cannot be directly stored or sent over the pipeline (wire). All XML documents are built from pointers to objects arranged in a hierarchical way; the objects have a well-defined common interface you can rely upon; this is called the Document Object Model, which is what the acronym DOM stands for. The input slave examines the document returned by the library and generates its textual representation which it sends back to the client.
It turns out that viewing scrollkeeper-example2 in KDE Help Center, even though it fails to display anything in the help window, replaces the file ./index.html with formatted text of the viewed document. The path normally resolves to your home directory; what you used to have in that file is gone.
OTOH, it turns out that Luigi was right. Processing scrollkeeper-example2 produces two files: index and apa, and both link to each other. There is no supported way to push that set unto standard output for the Help Center, and even if there was one (think MHTML), it would be an excessive complication. Even if we could prevent emitting two pages by tweaking the SGML tools, doing so is likely to confuse the reader by producing one page that is too long to scroll through. So the ball is back at ghelp I/O slave, I guess.