tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
* docbook2mdoc and [sub]section links
@ 2019-05-20  5:50 Anthony J. Bentley
  2019-05-20 17:45 ` Ingo Schwarze
  0 siblings, 1 reply; 2+ messages in thread
From: Anthony J. Bentley @ 2019-05-20  5:50 UTC (permalink / raw)
  To: tech

Hi,

Instances of .Sx that docbook2mdoc(1) generates in text don't match the
case of the actual section name. The Sx's printed text (and, in HTML
output, the href of the hyperlink) will come from the section's id in
the DocBook source, which is not correct.

For example, here's a sample from the DocBook source of fonts(7):

  <para>
  This document describes the support for fonts in X11R&relvers;.
  <xref linkend='Installing_fonts' xrefstyle='select: title'/> is aimed at the
  casual user wishing to install fonts in X11R&relvers; the rest of the
  document describes the font support in more detail.
  </para>
  (snip)
  <sect1 id='Installing_fonts'>
  <title>Installing fonts</title>

And the result currently in xenocara:

  This document describes the support for fonts in X11R6.
  .Sx Installing_fonts
  is aimed at the
  casual user wishing to install fonts in X11R6 the rest of the
  document describes the font support in more detail.
  (snip)
  .Sh INSTALLING FONTS

The Sx line should match its Sh, "INSTALLING FONTS".

A related problem is with <sect3>. docbook2mdoc(1) generates Sy in Pp
for the tag. While dissatisfying, I don't know what better solution
there could be at the moment. But since this can't be treated as a
normal section cross reference, docbook2mdoc(1) should not create Sx
for references to <sect3>.

An example:

  <para>
  All that remains is to tell the X server about the existence of the
  new font directory; see <xref linkend='Setting_the_servers_font_path'
  xrefstyle='select: title'/> below.
  </para>
  (snip)
  <sect3 id='Setting_the_servers_font_path'>
  <title>Setting the server's font path</title>

becoming:

  .Pp
  All that remains is to tell the X server about the existence of the
  new font directory; see
  .Sx Setting_the_servers_font_path
  below.
  (snip)
  .Pp
  .Sy Setting the server's font path

-- 
Anthony J. Bentley
--
 To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: docbook2mdoc and [sub]section links
  2019-05-20  5:50 docbook2mdoc and [sub]section links Anthony J. Bentley
@ 2019-05-20 17:45 ` Ingo Schwarze
  0 siblings, 0 replies; 2+ messages in thread
From: Ingo Schwarze @ 2019-05-20 17:45 UTC (permalink / raw)
  To: Anthony J. Bentley; +Cc: tech

Hello Anthony,

Anthony J. Bentley wrote on Sun, May 19, 2019 at 11:50:38PM -0600:

> Instances of .Sx that docbook2mdoc(1) generates in text don't match the
> case of the actual section name. The Sx's printed text (and, in HTML
> output, the href of the hyperlink) will come from the section's id in
> the DocBook source, which is not correct.

Yes, this is a known shortcoming.  The proper fix involves:

 1. During parsing, building a table of ID attributes.
 2. During parsing, record the <xref> (and possibly similar)
    attributes as-is.
 3. In a later validation phase (after parsing), iterate all
    nodes an change those pointing to ID attributes to point
    the titles associated with the ID attributes.

So far, i shied away from doing that because it is slightly complex.
But it needs to be done at some point.

> A related problem is with <sect3>. docbook2mdoc(1) generates Sy in Pp
> for the tag. While dissatisfying, I don't know what better solution
> there could be at the moment. But since this can't be treated as a
> normal section cross reference, docbook2mdoc(1) should not create Sx
> for references to <sect3>.

Thanks, i wasn't aware of that aspect yet.

You are right that mdoc(7) simply doesn't support a third level of
sections - which is more a feature than a bug, avoiding excessive
complexity of documentation.

I agree that in such a situation docbook2mdoc(1) should just not
generate the .Sx macro.  That requires selectively adding entries
to the ID table, then deleting cross references during the validation
phase when there is no match for the target.

This is all a bit on the more tedious, lower priority side of
features to implement, yet it should clearly be done.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-05-20 17:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-20  5:50 docbook2mdoc and [sub]section links Anthony J. Bentley
2019-05-20 17:45 ` Ingo Schwarze

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).