Re: controlling processing on variblelist term entires

Bob Stayton <[email protected]> Wed, 25 Mar 2020 10:54:49 -0700
Newsgroups gmane.text.docbook.misc
Message-ID <[email protected]>
Hi Mats,

There are a couple of stylesheet parameters to control this option. See 
the section "Multiple term elements" in my online book:

http://www.sagehill.net/docbookxsl/Variablelists.html

Let me know if that doesn't work for you.

Bob Stayton
[email protected]

On 3/25/2020 10:15 AM, Mats Wichmann wrote:
> Hi, folks.
>
> I'm not having any joy finding an approach here...
>
> I've sort of inherited a documentation project that has an aspect that
> doesn't look good.  The project has a bunch of methods that exist in
> pairs - a global function, and a class method (the language is Python,
> fwiw).  These often have differences (e.g. often the global function
> takes an extra argument), so a common signature doesn't necessarily
> work, you want to list both. Whoever set this up presents these as
> entries in a variablelist, with the method signatures as the terms.  So
> we can see something like this:
>
> <variablelist>
>    <varlistentry>
>      <term>function(with long signature)<term>
>      <term>cls.function(with long signature)</term>
>      <listitem>description of behaviour</listitem>
>    </varlistentry>
>    etc.
>
> This really wants to be rendered with a line break between each term in
> order to look sane, but of course defaults into a single comma-separated
> line (which often wraps even in a wide browser window when looking at
> html output, if the signature part is indeed really long).  In the worst
> cases there may actually be four terms for one definition.  This
> approach is probably the wrong one, but since it's Python, switching
> over to <funcsynopsis> or <methodsynopsis> style markup doesn't really
> work (e.g. trailing semicolons, which Python doesn't want). A foray into
> setting the separator with a "dbhtml term-separator" didn't seem to
> yield anything (and would only affect the html output anyway).
>
> Any thoughts?
>
> thanks,
>
> -- mats
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>