package_texi2qch
pkg-octave-doc: package_texi2qch (pkgname)
pkg-octave-doc: package_texi2qch (pkgname, Name, Value)
Generate a Qt compressed help file for an entire package.
package_texi2qch takes a single input argument, pkgname, which
is a char string with the package’s name whose Qt help file needs to be
generated, and writes pkgname.qch into the current working
directory. Octave’s GUI reads such a file to populate its documentation
tab: pkg load registers doc/pkgname.qch from the
package’s installation directory and pkg unload unregisters it, so
the generated file must be placed in the package’s doc/ directory
before the release tarball is built for it to have any effect.
The help text of every function listed in the package’s INDEX file is rendered to HTML, one page per INDEX category, and each function is registered as a keyword pointing at its own anchor within that page.
A classdef is not rendered onto its category page. It keeps the category its INDEX entry puts it in, and is given a page tree of its own beneath it, whatever its size:
<Class>.html carries the class help text and a list of links to the
pages below it.
<Class>_properties.html carries one section per property, and is
absent from a class that declares none.
<Class>_methods.html carries one section per method. A
grouped classdef, one that sorts its methods under
** Group Name ** banner blocks as classdef_texi2html reads
them, takes one page per group instead, named after it and carrying that
group’s methods, in the order the class declares them.
The contents tree of the documentation browser therefore nests a class under its own category, and is entered rather than scrolled past among its neighbours, which is what a category holding a few dozen classdefs would otherwise ask of a reader. A category page carries its plain functions and a list of links to the classes it owns.
Functions are grouped by category rather than given a page each because
every file inside a .qch is compressed on its own, so fragmenting
what the pages share inflates the archive: for the statistics
package the same documentation measures 0.57 MB at one page per category
against 1.89 MB at one page per function. The page tree a classdef is
given costs a part of that difference and buys the navigation back.
Demos are not included, neither their code nor their figures. A
.qch is an offline reference to be shipped inside the package, where
the rendered figures of a package the size of statistics would cost
more than the rest of the documentation put together. Demos remain
available through demo and through the online pages that
package_texi2html builds.
A @tex formula is rendered as its @ifnottex
alternative, and dropped when it has none. The documentation browser of
the GUI runs no JavaScript, so the MathJax that typesets a formula in the
online pages is not available to it, and the TeX would reach the reader as
source. This is what makeinfo does for every output that is not
TeX, and what help prints in the terminal for the same docstring.
package_texi2qch requires the qhelpgenerator program of the Qt
toolkit, which is located on the system’s $PATH unless the
'generator' option names it explicitly. The program is looked up
before any page is rendered and, if it cannot be found, an error is raised
and nothing is written, rather than spending the build on documentation that
cannot be packaged.
Example:
package_texi2qch ("statistics");
|
Optional Name/Value pairs
| Name | Value |
|---|---|
'Generator' | The qhelpgenerator executable, given
as a char string. By default the program is looked up on the system’s
$PATH. Name it explicitly on a system carrying more than one Qt
version, since a file built by one Qt major version may not register with a
GUI linked against another. |
'KeepHTML' | A logical scalar specifying whether the
intermediate HTML pages and the Qt help project file are kept beside the
generated .qch, which is false by default. They are useful
for inspecting what was rendered before shipping it. |
'Options' | A pkg_doc_options object giving each
rule the severity the package asks for, the defaults being used when none
is given. Unlike package_texi2cache and check_texi_docs,
which read doc-options.json from the package root they are run in,
this reads no settings file: it works from the installed package,
and a file at a source root is not installed, only the contents of
inst together with doc and packinfo being carried
there. So a package’s own conventions reach this route by being handed to
it, and the rules that are on by default, which are the ones wrong in any
package, apply either way. |
Source Code: package_texi2qch
Every help text is checked as it is read, and what is found is reported with the name it belongs to and a line counted from the first line of that help text. A finding never stops the build: a page is written from a help text whatever it says, since refusing would leave the package with no documentation over a defect the reader would have met anyway.
Only the rules a help text can be judged by on its own are applied here.
The rest measure the file a help text was written in, which this route
never opens, working as it does from the installed package; help is
its source and check_texi_docs is where those rules live.
See also: package_texi2html, function_texi2html, classdef_texi2html, check_texi_docs, pkg_doc_options
Source Code: package_texi2qch