Re: [Groff] Different font in first line of paragraph

[Steffen Nurpmeso]

Hello,

pet...@schwertfisch.de (Dirk-Wilhelm Peters) wrote:
 |is there a robust way to switch to a different font after the first
 |line of a paragraph is adjusted? The example below comes close,
 |but the first word of the second line of the paragraph is already
 |typeset in the previous font.

likely that Carsten will point to the "output line traps" that
Gunnar Ritter has introduced for Heirloom troff.
I've copied your message onto my TODO list for S-roff, because
i think it would be one of the more important improvements.
I hope i can make it there.

 |.ll 4c
 |.de PP
 |.br
 |.ft B
 |.wh \\n(nlu+1p DF
 |..
 |.de DF
 |.ft R
 |..
 |.PP
 |This is just an example paragraph.
 |It should be formatted in a different
 |font in the first line.

Ciao,

--steffen

[Groff] X in \A'X' isn't ignored - bug report?

[Steffen Nurpmeso]

Hello,

while trying to improve performance of mdocmx(7) on groff(1)
(without .hash request) further i'm now diversifying further via
.length+.substring (instead of only .length).  I am using \A'' so
that i can ensure the generated name can actually be used.
The (circumvented) problem is that, e.g.,

$ cat > ~/tmp/t.tr <<-_EOT
.if \A'du' \{\
du ist ok.
.\}
.if \A'\[' \{\
a bug?
.\}
huhu.
_EOT

generates

  ?0[steffen@sherwood roff.git]$ groff -Tutf8 < ~/tmp/t.tr
  :5: missing `]'
  :5: invalid component `a' in composite glyph name
  du ist ok.

That just can't be the intent, can it?  Is this a general parser
problem, i haven't looked yet..  Should i open a bug report?
Ciao,

--steffen

Re: [Groff] X in \A'X' isn't ignored - bug report?

[Steffen Nurpmeso]

Hello!

Werner LEMBERG  wrote:
 |>   :5: missing `]'
 |>   :5: invalid component `a' in composite glyph name
 |
 |Well, the parsing for `\[...]' happens before feeding the data to
 |\A'...', IIRC.
 |
 |> Is this a general parser problem, i haven't looked yet..
 |
 |I wouldn't call it a `general parser problem'.  Basically, you can't
 |generate `\[' programmatically, as far as I can see.  If you ever get
 |this warning, it's an error in the input.

Well exactly that was however the initial problem: while testing
the manual of the MUA i maintain i got three occurrences of
similar errors for \A'' on the result of a ".substring 0 1".
A terrible mess is needed to circumvent it:

  .   \" Otherwise we need to find a different way.  Use the length,
  .   length mx#sd#n \$2
  .   \" and furtherly subdivide (necessary, think mdoc(7) manual..)
  .   \" by using the first two letters (not one, ditto).
  .   \" Circumvent the ".substring returns anything" problem via \A'',
  .   \" be aware that groff(1) expands x in \A'x' during parse, so that,
  .   \" e.g, \[, from ".substring 0 1" results in parse errors!!
  .   ds mx#sd#s1 \$2
  .   ds mx#sd#s2 \$2
  .   substring mx#sd#s1 0 0
  .   substring mx#sd#s2 1 1
  .   ie \A'\*[mx#sd#s1]=\*[mx#sd#s2]' \

Note how you cannot even say \A'\*[a]\*[b]', since the result seems
to get expanded on the fly and breaks \A'' if that ends up as "\[".
So this is anything but robust and as such defeats the sole
purpose of \A''.

 |> Should i open a bug report?

Sorry for cross-posting.

--steffen

Re: [Groff] X in \A'X' isn't ignored - bug report?

[Steffen Nurpmeso]

Werner LEMBERG  wrote:
 |> Well exactly that was however the initial problem: while testing the
 |> manual of the MUA i maintain i got three occurrences of similar
 |> errors for \A'' on the result of a ".substring 0 1".
 |
 |Ouch :-)  Not having an `interned' representation can be advantageous,
 |but here it's definitely a problem...
 |
 |> Note how you cannot even say \A'\*[a]\*[b]', since the result seems
 |> to get expanded on the fly and breaks \A'' if that ends up as "\[".
 |> So this is anything but robust and as such defeats the sole purpose
 |> of \A''.
 |
 |Yes, it can't handle backslashes because they are always handled
 |before the request sees them.  Note that you want expansion of \*[...]
 |and \n[...], but at the same time you want that a solitary `\['
 |doesn't cause an error.  How shall this work?

Hmm, ok i see now what you mean.  I don't know the code in
question yet, but should i ever come up with a nice solution
i will open a regular ticket with a patch for groff(1), too (if
possible).

..I think i would implement such a thing by parsing the construct
and then recursively expanding the bounded content until no more
expansion is possible, finally checking the result: Since \A''
is ment to check if that final result is a valid identifier
i think (now that) i wouldn't care wether \[ is "something
incomplete" in other contexts.  As above.

 |I can imagine to add another escape sequence (or request) that accepts
 |a string register as an argument, checking its contents.  Cf. the
 |`dei' request.

That would be another solution.  I'm just looking at ChangeLog.117
right now, but don't understand the complexity behind the problem
yet (what i hope).  That'll take time.  And as above. :)
Thanks, Ciao, and have a nice weekend..

--steffen

[Groff] mdocmx(7), III.: reference extension for the mdoc(7) semantic markup language

[Steffen Nurpmeso]

Hello,

today i'm presenting "the first release" of mdocmx(7).
Shall no comments arise i'll open a bug ticket with exactly the
same content in the near future.
It will also be included in my fork of GPLv2 groff, S-roff.  (But
that will take quite some time.)

To reiterate what this thread [1,2] was about: i terribly missed
any kind of interactivity in mdoc(7) (*any* Unix manual that is)
and suggested extending mdoc(7) with some commands to make
references, indexing etc. at all possible, i.e., by being able to
specify anchors that can be referenced.

  [1] http://lists.gnu.org/archive/html/groff/2014-09/msg00145.html
  [2] http://lists.gnu.org/archive/html/groff/2014-12/msg00045.html

Ingo Schwarze responded with a much better solution, using
a single multiplexer command, so i jumped on that train and
developed an almost release-candidate prototype until christmas
2014.  Since then it matured even more.  (The most notable changes
are that the macros have been outsourced into their own file and
that all parts of the pipeline now require $MDOCMX_ENABLE to be
set and nonempty in order to understand mdocmx(7), instead of the
other way 'round.)

As a goody i've added PDF (via pdfmark) and HTML support today:
just like i said real support requires mdoc(7) to be rewritten [2].
Real is "appealing to me" in that respect.
But nothing prevented us to support the very same kind of output
that we use on the TTY also for PDF.  (And HTML, but i don't
mention that because what the HTML driver generates is.. a pity.)

So, what can mdocmx(7) do to improve manuals?
The answer can be found in mdocmx.7 that is attached.
A large manual that makes use of it is that of the MUA i maintain,
to be included in the next release that will happen in a few
minutes from now, v14.8 ("Albatros").

The following components are attached:

  . groff-1_22_3-mdocmx.diff:
Adds support to grotty(1) and mdoc(7).

  . groff-rel-to-head.diff:
For users of [master], patch this into
groff-1_22_3-mdocmx.diff.

  . less-v471-mdocmx.diff:
Adds support to less(1) v471 [3], the latest development
version.  Iirc it applies to the last official release [4]
with a very simple conflict that even non-programmers should
be able to resolve.
Inside less(1) the new command ^A (hold control-key and press
a) will prompt for a destination anchor.

[3] http://www.greenwoodsoftware.com/less/less-471.tar.gz
[4] http://www.greenwoodsoftware.com/less/less-458.tar.gz

  . mdocmx.sh:
mdocmx(1), the preprocessor, written in sh(1) and awk(1).
This is necessary because troff(1) doesn't support multipass.
(In fact mdocmx(7)-enabled manuals can be preprocessed and the
result can be shipped, so that it is _not_ necessary, then.)

  . mdocmx.tmac:
mdocmx(7), the actual macro package.

  . mdocmx.7, mdocmx.1:
Manual pages for mdocmx(7) and mdocmx(1).

I personally use the following shell functions:

  mdoc() {
  ( export MDOCMX_ENABLE=1 
mdocmx.sh "${1}" |
groff -Tutf8 -mdoc -dmx-toc-force=tree |
LESS= less --RAW-CONTROL-CHARS --ignore-case --no-init ) 
  } 
  mdocdbg() {
  ( export MDOCMX_ENABLE=1 
mdocmx.sh -vv "${1}" |
groff -Tutf8 -mdoc -dmx-toc-force=tree -dmx-debug=1 |
LESS= less --RAW-CONTROL-CHARS --ignore-case --no-init ) 
  } 

--steffen
diff --git a/src/devices/grotty/grotty.man b/src/devices/grotty/grotty.man
index 07ab62a..f9f4153 100644
--- a/src/devices/grotty/grotty.man
+++ b/src/devices/grotty/grotty.man
@@ -372,7 +372,7 @@ Print the version number.
 .\" 
 .
 .B grotty
-understands a single X command produced using the
+understands two X commands produced using the
 .B \[rs]X
 escape sequence.
 .
@@ -384,6 +384,21 @@ If
 is non-zero or missing, enable SGR output (this is the default),
 otherwise use the old drawing scheme for bold and underline.
 .
+.TP
+.BI \[rs]X'tty:\ mdocmx\ ...'
+.
+This request is used by the
+.BR mdocmx (@MAN7EXT@)
+reference extension of the
+.BR mdoc (@MAN7EXT@)
+semantic markup language and generates
+.SM BACKSPACE
+character sequences that allow supporting pager programs to perform
+reference navigation, but are ignored otherwise.
+This request should not be used directly;
+its interpretation will be suppressed unless the environment variable
+.B MDOCMX_ENABLE
+is set to a non-empty value.
 .
 .\" 
 .SH ENVIRONMENT
@@ -400,6 +415,19 @@ Colors are disabled.
 .
 .TP
 .SM
+.B MDOCMX_ENABLE
+Can be set to enable generation and interpretation of markup of the
+.BR mdocmx (@MAN7EXT@)
+reference extension of the
+.BR mdoc (@MAN7EXT@)
+semantic markup language.
+Note that it must be set to a non-empty value because of
+.BR @g@troff (@MAN1EXT@)
+language shortcomings (the macros won't see it otherwise).
+.
+.
+.TP
+.SM
 .B GROFF_FONT_PATH
 A list of directories i

[Groff] Little oversight in hdtbl/examples/common.roff (i think)

[Steffen Nurpmeso]

Hello,

i am finally finding time to truly sync my S-roff with the current
GNU troff (a bit tricky due to copyright issues…) in order to
be able to build and then act on it!  Woo-hoo!  Or something like
that...  ...And just in case you wonder...

Now this: in the outsourced common hdtbl example code i think i've
found an oversight?  Is the attached diff correct?

And say, _how_ painstaking exactly do i have to take care for GPL3
versus GPL2 "violations"?  E.g., i've taken the freedom to
synchronize hdtbl since the changes are mostly cosmetical and the
outsourcing of the shared example code i've done a bit
differently.  Note i've not copied the manual updates (examples
etc.).  Also, some changes simply cannot be done in a different
way (like save and restore compatibility mode: i can use
a different name for the save register, but that's it).
Ciao,

--steffen
diff --git a/contrib/hdtbl/examples/common.roff b/contrib/hdtbl/examples/common.roff
index ddb6d4a..0c3257a 100644
--- a/contrib/hdtbl/examples/common.roff
+++ b/contrib/hdtbl/examples/common.roff
@@ -282,15 +282,14 @@ along with this program. If not, see .
 .\"	**			minimal Page setup			**
 .\"	**
 .
-.nr s \n[.ps]
-.nr v \n[.v]
+.nr t*s \n[.ps]
+.nr t*v \n[.v]
 .nr p \n[.p]
 .nr o \n[.o]
-.pv 1.2 1.2 "" X
+.t*pv 1.2 1.2 "" X
 .nr l 6.6i\"	set text width
 .ll \n[t*l]u
-.nr o 2c\"	set offset
-.po \n[o]u
+.po 2c
 .nr p 29.7c\"	set paper length (A4)
 .pl \n[p]u
 .nr tH 1i\"	set top margin

Re: [Groff] Little oversight in hdtbl/examples/common.roff (i think)

[Steffen Nurpmeso]

Hallo Werner,

Werner LEMBERG  wrote:
 |Sorry for the late reply.

of course.
Thanks for doing so much work on and maintaining GNU roff such
a long time.

 |> Now this: in the outsourced common hdtbl example code i think i've
 |> found an oversight?  Is the attached diff correct?
 |
 |I don't think so.  The idea is that the hdtbl example modifies the
 |standard variables for general typesetting, not the ones specific to
 |hdtbl.  Do you notice a rendering difference?

I haven't tried it ._. (S-roff is not usable yet).
I just noted while syncing that in [6fb4a0a] (Fix last patch and
use `t*' prefix for all non-public stuff, 2010-02-08, yourself)
s and v of hdtbl were renamed to t*s and t*v but that didn't reach
common.roff, and methinks-ed "what else should s and v else refer
to"?  'Should have mentioned this context at first!

 |> And say, _how_ painstaking exactly do i have to take care for GPL3
 |> versus GPL2 "violations"?  [...]
 |
 |Alas, I don't know.

Me too, i ended up doing things that manifest like

TODO Yet i didn't remove the variable "left" since i don't know
TODO wether that wouldn't have side effects (since Werner did
TODO remove it there are surely none, but it takes intellectual
TODO property to get there and i'm in fear of violating copyright
TODO if i'd blindly take it).

in commit messages and hope it is enough.  (Also if the diff will
reduce to zero shall i find out that "left" really can be removed
that is.)
Ciao,

--steffen

Re: [Groff] How remove title?

[Steffen Nurpmeso]

Anyway i finally have to say that it is a pity that, instead of
(making the engine as such multi-pass and) instrumenting the
macros for different output formats that need meta-information,
and extending the macros sets to include more meta-information
that may be usable in output devices, so many other languages and
text formats have been invented where no person at all only spends
a single thought on using the necessary commands to provide this
meta-information as part of the format.

--steffen

Re: [Groff] recursive subdirectory search in GROFF_TMAC_PATH

[Steffen Nurpmeso]

Werner LEMBERG  wrote:
 |> Wouldn't it be useful to have the possibility of recursively
 |> searching the subdirectories of a directory in GROFF_TMAC_PATH,
 |> typically with the addition of a double-slash at the end of the
 |> concerned directory's name? (Cf. TeX's TEXINPUTS.)
 |>
 |> E.g.,
 |>
 |> export GROFF_TMAC_PATH=$HOME/groffinputs//:
 |>
 |> would cause .mso to search for its file at any subdirectory depth
 |> under $HOME/groffinputs.
 |
 |Definitely!  A few years ago I've already suggested to use the

I'm inclined to absolutely disagree given that

  ?0[sdaoden@wales roff.git]$ git grep GROFF_TMAC 1.02
  1.02:Makefile.bd:# you must set the GROFF_TMAC_PATH environment variable.
  1.02:man/groff.man:.B GROFF_TMAC_PATH
  1.02:man/gtroff.man:.B GROFF_TMAC_PATH
  1.02:troff/input.c:#define MACROPATH_ENVVAR "GROFF_TMAC_PATH"
  ?0[sdaoden@wales roff.git]$ gl1 1.02|head -5
  commit 351da0d (tag: refs/tags/1.02)
  Author: James Clark 
  Date:   1991-06-02 04:20:34 -0500

  groff before CVS: release 1.02

and i know about the crap i personally have done with path
variables not so many years ago.
And then think about the special path "//" which' behaviour is
implementation defined as well according to POSIX.

For the S-roff fork ("unforking" patches to groff is Public
Domain), which will ship with the class file_case patch that is on
the bugtracker (enabling .so over compressed paths, and enabling
any file to be compressed what some Brits don't like, however),
i like the idea of further extensions and fixes in that area, but
definetely not as suggested, so either a configuration option to
implicitly change the above or, more likely, a new environment
variable / configuration option.  (Configuration is too scattered
in my eyes.)

 |kpathsea library for groff's file management.  In particular, it would
 |allow for multiple font configuration files.

This is all too hardwired and restricted, and then scattered at
the same time.  Nothing a normal person can deal with easily.

 |However, I didn't have time and energy to implement it.  So please
 |file a `wishlist' report to the backtracker.

I'm still hoping for the upcoming years.

--steffen

Re: [Groff] recursive subdirectory search in GROFF_TMAC_PATH

[Steffen Nurpmeso]

Werner LEMBERG  wrote:
 |> And then think about the special path "//" which' behaviour is
 |> implementation defined as well according to POSIX.
 |
 |Do you actually know the kpathsea library?  Without this library, TeX
 |file management would be a nightmare.  And kpathsea works on all major
 |platforms and is very mature.

Not really, no.  I didn't use TeX since.. 2002?  I've searched and
read a bit once you brought it up, however.  And / but i also had,
until that day (2002-08-17+x), my own macro package and only needed

  ?0[sdaoden@wales ]$ git grep -i 'inputifexists{' master|sed -e '/doc/d'
  ..   \qInputIfExists{#1.ddf}% ddf = dimension-definition-file
  ..   \qInputIfExists{#1.fdf}% fdf = font-definition-file
  ..   \qInputIfExists{#1.lrf}% lrf = language-ressource-file
  ..   \qInputIfExists{\jobname .aux}% labels, write .toc,..
  ..   #1\makeatletter\qInputIfExists{\jobname .toc}\makeatother#2%
  ..   \qInputIfExists{\jobname .ind}%
  ..   \qInputIfExists{\jobname .bib}%
  ..\qInputIfExists{epsf.tex}%
  ..\qInputIfExists{colordvi.tex}%

epsf.tex and colordvi.tex (plus, of course, Knuth's base file, but
i have forgotten the name of it -- tex.tex?), that is really quick.
And then the REAL boster:

 % 00-05-31: new scheme to avoid waste. now a font is init only if it's used.
 % 2Compare (Cyrix 166+, 49MB, Linux 2.2.13-12, X 3.3.5):
 % | OLD   | NEW   |
 % |---|---|
 % | 1178 strings out of 13013 | 1413 strings out of 13013 |
 % | 13106 string characters of 122154 | 17026 string characters of 122154 |
 % | 35574 words of memory of 263001   | 54220 words of memory of 263001   |
 % | 2086 multiletter of 1+0   | 2321 multiletter of 1+0   |
 % | 80647 font info for 276 fonts | 20674 words of font info for 70 fonts |
 %   (out of 40 for 1000)
 % and 38s of 4000, instead of 37s. Note however that the additional use of the
 % (test) font-package, 'ec.fdf', let to "20 font info"! Today it is 28689
 ..
   (TeX stucked for one to two seconds before, but now it
 % runs straight and __the complete test is faster than the loading of the fonts
 % was before__).

I.e., lazy creating fonts à la

  \gdef\@font@hugestrm{%
  \ifndef{@hugest@rm}\@afontadd{@hugest@rm}{cmr10 
scaled\nmagstep{14}}\fi\@hugest@rm}%

That actually makes me wonder when exactly i became a Eunuch,
and even more, why.  I think a deep inspection of that topic will
turn out something positive.

 |>|kpathsea library for groff's file management.  In particular, it
 |>|would allow for multiple font configuration files.
 |>
 |> This is all too hardwired and restricted, and then scattered at the
 |> same time.  Nothing a normal person can deal with easily.
 |
 |Well, if I want to add a font to groff, I would prefer to *not* modify
 |the system-wide font config file but a local one...

I think a normal user would prefer something like

  .font tahoma.ttf

and get-set-go.  For other use cases i would have no problem with
a single global .ini-style configuration file and a per-user one
with the same syntax.  And then, e.g., a "[eqn]" section instead
of an eqnrc somewhere deep in an intransparent machinery.  Ok,
that is possibly a no-go given the content of eqnrc, but why not,
likewise hypothetic

  [startup-files]
  eqn = INSTALLPATH/eqnrc

So then the user looks /etc/XY.rc and then ~/.XY.rc and knows,
especially with some hinting comments.
And yes i have read the second paragraph of eqn(1).  But with that
no path search at all.  And that is the best of all path searches,
in my humble opinion.
Regarding my own efforts this is a long road to go, however.
Ciao, and a nice rest weekend to you and all lurkers,

--steffen

Re: [Groff] recursive subdirectory search in GROFF_TMAC_PATH

[Steffen Nurpmeso]

Hello and good morning Ralph,

Ralph Corderoy  wrote:
 |> For other use cases i would have no problem with a single global
 |> .ini-style configuration file and a per-user one with the same syntax.
 |
 |Aside, I dislike Microsoft's INI files that have appeared in Unix.  :-)
 |They're not line based, but have context, making them more awkward to
 |search and edit with Unix tools.

In my opinion it's even worse for those that became widespread
especially in the network area, presumably because of the existing
mature yacc parser, à la

 a {
   b = c
   d {
 e = f
  }
 }

or mixture of ini-style "[group]"s plus those {} subgroups i also
have seen.  But

 |>   [startup-files]
 |>   eqn = INSTALLPATH/eqnrc
 |
 |`startup-files.eqn=INSTALLPATH/eqnrc' might lead to repetition over many
 |lines, but it's self-contained;  the parser need not track any
 |`[section]', and sed can edit it more easily.

that is a suggestion to keep in mind.  Even though i now remember
that once i've read the git config manpage first i was insecure
how to actually do it (and i think writing "as-is" didn't work, at
least back then, ..and still).  You use it when doing lookups from
the command line, but have to use INI style syntax in the
configuration file.  Can be done differently, of course.
All in all i'm without plan yet anyway.
Variables had to go in there if such a thing would come, as in

  eqn = ${INSTALLPATH}/eqnrc
or
  eqn = ${configure.PREFIX}/eqnrc

i.e., what you say is good.

But, anyway, regarding the thread topic, in my opinion lesser path
search would be the improvement, not an additional library for
this little piece of code, which really could be done differently,
and additional path searches.
And _especially_ so in groff since it silently relies on POSIX
things and even "non-portable" extensions, e.g., realpath(3) is
a XSI extension even today, so then nftw(3) could also be used.
It's in the C library, you get it for free.
And then in a way that is explicit, either through a configuration
option (/ environment variable) or with a new environment
variable, just one more of those, but i don't like that.
Ciao.

--steffen

Re: [Groff] recursive subdirectory search in GROFF_TMAC_PATH

[Steffen Nurpmeso]

P.S.:

i wrote:
 |Werner LEMBERG  wrote:
 ||Do you actually know the kpathsea library?  Without this library, TeX
 ||file management would be a nightmare.  And kpathsea works on all major
 ||platforms and is very mature.

My "all too hardwired and restricted, and then scattered at the
same time" didn't refer to that library, but to groff.  Sorry for
not being clear.

And also, because it was the second time that you did that
i wanted to add that i'm not only (practically) a vegetarian but
also never used an airplane in my conscious life, nor will i ever
do so easily, for example.  Recalling the thread with Karl Berry
i said that i personally would allow Mr. Stallman to use an
airplane to go from city to city, so that is more than i am
allowing myself.  I think that was clear back then.  I see no
reason that a Gnu should be afraid of me.
Ciao,

--steffen

Re: [Groff] Reproducible dates in HTML/PDF/PS output files?

[Steffen Nurpmeso]

Colin Watson  wrote:
 |Here's an updated patch for this issue.  The difference relative to my

Thanks for placing this under GPL2, like that it will find its way
into S-roff, too!

 |More details on SOURCE_DATE_EPOCH (and there are many other useful
 |things on the same site):
 |
 |  https://reproducible-builds.org/specs/source-date-epoch/

And again thanks for the first pointer of yours, i never thought
about reproducible build before, have read that one and am already
sorting the sources for the MUA i maintain since about two weeks.
SOURCE_DATE_EPOCH to follow!

--steffen

Re: [Groff] Does groff match my needs?

[Steffen Nurpmeso]

 wrote:
 |Joh-Tob Schäg  wrote (Wed, 11 Nov 2015 17:32:47
 |+0100):
 |> i seached for an alternative to latex and found groff. Sadly i found
 |> no IRC or something where i could ask directly.
 |> But before i invest time in groff or some macro system, i wanted to
 |> know if it fits my needs.
 |> These are:
 |> -support for ä,ü,ö,Ä...
 |\[:a],\[:u],\[:o],\[:A],..
 |use preconv in order to translate from an encoding as utf8 to the groff
 |representation above; -D, -K, -k switches to groff are equivalent
 |Have a look at 'man groff' and 'man grof_char' for the chars.

I always use LATIN1 and use the umlauts etc. directly, as in

  ich mchte mich hiermit sehr herzlich fr die Wendung in
  unserem Rechtsstreit bedanken!

(This is via less(1) in an UTF-8 environment though.)

 |> -supporting word division for german (possible compound) words
 |watch out for hyphenation requests:
 |.hy, .hla and .hpf

E.g. this works pretty good for me, outsourced in its own file,

  .\"@ s-hw_german.tmac: hyphenation add-ons
  .hla de
  .hpf hyphen.de
  .hpfa hyphenex.de
  .
  .hw An-we-sen-heits-nach-weis
..list that increased over the years..
  .hw Ver-hand-lungs-ter-min
  .hw zu-min-dest

to be sourced into other documents via

  .mso s-hw_german.tmac

 |> -supports A4 paper format
 |Most tricky because you have to watch out at every transformation

Ys.

 |step: in groff, from groff to PS and from PS to pdf. For custom sizes,
 |this is a worst case, you might need to know ghostscript commandlines.

I have a shell alias for A4 (even with my own macros..)

  s-groff 'groff -dpaper=a4 -P-pa4'

 |  Be patiently in learning. Attempting to gain quick success in running

Ciao,

--steffen

Re: [Groff] Help locating financial reports generated by groff

[Steffen Nurpmeso]

"Gerard Lally"  wrote:
 |On Sun, 13 Dec 2015 17:15:15 -, Deri James  
 | wrote:
 |> On Sun 13 Dec 2015 11:31:58 Gerard Lally wrote:
 |>> Some time ago I came across some financial or business reports which, if
 |>> my memory isn't deceiving me, were generated by groff. I vaguely recall

 |All I remember is that they looked stunning, and I'm fairly certain they  
 |were produced by you. Old age is catching up with me though so God only  
 |knows!

I think you mean the quarterly (?) bank (?) reports.
Yes, it really looked just perfect, but the code that produces it
(it was posted or at least the link was posted and i looked) was
plain disgusting. ^_^
It was in one of those "groff is great i use it for just anything"
threads.. wait.. it must have been somewhen in that deep threads
around end of march 2014 if i recall correctly..  Hmm, i thought
i'd find it in the "letterspacing" thing, but no.  I think he
posted only once.  I even thought i'd have a saved copy locally,
but also no.  The code was really terrible.  Sorry...

--steffen

Re: [Groff] text variants

[Steffen Nurpmeso]

Dave Kemper  wrote:
 |On 11/23/15, Dave Kemper  wrote:
 |> groff_char does seem to address this issue regarding other glyphs.  It
 |> says, "Entries marked with `***' denote glyphs for mathematical

 |I was finally going to do this but hit a snag: it turns out commit
 |07a6233adeb476611f7a286295935cbbf6b9cbbd ("complete notes in tables,"
 |done by Bernd Warken) removed the *** marker from all rows that
 |previously contained it, while leaving the explanatory text of what
 |the marker signifies.

Thanks for analyzing your issue, that changeset i blindly took.

--steffen

Re: [Groff] text variants

[Steffen Nurpmeso]

Hello.

Werner LEMBERG  wrote:
 |> It seems more likely, though, that these markers were erroneously
 |> removed during the rather extensive changes introduced in this
 |> commit -- surely the point about the font metrics for these glyphs
 |> remains true.  Bernd?
 |
 |Please restore the markers.

I wonder what those "+" markers are for, they have been added in
[48615a4].  Whereas explanation for the *** markers has been added
in [d855e16], those remain untold?

--steffen

Re: [Groff] text variants

[Steffen Nurpmeso]

Werner LEMBERG  wrote:
 |Please restore the markers.

I think this should be it regarding ***.

--steffen
diff --git a/man/groff_char.man b/man/groff_char.man
index f393578..edd3792 100644
--- a/man/groff_char.man
+++ b/man/groff_char.man
@@ -842,7 +842,7 @@ right angle bracket
 T}
 
 \[bv]	\e[bv]	braceex	u23AA	T{
-curly brace vertical extension
+curly brace vertical extension *** +
 T}
 \[braceex]	\e[braceex]	braceex	u23AA	T{
 curly brace vertical extension
@@ -1169,18 +1169,18 @@ T}
 \[/_]	\e[/_]	angle	u2220	angle
 \[pp]	\e[pp]	perpendicular	u22A5	perpendicular
 \[is]	\e[is]	integral	u222B	integral
-\[integral]	\e[integral]	integral	u222B	integral
-\[sum]	\e[sum]	summation	u2211	summation
-\[product]	\e[product]	product	u220F	product
-\[coproduct]	\e[coproduct]	uni2210	u2210	coproduct
+\[integral]	\e[integral]	integral	u223B	integral ***
+\[sum]	\e[sum]	summation	u2211	summation ***
+\[product]	\e[product]	product	u220F	product ***
+\[coproduct]	\e[coproduct]	uni2210	u2210	coproduct ***
 \[gr]	\e[gr]	gradient	u2207	gradient
 \[sr]	\e[sr]	radical	u221A	square root
 \[sqrt]	\e[sqrt]	radical	u221A	square root
 \[radicalex]	\e[radicalex]	radicalex	---	T{
-square root continuation
+square root continuation ***
 T}
 \[sqrtex]	\e[sqrtex]	radicalex	---	T{
-square root continuation
+square root continuation ***
 T}
 
 \[lc]	\e[lc]	uni2308	u2308	left ceiling

Re: [Groff] text variants

[Steffen Nurpmeso]

Werner LEMBERG  wrote:
 |> I wonder what those "+" markers are for, they have been added in
 |> [48615a4].
 |
 |Uh, oh, a lot of them are lost :-( As documented in the man page, they
 |indicate that the (two-letter) glyph name is documented in the
 |original troff manual.

It seems i have searched only for the + as a symbol, not as
a word.  Hm.

 |I fear that Bernd won't be able to fix this due to personal issues, so
 |maybe someone can check the groff_char man page from version 1.22.2,
 |re-adding the plus signs.

I think the attached should do so.  It looses many of Bernd's
changes since i've reverted his commit as a first step, but that
mostly affects the greek alphabet and i think adding an, e.g.,
"omicron" comment for "omicron" is not really a loss.  Then i've
checked against [2f4fdb0].
Note i haven't really read all that thorougly.  One future day
when i convert the manual to mdoc(7) i will.
Ciao,

--steffen
diff --git a/man/groff_char.man b/man/groff_char.man
index f393578..e84c032 100644
--- a/man/groff_char.man
+++ b/man/groff_char.man
@@ -542,9 +542,9 @@ Moreover, new glyph names can be created by the \f(CW.char\fP request; see
 .BR groff (@MAN7EXT@).
 .
 .P
-In the following, a plus sign in the \[oq]Notes\[cq] column indicates
-that this particular glyph name appears in the PS version of the
-original troff documentation, CSTR\ 54.
+In the following, a plus sign \[oq]+\[cq] in the \[oq]Notes\[cq] column
+indicates that this particular glyph name appears in the PS version of
+the original troff documentation, CSTR\ 54.
 .
 .P
 Entries marked with \[oq]***\[cq] denote glyphs for mathematical
@@ -685,8 +685,8 @@ _
 \[a-]	\e[a-]	macron	u0304 (u00AF)	overbar accent
 \[a.]	\e[a.]	dotaccent	u0307 (u02D9)	dot accent
 \[a^]	\e[a^]	circumflex	u0302 (u005E)	circumflex accent
-\[aa]	\e[aa]	acute	u0301 (u00B4)	acute accent
-\[ga]	\e[ga]	grave	u0300 (u0060)	grave accent
+\[aa]	\e[aa]	acute	u0301 (u00B4)	acute accent +
+\[ga]	\e[ga]	grave	u0300 (u0060)	grave accent +
 \[ab]	\e[ab]	breve	u0306 (u02D8)	breve accent
 \[ac]	\e[ac]	cedilla	u0327 (u00B8)	cedilla accent
 \[ad]	\e[ad]	dieresis	u0308 (u00A8)	umlaut accent
@@ -740,9 +740,9 @@ Output	Input	PostScript	Unicode	Notes
 _
 \[r!]	\e[r!]	exclamdown	u00A1	inverted exclamation mark
 \[r?]	\e[r?]	questiondown	u00BF	inverted question mark
-\[em]	\e[em]	emdash	u2014	em-dash symbol
+\[em]	\e[em]	emdash	u2014	em-dash symbol +
 \[en]	\e[en]	endash	u2013	en-dash symbol
-\[hy]	\e[hy]	hyphen	u2010	hyphen symbol
+\[hy]	\e[hy]	hyphen	u2010	hyphen symbol +
 .TE
 .ad
 .
@@ -842,7 +842,7 @@ right angle bracket
 T}
 
 \[bv]	\e[bv]	braceex	u23AA	T{
-curly brace vertical extension
+curly brace vertical extension *** +
 T}
 \[braceex]	\e[braceex]	braceex	u23AA	T{
 curly brace vertical extension
@@ -868,19 +868,19 @@ right square bracket extension
 T}
 
 \[lt]	\e[lt]	bracelefttp	u23A7	T{
-left curly brace top
+left curly brace top +
 T}
 \[bracelefttp]	\e[bracelefttp]	bracelefttp	u23A7	T{
 left curly brace top
 T}
 \[lk]	\e[lk]	braceleftmid	u23A8	T{
-left curly brace middle
+left curly brace middle +
 T}
 \[braceleftmid]	\e[braceleftmid]	braceleftmid	u23A8	T{
 left curly brace middle
 T}
 \[lb]	\e[lb]	braceleftbt	u23A9	T{
-left curly brace bottom
+left curly brace bottom +
 T}
 \[braceleftbt]	\e[braceleftbt]	braceleftbt	u23A9	T{
 left curly brace bottom
@@ -889,19 +889,19 @@ T}
 left curly brace extension
 T}
 \[rt]	\e[rt]	bracerighttp	u23AB	T{
-right curly brace top
+right curly brace top +
 T}
 \[bracerighttp]	\e[bracerighttp]	bracerighttp	u23AB	T{
 right curly brace top
 T}
 \[rk]	\e[rk]	bracerightmid	u23AC	T{
-right curly brace middle
+right curly brace middle +
 T}
 \[bracerightmid]	\e[bracerightmid]	bracerightmid	u23AC	T{
 right curly brace middle
 T}
 \[rb]	\e[rb]	bracerightbt	u23AD	T{
-right curly brace bottom
+right curly brace bottom +
 T}
 \[bracerightbt]	\e[bracerightbt]	bracerightbt	u23AD	T{
 right curly brace bottom
@@ -938,13 +938,13 @@ T}
 l l l l lx.
 Output	Input	PostScript	Unicode	Notes
 _
-\[<-]	\e[<-]	arrowleft	u2190	horizontal arrow left
-\[->]	\e[->]	arrowright	u2192	horizontal arrow right
+\[<-]	\e[<-]	arrowleft	u2190	horizontal arrow left +
+\[->]	\e[->]	arrowright	u2192	horizontal arrow right +
 \[<>]	\e[<>]	arrowboth	u2194	T{
 horizontal arrow in both directions
 T}
-\[da]	\e[da]	arrowdown	u2193	vertical arrow down
-\[ua]	\e[ua]	arrowup	u2191	vertical arrow up
+\[da]	\e[da]	arrowdown	u2193	vertical arrow down +
+\[ua]	\e[ua]	arrowup	u2191	vertical arrow up +
 \[va]	\e[va]	arrowupdn	u2195	T{
 vertical arrow in both directions
 T}
@@ -984,14 +984,14 @@ extension of the square root sign.
 l l l l lx.
 Output	Input	PostScript	Unicode	Notes
 _
-\[ba]	\e[ba]	bar	u007C	bar
-\[br]	\e[br]	SF11	u2502	box rule
-\[ul]	\e[ul]	underscore	u005F	underscore
-\[rn]	\e[rn]	overline	u203E	overline
-\[ru]	\e[ru]	---	---	baseline rule
-\[bb]	\e[bb]	brokenbar	u00A6	broken bar
-\[sl]	\e[sl]	slash	u002F	slash, solidus
-\[rs]	\e[rs]	backslash	u005C	reverse slash, reverse solid

Re: [Groff] text variants

[Steffen Nurpmeso]

Hi.

Dave Kemper  wrote:
 |On 12/15/15, Steffen Nurpmeso  wrote:
 |> I think the attached should do so.
 |
 |Thanks, Steffen!  Once this is applied to git, I'll create a patch
 |with my originally suggested enhancement.

The attached may do, then.  (With some manual intervention.)
(And regarding my S-roff fork, and fyp[ossible]i, i am
tremendously sorry that it takes so long; i trail behind more than
a year compared to the initial schedule, but in December 2014 the
BSD Mail codebase got a fairly silly CVE, and even though the
initial fix was done in a day it took about half a year to come to
the point where the desired approach of something good could
become implemented.  And then there was some light on the horizon
to reach a pretty acceptable state until the end of 2015.
Unfortunately i then decided to fix some no-go area in October (a
brilliant idea from the 1970s!, but which won't work out with new
functionality that was added in the 2000s -- and thus never worked
for real) and that messed up anything.  Now i hope to be able to
release that one when it's getting 38 years old, by the end of
March, and then i really turn my head for a lng time and
start working on S-roff.  And i hope for good.)

Ciao,

--steffen
Author: Steffen Nurpmeso 
Date:   2015-12-26 12:03:07 +0100

[firstfixes] man/l_roff-char.7.in: sprinkle *** (Dave Kemper)...

The thread that resulted in the detection that the Bernd lost some
precious manual information started off because of some missing
*** markers [1].  Even though the corresponding text variants
follow in the manual directly after the non-text one, honour [2]
and add the markers, since that is what they are for.

  [1] http://article.gmane.org/gmane.comp.printing.groff.general/13582
  [2] http://article.gmane.org/gmane.comp.printing.groff.general/13640
---
 man/l_roff-char.7.in | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/man/l_roff-char.7.in b/man/l_roff-char.7.in
index 3175f99..cbc0ab0 100644
--- a/man/l_roff-char.7.in
+++ b/man/l_roff-char.7.in
@@ -1074,7 +1074,7 @@ Output	Input	PostScript	Unicode	Notes
 _
 \[AN]	\e[AN]	logicaland	u2227	logical and
 \[OR]	\e[OR]	logicalor	u2228	logical or
-\[no]	\e[no]	logicalnot	u00AC	logical not +
+\[no]	\e[no]	logicalnot	u00AC	logical not + ***
 \[tno]	\e[tno]	logicalnot	u00AC	text variant of \[oq]no\[cq]
 \[te]	\e[te]	existential	u2203	there exists
 \[fa]	\e[fa]	universal	u2200	for all
@@ -1109,15 +1109,15 @@ _
 \[pl]	\e[pl]	plus	u002B	plus in special font +
 \[mi]	\e[mi]	minus	u2212	minus in special font +
 \[-+]	\e[-+]	uni2213	u2213	minus-plus
-\[+-]	\e[+-]	plusminus	u00B1	plus-minus +
+\[+-]	\e[+-]	plusminus	u00B1	plus-minus + ***
 \[t+-]	\e[t+-]	plusminus	u00B1	text variant of \e[+-]
 \[pc]	\e[pc]	periodcentered	u00B7	period centered
 \[md]	\e[md]	dotmath	u22C5	multiplication dot
-\[mu]	\e[mu]	multiply	u00D7	multiply sign +
+\[mu]	\e[mu]	multiply	u00D7	multiply sign + ***
 \[tmu]	\e[tmu]	multiply	u00D7	text variant of \e[mu]
 \[c*]	\e[c*]	circlemultiply	u2297	multiply sign in circle
 \[c+]	\e[c+]	circleplus	u2295	plus sign in circle
-\[di]	\e[di]	divide	u00F7	division sign +
+\[di]	\e[di]	divide	u00F7	division sign + ***
 \[tdi]	\e[tdi]	divide	u00F7	text variant of \e[di]
 \[f/]	\e[f/]	fraction	u2044	bar for fractions
 \[**]	\e[**]	asteriskmath	u2217	mathematical asterisk +

Re: [Groff] horizontal trap

[Steffen Nurpmeso]

Tadziu Hoffmann  wrote:
 |> A trap set just below the current output position could record
 |> the maximum .n seen on this page, moving the trap down each time.
 |
 |Indeed, trapping output instead of input would have the added
 |advantage that overlong lines could be detected even if the
 |text was processed in fill mode.
 |
 |> At the bottom of the page, if the maximum is too long, flag
 |> this page as a problem;  for example, .tm output, or add
 |> something to the page itself for searching.
 |
 |But if we're only interested in flagging the output pages
 |with no direct connection to the location of the problematic
 |material in the input, then trapping every single output line
 |strikes me as a bit complicated.  I'd suggest simply diverting
 |the page contents and then testing the diversion's width.

Simply dumping into a diversion is what i do for my VERBATIM
macro, too.  I'm however not testing the width.  It seems i never
made it yet to overtake that from my partially lost TeX package,
which actually does, and also supports five different builtin
styles for verbatim output instead of only a silly numbered one.
What a shame.
(I refrained from posting wonderful hookable TeX code to this list
at this point, but i also do love it!  And roff, but i didn't know
that back then.)

 |(If one is doing multi-column output then I guess it would
 |be expedient to divert the output anyway, so this could be
 |conveniently combined with testing for overlong lines.)

--steffen

Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff

[Steffen Nurpmeso]

Ralph Corderoy  wrote:
 |> The project on github: https://github.com/cloutiy/tml
 |> Extensive documentation on its wiki: https://github.com/cloutiy/tml/wiki
 |
 |Interesting, and I'll look more when I've time.
 |
 |> Inline formatting has a nice clean syntax that resembles HTML, but
 |> much cleaner - you just need 1 closing tag.
 |...
 |> Here is some .
 |> Here is some .
 |> Here is some .
 |...
 |> Here is 
 |
 |I struggle to read the  syntax though, and I suspect enough
 |non-programmers have been exposed to HTML-like syntax in forum software,
 |etc., that they to are used to <> balancing.  Editors may also provide
 |"matching bracket" functionality for <>, as with [], etc.  Were syntaxes
 |like
 |
 |Here is some .
 |Here is some .
 |Here is some .
 |Here is 
 |
 |considered, with the first colon marking the separation?
 |
 |> text.

Or plain SGML that i think could use 

Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff

[Steffen Nurpmeso]

Hi,

Yves Cloutier  wrote:
 |Thanks for your comment.

It however wasn't real fun for i guess, but it is great that you
don't mind.

 |Closing a inline formatting stack with a single closing bracket was a
 |design decision meant to reduce the noise added to running text.  It's
 |meant to keep the running text more readable. For example:
 |
 |some text
 |
 |vs
 |
 |
 |
 |or even the sugared version:
 |
 |.

Even is nice :)  Ya, i mean, ya, sure, being able to easily add-up
properties for an enclosed range.

 |I'm not familar with SGML, but will have a look.

Yep, thanks for refreshing me.  Actually i think that the empty
end tag  was standard SGML, and that the " doesn't thrill me.  I could hardly grasp it in
a lot of running text it would surely drive me up the wall.
Really it may have something to do with psychology and the
horizontal bias of the graphics you use, and the leading into
different directions?  I think 

Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff

[Steffen Nurpmeso]

"James K. Lowden"  wrote:
 |On Sat, 16 Jan 2016 17:32:38 +0100
 |Steffen Nurpmeso  wrote:
 |> I think plain SGML is still an interesting language, much
 |> better than what XML made of it.  
 |
 |As Dijkstra said of Algol, "an improvement over many of its
 |successors."  
 |
 |> I had a time when i liked rst, but pimping POD is possibly nicer
 |> given how rst looks if you start real work with progamming stuff
 |> etc.  And then a nicely reduced ROFF (TeX, too) set of macros does
 |> look very clean!
 |
 |I observe that my groff documents have the lowest markup/text ratio.
 |Less typing, more typesetting.  I suppose that's because, contrary to

Me too.  At least regarding letters or the like, in my own macro
package.  mdoc manuals are something different.

 |XML, troff syntax was always meant to be typed by the user.  
 |
 |My other observation is that all the new plaintext syntaxes run out of
 |gas before you get very far.  Try representing a table in markdown;
 |look for a way to do footnotes.  

That is, or was, my one, too.  I don't think i ever tried _that_,
though i tried to use it for documenting programs, and the text
became so full of special markup characters that the term "plain
text format" could no longer have been applied to it, and using
the result as a README for a normal end-user would not have been
a real option no more.

The good think on those new format is that someone has written
converters that can be used to produce output in a lot of formats,
and very often in good quality.  It would be nice if that would
happen with roff in the future.

--steffen

Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff

[Steffen Nurpmeso]

"James K. Lowden"  wrote:
 |On Sat, 23 Jan 2016 12:17:35 -0500
 |Larry Kollar  wrote:
 |> IIRC, James Clark wrote the only open-source SGML parser around, and
 |> it didn?t support the full syntax. By contrast, there are XML parsers
 |> in just about every language out there including awk.
 |
 |AFAIK Clark's jade is the only free SGML parser.  While it's true that
 |it leaves certain features unsupported, I never bumped into them while
 |writing the user guide for FreeTDS.  

Writing a perl script that digs SGML is pretty easy, especially if
its not for "production" industry use.

 |I suspect that SGML included minimization because it was at least
 |sometimes intended to be written by by hand.  The unfulfilled hope of

Yes, manual editing in your favourite text editor.  At least
a little bit of human notion in the tagsoup.  I never understood
XML and treated it as industry forum outcome that help some people
to take a soapy bath on some stages, which is the real show babes,
is it, and i think JSON/YAML is better if you cannot do it
manually anyway, with CBOR being a nice binary notation.

 |XML was that tools would produce and use XML, and that we humans would
 |produce and use those tools.  

No.

--steffen

Re: [Groff] pdfroff 1.22 calls groff 1.19 -help

[Steffen Nurpmeso]

Anton Shterenlikht  wrote:
 |This is on FreeBSD 10.2-RELEASE-p9,
 |with base OS groff, /usr/bin/groff at 1.19.2,
 |and groff-1.22.2_3 istalled via packages
 |under /usr/local/bin.
 |
 |When I try to run pdfroff 1.22, it pulls
 |groff 1.19:
 |
 |$ /usr/local/bin/pdfroff --version
 |GNU pdfroff (groff) version 1.22.2

This script will prefer environment variables GROFF_BIN_DIR then
GROFF_BIN_PATH (why is all that, btw.?  ph!) falling back to
PATH as a last option only.  So doing

  $ ( GROFF_BIN_PATH=/usr/local/bin/; $GROFF_BIN_PATH/pdfroff )

should do it, no?  Not seldom the quality of packages is really,
really regrettable.  But it seems to me here some configure /
compile time setting is truly missing.  (For the future S-roff
i would really like to see that we have outsourced shell (and
perl++) "libraries" which get sourced in by such scripts, and can
be sourced in by possible user scripts.  Just like, e.g., git does
it.  In there variables like $INSTALL_BIN -- or whatever! -- can
easily be distributed to any user.)  On the other hand it seems to
be common sense that users are responsible for their $PATH, so if
you use the package system which adds in /usr/local then you
possibly should place /usr/local before /usr in $PATH, since
otherwise anything in base will be used in preference.  Right. :)

 |However, 1.19, the base OS version is drastically
 |cut down to the bare necessities of building FreeBSD
 |man pages only, so it does not have spdf or pdfmark
 |macros, hence the error:
 |
 |$ /usr/local/bin/groff -Tpdf -mspdf z.1 > z.pdf
 |$ /usr/local/bin/pdfroff -mspdf z.1 > z.pdf
 |troff: fatal error: can't find macro file spdf
 |troff: fatal error: can't find macro file spdf

So this should magically disappear, too, then.  It seems to be common
sense that this error message is even verbose, but some reference
to $GROFF_TMAC_PATH, and/or the complete search-path, would make
sense more easy for users i think.

--steffen

Re: [Groff] pdfroff 1.22 calls groff 1.19 -help

[Steffen Nurpmeso]

Anton Shterenlikht  wrote:
 |>This script will prefer environment variables GROFF_BIN_DIR then
 |>GROFF_BIN_PATH (why is all that, btw.?  ph!) falling back to
 |>PATH as a last option only.  So doing
 |>
 |>  $ ( GROFF_BIN_PATH=/usr/local/bin/; $GROFF_BIN_PATH/pdfroff )
 |>
 |>should do it, no?  Not seldom the quality of packages is really,
 |>really regrettable.
 |
 |Thank you. I got it to work.
 |
 |Are you saying this is something that should be
 |properly fixed in the FreeBSD groff package?
 |If so, I'll submit a PR for the port maintainer
 |to have a look.

No, i changed my mind while writing the message...
(Staying flexible is very mammal'ish.  Also the key of survival,
which is why i don't believe in green plus genetic engineering.-)

--steffen

Re: [Groff] bad QE in -ms

[Steffen Nurpmeso]

Hi.

Carsten Kunze  wrote:
 |Can we agree to commit this?  (The patch is also added as a .gz file.)
 |
 |diff --git a/tmac/s.tmac b/tmac/s.tmac
 |index cf0eca8..190ee11 100644
 |--- a/tmac/s.tmac
 |+++ b/tmac/s.tmac
 |@@ -1298,6 +1298,10 @@ along with this program. If not, see .
 | .\}
 | .el .@error unbalanced \\$0
 | .par@reset
 |+.if '\\$0'QE' \{\
 |+.  sp \\n[\\n[.ev]:PD]u
 |+.  ne \\n[PORPHANS]v+\\n(.Vu
 |+.\}
 | ..
 | .de @QS
 | .br
 |@@ -1311,6 +1315,8 @@ along with this program. If not, see .
 | .nr \\n[.ev]:ri +\\n[QI]
 | .nr \\n[.ev]:ai \\n[\\n[.ev]:PI]
 | .par@reset
 |+.sp \\n[\\n[.ev]:PD]u
 |+.ne \\n[PORPHANS]v+\\n(.Vu
 | ..
 | .als @QE @RE
 | .\" start boxed text

Disclaimer: i never have used ms nor have i ever looked into the
macros.
But of course i was interested in this and while i fully trust you
(i haven't even tried it) i think a better approach would be to
avoid the repititions.  I saw you've copied+pasted the .sp / .ne
sequence from a par*start, so wouldn't it be better as attached?
What do you mean?

--steffen
diff --git a/tmac/s.tmac b/tmac/s.tmac
index cf0eca8..0749eba 100644
--- a/tmac/s.tmac
+++ b/tmac/s.tmac
@@ -1188,6 +1188,10 @@ along with this program. If not, see .
 .nr \\n[.ev]:pri 0
 .par@reset
 ..
+.de par@adjspace
+.sp \\n[\\n[.ev]:PD]u
+.ne \\n[PORPHANS]v+\\n(.Vu
+..
 .\" This can be redefined by the user.
 .de TA
 .ta T 5n
@@ -1202,14 +1206,9 @@ along with this program. If not, see .
 .nr \\n[.ev]:pli \\$1
 .nr \\n[.ev]:pri \\$2
 .par@reset
-.sp \\n[\\n[.ev]:PD]u
-.ne \\n[PORPHANS]v+\\n(.Vu
-..
-.de par@finish
-.nr \\n[.ev]:pli 0
-.nr \\n[.ev]:pri 0
-.par@reset
+.par@adjspace
 ..
+.als par@finish @RT
 .\" normal LP
 .de @LP
 .par*start 0 0
@@ -1298,6 +1297,7 @@ along with this program. If not, see .
 .\}
 .el .@error unbalanced \\$0
 .par@reset
+.if '\\$0'QE' .par@adjspace
 ..
 .de @QS
 .br
@@ -1311,6 +1311,7 @@ along with this program. If not, see .
 .nr \\n[.ev]:ri +\\n[QI]
 .nr \\n[.ev]:ai \\n[\\n[.ev]:PI]
 .par@reset
+.par@adjspace
 ..
 .als @QE @RE
 .\" start boxed text

Re: [Groff] groff performance in respect to hardware platform

[Steffen Nurpmeso]

Steve Izma  wrote:
 |On Wed, Mar 23, 2016 at 08:25:50PM -0400, Larry Kollar wrote:
 |> Subject: Re: [Groff] groff performance in respect to hardware platform
 |>> I'm wondering how CPU configurations affect groff processing
 |>> speed.

 |I guess I need to re-state the question. I'm quite familiar with
 |groff's speed, including with 1000-page (or larger) complex
 |books. But I'm wondering if anyone can tell me if groff benefits
 |from running on multiple CPU cores and multiple CPUs.

Well i guess that you benefit quite a bit due to the piped nature
in between all the several programs that are involved, right?
Unless one part of the pipeline has to wait for more input from
its predecessor it seems to me they can run in full parallel.
One more reason not to like grohtml, by the way. ^_^

--steffen

Re: [Groff] groff performance in respect to hardware platform

[Steffen Nurpmeso]

Steve Izma  wrote:
 |On Wed, Mar 23, 2016 at 11:21:37PM -0400, Steve Izma wrote:
 |> Subject: Re: [Groff] groff performance in respect to hardware platform
 |> 
 |>> ... But I'm wondering if anyone can tell me if groff benefits
 |>> from running on multiple CPU cores and multiple CPUs.
 |>> I assume that another way of asking this: "is groff
 |>> multithreaded?"

 |Damian's comment might be relevant to the viewing process (and
 |definitely for the other graphics-oriented concerns I have) but
 |one counter-indication is how I observe okular working. Up to
 |about 50 pages, the PostScript file is completely written before
 |okular attempts to re-read it. The screen update is very fast.
 |But if I'm viewing, say, page 90 the PS file (being written
 |apparently in chunks by grops) is noticed by okular as having
 |its timestamp changed, so it reads whatever in can get, can't
 |find page 90, so displays page 50. Strangely enough, it doesn't
 |seem to notice that the file has had more pages added to it after
 |this point, so I'm stuck looking at the wrong place in the
 |output. This implies either an I/O problem or else one part of
 |the pipeline (I don't think it's the python parsing) is lagging
 |behind.

Let groff write into fileA, move that to fileB and open your
viewer on that one?

 |> Looking at spawn-pipe.c, the only parallelization you get in groff is
 |> the pipeline of preprocessing, formatting, and rendering.  
 |> 
 |> ISTM that's all you *can* get because the formatting process --
 |> determining which words go on each line -- is necessarily sequential.
 |> The whole-paragraph formatting algorithm Doug McIllroy proposed some
 |> time back worked in parallel, but each paragraph would still be rendered
 |> serially.  
 |
 |Thanks for looking at the code, which reinforces the above
 |comments. I think you're correct about the limitation caused by
 |the serial nature of typesetting, but I wonder if the non-h&j
 |processes, like I/O and perhaps even things to do with font data,
 |could be done in parallel? E.g., if, like in a PostScript file,
 |one stated at the beginning of a tmac file all the fonts that are
 |going to be needed then having font info compilation as a
 |separate thread -- this might work? (Not that I'm volunteering; I
 |couldn't begin to understand how to code that.)

Regarding myself i think that it will take several years of basic
homework until i will be able to think about such things.  I hope
i have a compilable and usable roff at the end of this summer
(late enough it'll be), but from what i have seen yet things are
pretty complex and i for one don't like coding bypasses to achieve
a goal fast, generally speaking.  Because, if you do this for
multiple features and several then you have a dead-end codebase,
and that is something that i don't like.  Sure, what is known from
me in public is not the sunniest side of coding possible, at least
so far, but in general i try to iterate over code until it is,
yes, a kind of beauty.  I.e., something of value, like a Japanese
knife or sword that has been folded manually thousands of times.
Or real Rolls-Royce back in the day with hand fitted (the german
word is "dengeln", i can't seem to find the right english
translation) fenders - a man, some metal and three days of hard
work.  And having tea.

It has become clear, i have no idea.  But i would be surprised if
by pure design the core of troff could be parallelized that much,
because of all the traps etc.  What you say, maybe.  I think it is
easier in something like Markdown or RTF or a full Word processor
where paragraph boundaries and all attributes of a paragraph are
clear and fully specified on the input side, so then it is
thinkable that you can fully parallelize the "painting" of the
lines that make up a complete paragraph, and then simply merge
those threads of paintings together for the final target, taking
care for orphan and widow lines etc.  In reality reality may crush
this utopia forcefully, however.

--steffen

Re: [Groff] psfig With groff

[Steffen Nurpmeso]

Hello,

Henry McGilton  wrote:
 |I’m trying to determine whether or not psfig can be used with groff.
 |
 |Pretty much all of the back and forth about groff is a decade old, and
 |doesn’t really answer the simple question of whether groff supports
 |psfig. 
 |
 |I see that James Clark mentions that psfig is not being supported
 |going forward, but does that apply to groff support of psfig, meaning,
 |have the various parts of the \X (in-line pass through) been modified
 |to support psfig?
 |
 |For what it’s worth, I have a Mac version of psfig that compiles and
 |builds clean on Mac OS X.I went through all the compiler warnings
 |and errors and fixed all of them.

So i still wonder what your message means.  Is the patch that is
in the groff sources still usable?  psfig.tmac doesn't seem to be
installed in a default groff, though in the tmac/ of the groff
sources it is contained.  I haven't used TeX for a very long time.
Ciao,

--steffen

Re: [Groff] grohtml missing in groff 1.22?

[Steffen Nurpmeso]

Anton Shterenlikht  wrote:
 |On FreeBSD 11-current, with groff 1.22 installed
 |
 |rat> pkg info -xo groff
 |groff-1.22.2_4 textproc/groff
 |rat> pkg info -xl groff|grep groh
 |/usr/local/bin/post-grohtml
 |/usr/local/bin/pre-grohtml
 |/usr/local/man/man1/grohtml.1.gz

 |Before I contact the FreeBSD groff maintainer,
 |should a separate grohtml binary be built
 |as part of groff-1.22?

I think it's just «irritation because of fuzzy manual language».
As in «HTML output device can be chosen by using the -Thtml
command line option of groff(1)».
And don't forget to double check the output if you really think of
using it (my one cent)!

--steffen

Re: [Groff] grohtml missing in groff 1.22?

[Steffen Nurpmeso]

i wrote:
 |Anton Shterenlikht  wrote:
 ||On FreeBSD 11-current, with groff 1.22 installed
 ||
 ||rat> pkg info -xo groff
 ||groff-1.22.2_4 textproc/groff
 ||rat> pkg info -xl groff|grep groh
 ||/usr/local/bin/post-grohtml
 ||/usr/local/bin/pre-grohtml
 ||/usr/local/man/man1/grohtml.1.gz
 |
 ||Before I contact the FreeBSD groff maintainer,
 ||should a separate grohtml binary be built
 ||as part of groff-1.22?
 |
 |I think it's just «irritation because of fuzzy manual language».
 |As in «HTML output device can be chosen by using the -Thtml
 |command line option of groff(1)».

As in: «grohtml invokes groff twice.» is a nice paraphrase for the
penetration of the respective code in roff.

 |And don't forget to double check the output if you really think of
 |using it (my one cent)!

--steffen

Re: [Groff] multi-line macro arguments

[Steffen Nurpmeso]

(Ted Harding)  wrote:
 |> ?ukasz Stelmach  wrote:
 |>> I am developing a macro to print envelopes. Is it possible to pass a
 |>> multi-line string (not necessarily defined with .ds) as a parameter
 |>> for a macro?

 |The basic idea is not to give a "multi-line string" as a single
 |paramater, but to give the separate lines as separate arguments.

Or open a diversion, read in all lines, and then work with the
diversion.  E.g., my letter template has something like

  .RECEIVER
  $TITLE
  $NAME
  $STREET

  $CITY
  .RECEIVER END

and the plain macro looks like (of course it's part of an,
heavily restricted,

  .MACRO RECEIVER
  .  S:BOOLIFY \$1
  .  ie \n[S:#IS_BOOL] \{\

I.e., macro starting point

  . vs \n(.su*\*[RECEIVER_LINE_SPACING_SCALE_FACTOR]

By default: RECEIVER_LINE_SPACING_SCALE_FACTOR 1.5

  . nf
  . de S:RECEIVER_TRAP EOT
  .blm PARA

I use blank lines to cause paragraphs.

  .ds S:RECEIVER_DIVERSION_HOOK
  .sp 1v
  \*[RECEIVER_PREHOOK]\c

By default: RECEIVER_PREHOOK \s[+1] 
That's all very inflexible, but the way it's used will print the
postal code etc. in a larger font.
(It would need more hooks...)

  .EOT
  . di S:RECEIVER_DIVERSION
  . blm S:RECEIVER_TRAP
  .  \}
  .  el \{\

Macro called with "END".

  . if d S:RECEIVER_DIVERSION_HOOK \{\
  \*[RECEIVER_POSTHOOK]\c

By default: RECEIVER_POSTHOOK \s[-1]

  .rm S:RECEIVER_DIVERSION_HOOK
  . \}
  . di
  . \" Calculate best position for address field and box out
  . if (\n(dlu >= \n[#RECEIVER_WIDTH]u) \

Default: #RECEIVER_WIDTH 9c

  .WARN \
  "Receiver address is too width to fit in address window!"
  . if (\n(dnu >= \n[#RECEIVER_HEIGHT]u) \{\

Default: #RECEIVER_HEIGHT 3.8c

  .WARN \
  "Receiver address does not fit in address window! Growing window!!"
  .nr #RECEIVER_HEIGHT \n(dnu
  . \}
  . nr #1 (\n[#RECEIVER_HEIGHT]u-\n(dnu)/2u
  . sp |(\n[#RECEIVER_START]u+\n(#1u

Default: #RECEIVER_START 4.15c

  . rr #1
  . S:RECEIVER_DIVERSION
  . rm S:RECEIVER_DIVERSION
  . rm S:RECEIVER_TRAP
  . fi
  . vs
  .  \}
  ..

The default dimensions are for C6 (for DIN A4).
The good thing about this approach is that quoting doesn't matter
at all.

--steffen

Re: [Groff] .if !dTS - GNU extension?

[Steffen Nurpmeso]

"James K. Lowden"  wrote:
 |On Fri, 29 Apr 2016 17:50:52 +0200
 |Ingo Schwarze  wrote:

 |Have you experimented with a single index for all man pages?  I wonder
 |how useful that would be, or how it might be subdivided.  An index that
 |spanned pages would be helpful for sets of routines covered by
 |different man pages.  (groff.7 and groff_char.7 come to mind.)  

In books as well as in info pages there are either multiple
indexes or a single index where entries are somehow tagged to
indicate an entries' type, if that is applicable, which it
definetely is for the Unix manual system with its different
sections, and the corresponding differences in the manuals
contained therein.

And especially mdoc(7) can be easily extended to provide the
necessary tagging facilities, and then it is only the tool that is
missing to generate such a global index from the per-document
indexes.  If that basic Unix system will gain more functionality
it could be hoped that all those other formats in which people
started writing their manuals in order to gain that bit more (and
they don't mind adding complicated and cryptic tags in order to do
so) will extend their converters to also use it.  And at least
automatically created mdoc(7) should be acceptable to anybody.

It's absurd that (at least) in the Linux world people started
tagging man(7) manual pages, things which you use every day, with
function-less blue hyperlinks using font escapes, whereas billions
of dollars and maybe hundreds of thousands of man hours have been
put into code that is being rudely documented.  Unfortunately i am
still stuck in the MUA i maintain, and i will need until at least
mid summer eve.  But then i will come to my roff fork, and at the
long run it will be mdoc all through and it will ship with the
mdocmx extension from the start.  Even «magic» won't help against
the basic problem of non-extended mdoc(7), and that is that you
don't have anchors: no real index without proper anchors.

--steffen

Re: [Groff] .if !dTS - GNU extension?

[Steffen Nurpmeso]

Deri James  wrote:

 |I've been using pdf versions of the man pages for a while now. They don't 
 |suffer some of the problems mentioned in this thread. For example, in\
 | the ksh 
 |manual you can find the description of "read" with two mouse clicks. First 
 |open the section "Built-in commands" (near the bottom of the overview\
 | pane), 
 |then scroll down to the "read" command and click on it.

Yes.  This is a convenient, also visual, improvement for users,
but it plasters over a hollow ground!

 |You can see what I mean at:-
 |
 |http://chuzzlewit.co.uk/WebManPDF.pl/man:/1/ksh

The good thing about real books is that you can have a finger in
the index as necessary.  E.g., if you read a book from Oxford
World's Classics, well you as an English are used to the quality,
by the way, yet i'm not, so that i admire and i can bathe in
typography, footnotes and also swiftly look and read things like

  salvage or silver man: wild man of the woods or green man;
  a figure of heraldry as well as folklore.

and switch back to the daunting story within a glance, the most
beautiful green turf, surrounded on one side by the forest, and
fringed on the other by straggling oak-trees, some of which had
grown to an immense size.

This experience you simply won't get without precise text
attribution and iterated text inspection, let it be expensive.
Pissing a bit it needs to be said that with mdocmx(7) – thus
anchors – you get a bit of what i call «natural» read experience,
regardless of wether you look at the HTML variant, or – and that
it is for me!  (And note germans surround em dashes with spaces!)
– on the terminal, in your normal $PAGER.

It is missing an index yet, but while reading in the text you see
a reference to, say, *mimetypes-counter-evidence*, you hit ^A and
enter the link number, recall what this is all about, then hit ''
and are back where you were before.  In a HTML browser you can
even follow blindly as references fly by and step back multiple
times, i sometimes miss that in my mdocmx(7)ified less(1).

Then imagine all manual pages where instrumented like that, and
a real multi-level index could be build over them all.  All
functions, all preprocessor variables, all "commands" etc.,
available in a searchable and even browsable (could be themselves
mdoc(7) and mdocmx(7)) in a plain $PAGER, too!  A list of all
cross-references, as in "gzip(1) is referenced from the following
manual pages: x y z".  Then your system would be able to produce
a real index and a real table of content of all the things that
your system actually provides.  More is thinkable, the tool could
also generate JSON or CBOR output, or whatever.  Compare that to
the X Rosetta Man.

--steffen

Re: [Groff] Permissible characters for hyphenation

[Steffen Nurpmeso]

i wrote:
 |Stephen Berman  wrote:
 ||Does groff permit characters besides hyphen-minus (ASCII 45) and soft
 ||hyphen (octal 255) for displaying hyphenation in man pages?  I'm asking
 |
 |I have been convinced that soft hyphen is a control character and

…assuming you referred to U+00AD when you have meant soft hyphen.


--steffen

Re: [Groff] Permissible characters for hyphenation

[Steffen Nurpmeso]

Oh!

i wrote:
 |Stephen Berman  wrote:
 ||Does groff permit characters besides hyphen-minus (ASCII 45) and soft
 ||hyphen (octal 255) for displaying hyphenation in man pages?  I'm asking

that finally made me think: Eli Zaretskii is so active on the
Unicode list, why don't you use the Pd character class for
detecting «hyphen»?  I guess this should cover all such things
already as of today, thanks to Werner Lemberg?!

--steffen

Re: [Groff] Permissible characters for hyphenation

[Steffen Nurpmeso]

Hello!

John Gardner  wrote:
 |> I have been convinced that soft hyphen is a control character and
 |> not something visual,
 |
 |Almost correct.
 |
 |Soft hyphens *do* describe potential breaking points, but they only become
 |visible when surrounding text is broken.
 |
 |For instance, assume this line had soft-hyphens every 20 characters:
 |
 |Methionylalanylthreonylserylarginylglycylalanylserylarginylcysteinylproly
 |
 |When wrapped, this is how it would look:
 |
 |Methionylalanylthre-
 |onylserylarginylgly-
 |cylalanylserylargin-
 |ylcysteinylproly
 |
 |Without soft-hyphens (and when wrapped to 20 columns), it'd look like this
 |instead:
 |
 |Methionylalanylthre
 |onylserylarginylgly
 |cylalanylserylargin
 |ylcysteinylproly
 |
 |Here, hyphenation becomes a lot less apparent.

Yes.  For display purposes however i think U+00AD can't be used
directly, but will be replaced by the renderer to either nothing,
if no wrap is to be applied at the character position, or
something appropriate, like ASCII hyphen-minus or some extended
Unicode "Pd" letter, of which there are some (e.g., U+058A
ARMENIAN HYPHEN, U+1400 CANADIAN SYLLABICS HYPHEN, and more).

 |I should also add that I don't know how well-supported this behaviour is
 |between different platforms. I remember reading that some browsers
 |displayed the hyphen between broken word boundaries, while others didn't.
 |Web authors were encouraged to use the more semantic and reliable 
 |element 
 |instead.

I am, for one, sure that the HTML standard committee will someday
manage to add markup for shitty baby napkins.  The palms and
beaches of their happenings seem to promote this direction. ^.^

--steffen

Re: [Groff] Permissible characters for hyphenation

[Steffen Nurpmeso]

John Gardner  wrote:
 |On 30 May 2016 at 23:20, Steffen Nurpmeso  wrote:
 |> John Gardner  wrote:
 |>|> I have been convinced that soft hyphen is a control character and
 |>|> not something visual,
 |>|
 |>|Almost correct.
 |>|
 |>|Soft hyphens *do* describe potential breaking points, but they only
 |> become
 |>|visible when surrounding text is broken.

 |> Yes.  For display purposes however i think U+00AD can't be used
 |> directly, but will be replaced by the renderer to either nothing,
 |> if no wrap is to be applied at the character position, or
 |> something appropriate, like ASCII hyphen-minus or some extended

 |>|Web authors were encouraged to use the more semantic and reliable 
 |>|element <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr>
 |>|instead.
 |>
 |> I am, for one, sure that the HTML standard committee will someday
 |> manage to add markup for shitty baby napkins.  The palms and
 |> beaches of their happenings seem to promote this direction. ^.^
 |
 |I, uh, think something might've been lost in translation. :|

So.  That made me search the web and i've found:

  On UTF-8 encoded pages,  behaves like the U+200B ZERO-WIDTH
  SPACE code point. In particular, it behaves like a Unicode bidi
  BN code point, meaning it has no effect on bidi-ordering: 123,456 displays, when not broken on two
  lines, 123,456 and not 456,123.

  For the same reason, the  element does not introduce
  a hyphen at the line break point. To make a hyphen appear only
  at the end of a line, use the soft hyphen character entity
  (­) instead.

  This element [.] was officially defined in HTML5.

My opinion: HTML was derived from SGML as a strict abstraction of
content and form(atting).
But afaik HTML requires any conforming application to support
Unicode since quite a long time, so then why duplicating
behaviour?  Is it because of «explicit is better»?  So, then.
Fine.  I also would use  above, but the bigger the choice,
the harder it is to choose (www.dict.cc).

Years ago i've read Korpela's rant on this topic, but Markus Kuhn
also has something nice to say:

  The original HTML 2 specification [6] by Tim Berners-Lee et al.,
  still wisely leaves the semantics of SOFT HYPHEN untouched with
  the remark

NOTE - Use of the non-breaking space and soft hyphen indicator
characters is discouraged because support for them is not
widely deployed.

  Unfortunately by HTML 4 [7], this had mutated into a complete
  reinterpretation of the purpose of the SOFT HYPHEN, compared to
  how it had been used over the past decade in output devices.
  What was originally a graphical character had turned into an
  invisible marker for a hyphenation opportunity:
  [.]
  This HTML 4 reinterpretation is essentially the semantics that
  Unicode then adopted as well.

May the majority be with you.

--steffen

Re: [Groff] How to find bugs in man pages?

[Steffen Nurpmeso]

Hello.

Ingo Schwarze  wrote:
 |Ralph Corderoy wrote on Sun, Jun 19, 2016 at 04:10:15PM +0100:
 |> Xose wrote:
 |
 |>> I'm using: groff -z -b -wall manpage.x
 |>> Is there anything better?
 |
 |> Not as far as I know.
 |
 |Inside groff, that is.

 |Several linters exist.

You are too modest in my opinion, mandoc -Tlint is the best
i know.  (It doesn't know .Mx, which is, well, a pity.)

 |  schwarze@isnote $ which igor

But thanks for pointing out igor nonetheless, it reported quite
some long-standing spelling mistakes of mine, which i thus could
fix.  Good to know that these can happen to native english
speakers, too.  Note you have to face being credited.
In general it is astounding that it is not astounding that "good
enough" doesn't write some overlay macro packages which check more
error conditions.

--steffen

Re: [Groff] colorized man pages

[Steffen Nurpmeso]

"James K. Lowden"  wrote:
 |http://boredzo.org/blog/archives/2016-08-15/colorized-man-pages-understood-a\
 |nd-customized
 |
 |https://news.ycombinator.com/item?id=12296000
 |
 |It's a little far afield, but some here might be interested in the
 |interest in manpages.  mdoc has no color features, leaving folks to
 |resort to some pretty brutal techniques. 
 |
 |Raw VT-100 escape sequences, in 2016.  Where will it all end?  

I think it would be nice to offer people the possibility to
specify a list of colours.  It shouldn't be too much work to
instrument a few important man and mdoc macros and add an
environment variable, say, MANUAL_COLOURS, in equal spirit to
LS_COLORS.  In the Linux world there is now a dircolors(1) command
which can be used to control LS_COLORS.  Well.

Yes, people are interested in that and should have the possibility
to do that, exactly like you say.  And as flexible as possible.
I place it on my TODO list for S-roff.

--steffen

Re: [Groff] colorized man pages

[Steffen Nurpmeso]

walter harms  wrote:
 |Am 19.08.2016 13:06, schrieb Steffen Nurpmeso:
 |> "James K. Lowden"  wrote:

 |>|It's a little far afield, but some here might be interested in the
 |>|interest in manpages.  mdoc has no color features, leaving folks to
 |>|resort to some pretty brutal techniques. 

 |> I think it would be nice to offer people the possibility to
 |> specify a list of colours.  It shouldn't be too much work to
 |> instrument a few important man and mdoc macros and add an
 |> environment variable, say, MANUAL_COLOURS, in equal spirit to
 |> LS_COLORS.  In the Linux world there is now a dircolors(1) command
 |> which can be used to control LS_COLORS.  Well.
 |> 
 |> Yes, people are interested in that and should have the possibility
 |> to do that, exactly like you say.  And as flexible as possible.
 |> I place it on my TODO list for S-roff.

 |hi guy,
 |please make sure that this is a reversible change.
 |personally i find dircorlors annoying, i can not read
 |anything with certain combinations. An i have no idea
 |what colors you would like to have in a man page.

I am really sorry that S-roff is still not what i am working on,
i had planned to not touch my MUA a single day in 2016 and yet
i haven't touched anything else a single day.  I am sorry for all
people that have placed hope in that project over two years ago,
shall there be some sort of!

The thing is, i have stepped up maintaining this MUA, and it was
really broken, and it is still so restricted, and the new version
will bring _so_ many improvements...  I want to step over to other
projects because i actually _can_ leave it aside for some time
without too many regrets, and for no other reason.  Not too few
times i have said things like "S-roff should have worked on
christmas, ... but in 2014", and it is even worse with S-CText.

I'm really, really eagerly looking forward for it.
I will remember your words, then.

I mean, the thing as such should be doable in a few days, if you
know the macros.  I think the TTY device (html is just broken)
should optionally be enabled to look for real colours, though, and
actively decide on its own.  That will need proper configuration,
compile etc. extensions, then, however.
Ciao.

--steffen

Re: [Groff] colorized man pages

[Steffen Nurpmeso]

Clarke Echols  wrote:
 |Just because you can doesn't mean you should.

To me the problem is that i can't right now, even though i want.

 |With a world gone crazy over apps for this, apps for that,
 |and apps to manage apps (I'm guessing because I've never
 |owned a cell phone -- much less a smart phone) I see no

I don't know about that.  I have an «emergency» mobile phone.  It
is the second mobile phone i own – you know the story of the
extreme cruelty and environmental terror surrounding Coltan, and
that the Chinese even paid over world market price to calm down
the situation some ten years ago, _if_ i recall correctly.  So,
no.  I would still use my first, even older, Nokia, but the power
plug is dead, and no one seems to be able to repair it.  Though it
would very well be worth it.  Anyway i am now the owner of a used
Samsung, which, i admit, has a camera and, once unfolded,
a monitor.  I couldn't wait for the renaissance of the plain old
good stuff, unfortunately.

Granted that we possibly have seen a step forward regarding user
interfaces due to all this.  Then again, i think it is just a step
heading towards the vision that materialized in the Newton.
And that in turn is most likely (not only!) a real-life
translation of the brain transplant and do-by-thinking, which is
much, much older, i think.

 |need for it.

I can't agree.  Though i am pretty conservative regarding this
myself, most of the time – my vim, with which i stay practically
all the time, uses DarkRed (brown) for comments and
reverse,bold,red for warning messages.

I see the need because this software, not only the macros, don't
allow people to realize what they want.  And they seem to do so,
because whenever i start vim without my own config file, myself
starts laughing.  And it was like that already when i started
using vim, around Y2K.  And then colors offer the option to «break
out» of a situation: say you work twelve hours in a two-colour
editor session, it is, in my gut feeling, helpful to switch to
a different environment with a completely different visualization.
E.g., whereas i am completely fine with

  colour mono sum-dotmark   ft=bold,ft=reverse dot
  colour mono sum-headerft=bold dot
  colour mono sum-threadft=bold dot
  colour mono view-header   ft=bold from,subject
  colour mono view-msginfo  ft=reverse,ft=underline ''
  colour mono view-partinfo ft=bold,ft=underline ''
  colour mono mle-position  ft=bold ''
  colour mono mle-promptft=bold ''

on a monochrome display (the reverse is even too much), i also
like switching to

  colour iso sum-dotmark   ft=reverse,fg=blue dot
  colour iso sum-headerfg=blue dot
  colour iso sum-threadfg=blue dot
  colour iso sum-threadfg=magenta ''
  colour iso view-from_fg=brown ''
  colour iso view-header   ft=bold,fg=red from,subject
  colour iso view-header   fg=red ''
  colour iso view-msginfo  fg=green ''
  colour iso view-partinfo fg=brown ''
  colour iso mle-position  ft=bold ''
  colour iso mle-promptfg=red ''

on a normal eight-colour display and really like, for quite some
weeks now, periodically switching over to

  colour 256 sum-dotmark   ft=bold,fg=13 dot
  colour 256 sum-headerfg=19 older
  colour 256 sum-headerfg=16,bg=219 dot
  colour 256 sum-headerfg=17 ''
  colour 256 sum-threadft=bold,fg=164,bg=219 dot
  colour 256 sum-threadfg=172 ''
  colour 256 view-from_fg=142 ''
  colour 256 view-header   ft=bold,fg=red from,subject
  colour 256 view-header   fg=124 to,cc
  colour 256 view-header   fg=203 reply-to,mail-followup-to,user-agent
  colour 256 view-header   fg=88 ''
  colour 256 view-msginfo  fg=green ''
  colour 256 view-partinfo fg=brown ''
  colour 256 mle-position  fg=202 ''
  colour 256 mle-promptfg=red ''

on a 256-colour display, even though that is, well, colourful.

 |But one factor nobody's mentioned is the fact that some
 |users are color blind, and the wrong combination of
 |colors can make a page very difficult to read, and that
 |is NOT what's needed.

I wouldn't enable this by default, then.  That is easy to do if
the software is a good one and the mechanism as such is backed by
good code.

I.e., the software should be capable to automatically detect
whether colours are applicable, choose the right terminal sequences
to realize what is desired, etc.  I don't really honour the latter
because i always have presupposed ISO 6429, i.e., ANSI
attribution, which originates in the 1970s.

 |I suggest leaving well enough alone.  Black text on a
 |white background has always worked well.  Strong
 |contrast (NEVER grey on white like so many "modern"
 |graphic designers seem to think is so pretty, even if
 |it makes text much harder to read) is still the best
 |way to put text on a screen or on paper either for
 |that matter.
 |
 |My engineering manager from decades ago said the best
 |designs are always the simplest, and have the least
 |need for adjustments.

I do appreciate clean and reduced designs myself

Re: [Groff] colorized man pages

[Steffen Nurpmeso]

John Gardner  wrote:
 |Adding colours to manual-pages is a solution to a problem that doesn't
 |exist. It's purely aesthetic.
 |
 |As both a graphic designer *and* a programmer, I can say with confidence
 |that both disciplines exist to solve problems. If colour is what helps a
 |reader navigate a manpage's content, then the content in question is
 |probably a victim of a more mundane issue of poor structuring, verbosity,
 |and/or misuse of formatting.

I'm hoping for you that being a graphic designer with a preference
for minimalistic designs makes a living.  ^.^

In the end that feature would (hopefully will) also be for you,
then, because when i look at the manual of my MUA, which uses mdoc
and has been tweaked with commitment to be fully referenced
(regarding .Ev, .Va, .Ic, .Xr, .Cd etc.), with or without the
mdocmx extension enabled, i see many, many words which are
underlined or bold already today.  And then turning on the mdocmx
extension enabled hundreds and hundreds of functional hyperlinks,
also on the TTY and in less(1), ^.^, and those are ISO blue.  If
i could, i would use a colour which does not stand out _that_
much, for example.  I think it would be a good thing to have.

--steffen

Re: [Groff] colorized man pages

[Steffen Nurpmeso]

Tadziu Hoffmann  wrote:
 |> Raw VT-100 escape sequences, in 2016.  Where will it all end?
 |
 |Steering wheels.  On cars.  In 2016.  Where will it all end?

I hope not for joysticks, or maybe only for cars driven by women.
Instead something more motorcyclish, where both hands can do
something.

 |Seriously:  what's wrong with escape codes?  I mean, if you're
  ..
 |still working with a text terminal, I'd expect escape codes to
 |be your daily bread and butter, not something to scoff at.
 |(Unless I'm missing the good-natured, approving irony here?)

Yah!  It seems control codes won't go away, Unicode adds
some more of them.

 ..
 |> It shouldn't be too much work to instrument a few important
 |> man and mdoc macros and add an environment variable, say,
 |> MANUAL_COLOURS, in equal spirit to LS_COLORS.  In the Linux
 |> world there is now a dircolors(1) command which can be used
 |> to control LS_COLORS.
 |
 |Coloring ls output adds semantic information from the mode
 |bits and the file type (normal files, device files, fifos,
 |links, etc.).  The "colored manpages" trick really has
 |nothing to do with man, it simply colors bold and underline
 |in the terminal.  To perform the equivalent of dircolors with
 |manpages will require actually rewriting the manual pages
 |and adding semantic information by hand (a *lot* of work).

Yes, i have read the referenced article.  That is a hack that
people use, but i was referring to something durable, regular.
For something semantically correct, yes, but – you know i had to
think about it – as a starter being able to define several
mappings wouldn't be that bad.  We have bold and underlined
output, why not warp that on request to something, _if_ the
terminal supports it.  I.e., /dev/tty i guess would have to be for
roff.  Also i think being able to map the plain roff colour names
would then be nice too, the blue that is used for URLs is really
screaming on this terminal, in the context of a manual.

  ..
 |> Black text on a white background has always worked well.
 |
 |On paper, using ambient light, yes.  On a self-luminous screen,
 |large areas of white are too bright and are hard on the eyes.

Situation has so much improved with the LED monitors, compared to
earlier times.  On a window system i still have a FC/FC/F9
background though.

  ..
 |> Adding colours to manual-pages is a solution to a problem
 |> that doesn't exist. It's purely aesthetic.
 |
 |Decidedly not.  It's in the same league as highlighting
 |words in bold or italic/underline.  Or are you saying that
 |this is superfluous as well?  Compare the following:
 |
 |  zcat /usr/share/man/man1/bash.1.gz | GROFF_NO_SGR=yes nroff -man | less
 |  zcat /usr/share/man/man1/bash.1.gz | GROFF_NO_SGR=yes nroff -man | \
 |  col -b | less
 |
 |I prefer the former.

Me too.

 |Another thing to keep in mind is that not all terminals can
 |display bold text (meaning a different typeface); some of them
 |substitute text with higher brightness.  It does strike me as
 |reasonable to give users some choice in the matter by allowing
 |them to switch to a different color instead (or in addition).

 ..
 |> Of course that isn't possible with [g]roff because [g]roff
 |> already throws away the information about macros in the
 |> preprocessor.
 |
 |Uh, no.  (What preprocessor, by the way?)  Apart from bold
 |and italic, the information simply isn't there.  And if it
 |were, you could of course transfer it to the output by using
 |a different implementation of the manpage macros.
 |This has nothing to do with the *roff syntax per se, but
 |rather with what has been captured by the manpage author.
 |
 |I think we have gone over this topic before on this list,
 |ad nauseam.  A long time ago, DEC had added semantic
 |information to their manual pages (all in [nt]roff format).
 |They called it "OSF Reference Semantic Markup Language"
 |and distinguished between ordinary text, emphasis, literals,
 |variables, alphabetic constants, numeric constants, system
 |(user) input, and system (computer) output, together with
 |markup descriptions of headings, lists, figures, etc.
 |Notwithstanding the effort, it hadn't really caught on.
 |My guess is because existing manual pages were "good enough".
 |Ultimately, they're intended to be read by humans, and if
 |humans understand them their purpose has been achieved.

I didn't know about this OSF.  mdoc is there and available
everywhere where groff (at least) is, and many programmers are
more or less aware of it.  And i agree ^.^.  But i dislike that
the very large GNU and Linux communities started trashing the
manuals they have with blue font attributes instead of doing
something real and adding some semantic to GNU and Linux manpages,
for URLS.  They had and they have control over all parts of the
pipeline.  A few weeks ago i have read that yet another approach
on documenting Linux kernel code is going to be evaluated, so
there are actually people who have interest and the will to go
a st

Re: [Groff] colorized man pages

[Steffen Nurpmeso]

Ingo Schwarze  wrote:
 |Tadziu Hoffmann wrote on Tue, Aug 23, 2016 at 01:29:07AM +0200:

 ..
 |> And regarding the
 |> "ready-to-use solution" that has "long been available":
 |> for the most part, the semantic information is simply not
 |> encoded in the manpages.
 |
 |That is true for the Linux manpages project, which still uses the
 |man(7) language for manual pages, and for some other projects, in
 |particular GNU software, as far as that uses manual pages at all.
 |For BSD software, that statement has no longer been true since the
 |switch of almost all manpages to mdoc(7) 25 years ago, and various
 |other projects also use mdoc(7).

That is plain untrue unless all you look at is the .Nm and some
rare other constructs, which is not sufficient for a whole lot of
manuals, if not the majority of them.  And those are mostly completely
meaningless inside of large documents like the manuals of bash
(man), mksh (mdoc) etc.

  ..
 |> Ultimately, they're intended to be read by humans, and if
 |> humans understand them their purpose has been achieved.
 |
 |Very true.  In addition to that, and less importantly, semantic
 |searching is at times useful.  And *if* people want semantic markup
 |(which started this thread), they can have it (of course, as you
 |say, only for those manuals that contain semantic markup in the
 |first place).

No.  If you don't know where the root of something is, you can
only provide a list of occurrences of that something.  That
improves searching, but that is all there is about it.
If you have a book of only 200 pages and you have several dozen
occurrances of a correctly marked .Va, then be lucky that you are
in less(1) and not in a paperback.  In an index list of several
dozen places, your concept misses the single bold entry.

I am still dreaming, and it is possible that you could have a real
handbook of all the installed software of your box, automatically
created and semantically correct, with index and toc.  mandoc
-Thtml /usr/share/doc/man* is a great thing, and it is quite fast,
but it won't give you that result.

--steffen

Re: [Groff] colorized man pages

[Steffen Nurpmeso]

Larry Kollar  wrote:
 |> Steffen Nurpmeso  wrote:
 |> 
 |>|still working with a text terminal, I'd expect escape codes to
 |>|be your daily bread and butter, not something to scoff at.
 |>|(Unless I'm missing the good-natured, approving irony here?)
  ..
 |>|> It shouldn't be too much work to instrument a few important
 |>|> man and mdoc macros and add an environment variable, say,
 |>|> MANUAL_COLOURS, in equal spirit to LS_COLORS.  In the Linux
 |>|> world there is now a dircolors(1) command which can be used
 |>|> to control LS_COLORS. ...
  ..
 |> For something semantically correct, yes, but – you know i had to
 |> think about it – as a starter being able to define several
 |> mappings wouldn't be that bad.  We have bold and underlined
 |> output, why not warp that on request to something, _if_ the
 |> terminal supports it.  I.e., /dev/tty i guess would have to be for
 |> roff.  Also i think being able to map the plain roff colour names
 |> would then be nice too, the blue that is used for URLs is really
 |> screaming on this terminal, in the context of a manual.
 |
 |AT&T nroff had what they called “drivers,” a compiled data structure \
 |that defined control codes for printer motions. In the early years of \
 |my tech writing career, I wrote one to take advantage of the NEC Spinwriter’\
 |s fractional motions; it supported stretchable spaces. GNU *roff doesn’t \
 |really have that. A custom post-processor might fill the bill, but is \
 |much more complex than a data structure.
 |
 |OTOH, a post-processor that hooked into terminfo could solve the problem \
 |almost automatically, no? If the user’s $TERM supports color, and a manpage \
 |requests color, then the user gets color. A register or string could \
 |be defined to set a color for highlighting bold body text and/or headings.

I was indeed thinking about adding support for termcap/terminfo to
the TTY output device, then.  So it would know whether there are
any #Co/#colors, how much of them, etc.  Screen dimensions (also
taking care for the standard $LINES and $COLUMNS).  It could then
of course also generate the sequences for bold etc. that the
terminal expects instead of using the standard ISO 6429 ones.

(The tty driver seems to use explicit SGR_ITALIC..SGR_NO_ITALIC,
so that there is an exact feature on/off mapping, which should
make this really easy to implement here.  In my own things i have
never done it like that but always presumed ISO 6429, where all
attributes can be turned off with a single command.)

And we surely could have a "simple" mapping mechanism that passes
in some font attribute or colour and gets back something modified.
This may become more complicated the more you look into it because
of the versatile set of output devices.  But this is C++ so this
may even be object based fun in the end.

--steffen

Re: [Groff] colorized man pages

[Steffen Nurpmeso]

"James K. Lowden"  wrote:
 |On Tue, 23 Aug 2016 01:29:07 +0200
 |Tadziu Hoffmann  wrote:
  ..
 |> Seriously:  what's wrong with escape codes?  I mean, if you're
 |> still working with a text terminal, I'd expect escape codes to
 |> be your daily bread and butter, not something to scoff at.
 |> (Unless I'm missing the good-natured, approving irony here?)
 |
 |Yes, but who is still working with a text terminal?  

Oh.  I do.

  ..
 |mother of invention -- the author of the article I linked to decided
 |he'd like color in his man pages.  Where did he turn?  A style sheet in
 ..
 |So, yes, he's still working with a text terminal, after a fashion.
 |But the programmability of that text terminal is an accident of
 |history, its feature set long since made obsolete -- not useless, but
 |out-moded -- by graphical displays and GUIs.  That he reached for that
 |particular tool is a measure of how far we have come, and how far we
 |have not.  

In fact i personally was a bit disappointed to come back to look
into Linux about 2012/3 and see that the beautiful framebuffer
hasn't proceeded.  Before i've switched to FreeBSD ~2001/2 i think
that thing came up and there was a simple, clean and documented
header in /usr/include that accessed some drawing graphics.  And
back then i for a moment was almost dreaming it would be possible,
just me and the kernel that is, because all i would have needed
beside a terminal is a PDF and a graphics viewer.  (I didn't know
about Plan9, despite the fact it is always graphical.  And of
course a compiler would never have made it.)

There was the Norton/Midnight Commander, but i really wouldn't
know of a better way, with full control and power that is, and
except for real doing-by-thinking, than a normal shell command
line.  I admit i never used David Korn's extended shell, because
for my everydays' work i have everything i need (including
a graphical browser) but that would be a direction that
i understand.

--steffen

Re: [Groff] Possible bug in -doc

[Steffen Nurpmeso]

Ingo Schwarze  wrote:
 |Carsten Kunze Heirloom wrote on Mon, Oct 03, 2016 at 12:31:02PM +0200:
 |> the problem in the document is the missing "-width" argument for .Bl.
 |> From groff_mdoc:
 |> 
 |> If a width is not specified for the tag list
 |> type, every time ?.It? is invoked, an attempt
 ..
 |Even if we would want lists with non-uniform indentation, binding
 |that to the default widths of the first macros renders the feature
 |practically useless, and besides, i don't consider changing indentation
 |within a list typographically sound.  It will confuse manual readers

I agree with the first, but not with the latter.  Having
a definition list with some few first words in a different style,
e.g., bold or emphasized, than directly following text in the same
paragraph block, i.e., term and definition, or tag and text, in
the same paragraph, is pretty common, i think.

That, however, is not possible with .Bl, and a quick look last
week showed that it cannot be implemented easily for the very same
reason that forces mdocmx to produce link references as suffixes,
not prefixes.
Just my one cent.

--steffen

Re: [Groff] Possible bug in -doc

[Steffen Nurpmeso]

Hallo.

Ingo Schwarze  wrote:
 |Steffen Nurpmeso wrote on Mon, Oct 10, 2016 at 01:41:43PM +0200:
 |> Having a definition list with some few first words in a different
 |> style, e.g., bold or emphasized, than directly following text in
 |> the same paragraph block, i.e., term and definition, or tag and
 |> text, in the same paragraph, is pretty common, i think.
 |> 
 |> That, however, is not possible with .Bl,
 |
 |Of course that is possible in more than one way, and completely
 |trivial.  Here are just three ways as examples for the many ways
 |to achieve it:
 |
 |  .Bl -hang

Then i was mistaken.

  ...
 |The -diag and -ohang types can also be used, and even -bullet, -dash,
 |-enum, and -hyphen, if you want to.  And you can of course do it
 |with .Pp alone, without any .Bl whatsoever.
 |
 |However, this isn't related to the original problem at all, which
 |was overcomplicated rules for handling lack of -width in .Bl -tag.

I am not in your way.  It seems to have been existent everywhere
before the removal, and now has been removed.  (And i will follow
in a distant future.)

Ciao -- and sorry, i have used those you have mentioned myself in
the past, i only had a look at -tag code and saw it starting the
recursion!

--steffen

Re: [Groff] speedata Publisher: XML to PDF.

[Steffen Nurpmeso]

Ralph Corderoy  wrote:
 |I'm no fan of XML, but I thought this command-line PDF producer from an
 |XML file may be of interest.  Has Lua somewhere under the covers.
 |https://speedata.github.io/publisher/index.html

Pretty cool indeed, and from a glance it seems to be very clean.
I really rather have a rocking roff at my fingertips, however.

XPath, XSL, etc., i luckily never had to deal with.  I.e., i even
bought a recommendet book in 1999, Goldfarb/Prescod, "The XML
Handbook", but: _don't buy it_, since it doesn't offer anything
real but advertisement.  Buuh!  (It is outdated anyway.)

Roff would deserve to become being more hip again, and as for many
good things i am confident it will happen again.  It is good.

--steffen

Re: [Groff] Applying commands to all pages

[Steffen Nurpmeso]

"Brendan Caluneo"  wrote:
 |So I decided to experiment a little with my own macro package. A problem 
 |I am having right now is how to make commands, such as ".sp x" to set 
 |the top margin, apply to all pages, not just the first one. I'm 
 |completely lost and would appreciate any help with solving this problem.

It is event-driven, and you set "traps", which then get evaluated
at appropriate times.  Unfortunately the manual is a bit spread,
and you will find yourself jumping around like grazy before you
get the glue and only need to look up details.  I think reading
the original document from Joseph F. Ossanna and Brian W.
Kernighan is a better starter than the GNU troff manual.  Search
the internet for cstr#54-troff-revised.pdf -- some members of this
list have revised the original, and i think for the better.
Ciao,

--steffen

Re: [Groff] Applying commands to all pages

[Steffen Nurpmeso]

Mike Bianchi  wrote:
 |On Thu, Nov 10, 2016 at 04:35:34PM +0100, Steffen Nurpmeso wrote:
 |> ... Search
 |> the internet for cstr#54-troff-revised.pdf -- some members of this
 |> list have revised the original, and i think for the better.
 |
 |I cannot find anything searching for
 | cstr#54-troff-revised.pdf
 | or
 | troff-revised.pdf
 |
 |Are you referring to the 1992 version by Brian Kernighan?
 |THAT I can find.

Indeed that is what i seem to have, too.  But i also seem to
recall a thread on this list about a modernized manual on troff,
based on cstr#54?  I can't find it, however.  But i am pretty sure
that i have read a paragraph with names of members of this list.
Whatever that was, then, that is to say.
troff.org and schaffter.ca would also be useful pointers for
Brendan.

--steffen

Re: [Groff] Applying commands to all pages

[Steffen Nurpmeso]

Hello.

Is there any particular reason this is getting private?
I would prefer public lists since answers to your questions can
very well be interesting for other readers of the ML.  I really
would like to forward this answer to the ML unless you speak
against it.  What is wrong with that?  Say, come on, i'll Cc: it
right away.

"Brendan Caluneo"  wrote:
 |the package can format MLA style essays, but I am having a problem \
 |with one word 
 |widow lines. For example, given the line "The highest rating it can \
 |receive: AO for Adults Only.", the page breaks after the first "the" \
 |but the word 
 |"highest" is put in the header with the page numbering while the rest \
 |of the sentence continues on an inch from the top as it should. Something \
 |like:
 |
 |The
 |
 |- page break (this is the header for page numbering)-
 |
 |highest 

That i don't understand.  Roff uses special requests for header
and footer lines; if you want to do that in some special way so
that it serves your purpose, you should create .di (versions) and
dump them out at appropriate times.

 |Caluneo 2
 |
 |-spacing (back to where the essay text should go)-
 |
 |rating it can receive.
 |
 |I've read pages elsewhere about how to fix this, but none of the solutions \
 |they yielded worked for me.

Well the manual has section 5.16 on "Page Control".
The request to deal with orphan lines is .ne, and you will likely
have a hard time getting the paragraphs right.  E.g., i have
a paragraph macro that is (and i have ".blm PARA", too, and yes
the requests are all .als aliases of real roff requests)

  .NUMBER #PARA_SPACE 1v
  .NUMBER #PARA_INDENT 0
  .MACRO PARA
  .\" FIXME
  .  br
  .  \" Suppress any spacing before _and_ at (!) pagestart
  .  ie ((\\n[ROFF:#VERT_POS]u > \\n[S:#PAGE_START]u)) \{\
  ' sp \\n[#PARA_SPACE]u
  . if (\\n[ROFF:#PAGENO] = 1) \{\
  .if !d S:TOP_BOXES_SET .S:CHECK_TOP_BOXES

I indeed have some code for doing my own headers, too, and to be
able to get that for the first page (as opposed to follow pages
where the page trap .wh comes into play) i seem to have found no
better solution than this.

  . \}
  . if (\\n[ROFF:#VERT_POS] >= \\n[S:#PAGE_END_CRITICAL]) \{\
  .ne \\n[#ORPHAN_LINES]

I have a page layout calculator which gets sprung for each page,
too, and it sets a critical dimension (as via

  .  nr S:#PAGE_END_CRITICAL \\n[S:#PAGE_END]u-(\\n[#ORPHAN_LINES]u*1v)

) that is then used to adjust .ne requests on the fly, whenever
a paragraph is newly opened.  I.e., you need to (or should) have something
that can be sprung via traps as well as because of explicit user
requests, say a new paragraph.  Otherwise you will sooner or
later have a layout problem that is not solvable except by placing
command into the document itself, and that is something that i for
one really dislike a lot.

  . \}
  .  \}
  .  if \\n[#PARA_INDENT] \{\
  . ie d S:PARA_NOINDENT .rm S:PARA_NOINDENT
  . el .ti \\n[#PARA_INDENT]u
  .  \}
  ..

Hope this helps,
Ciao from gray Germany,

--steffen

Re: [Groff] groff developments - query about any interest?

[Steffen Nurpmeso]

 wrote:
 |Werner LEMBERG  wrote (Thu, 17 Nov 2016 09:02:52 +0100
 |(CET)):
 ...
 |> Alas, Vienna is a bit too far away from Berlin...  BTW, what do you
 |> mean with `left behind'?
 ...
 |Also:
 |markdown/ ReST -> HTML is superior to groff -> HTML.

Surely this is not necessarily true.  I would love to have a HTML
filter that just works, in order to simply convert Unix manual
pages to HTML if i want to.  (And, yes, with mdocmx anchors and
thus fully interlinked.)  Unfortunately it is not that easy even
though massive amount of manpower has been put in this, but if
i convert the manual of the MUA i am sticking in so much that
i seem to have disappeared i need two of my work days of manual
adjustments to get it done, so, and only because of this, i agree.
Otherwise i would not.  Oh yes, there is plenty of interest.

--steffen

Re: [Groff] groff developments - query about any interest?

[Steffen Nurpmeso]

John Gardner  wrote:
 |> even though massive amount of *manpower* has been put in this
 ...
 | for Atom (a text editor
 |which is built using web technologies: HTML, CSS, JavaScript, etc). I

Yes, i've looked at that after you mentioned it first.  Indeed
a DOM structure and model-view-controller with editing and
displaying that beast is surely almost optimum, from wherever you
look at it.  Yet :), i'm afraid that is nothing for me, i tend to
have a load average of 0.00 on my laptop, and anything else makes
me nervous.  (Pretty old generation.)
Ciao,

--steffen

Re: [Groff] overview of man(1) and groff(1) command line options

[Steffen Nurpmeso]

Ingo Schwarze  wrote:
 |i just assembled an overview of all the command line options of
 |man(1), groff(1), and closely related utilities:
 |
 |  http://mdocml.bsd.lv/man/man.options.1.html
 |  http://mdocml.bsd.lv/cgi-bin/cvsweb/man.options.1

Good sleuthing, it seems to me.
I felt the immediate desire to include it, but then again that
wouldn't really make sense. ^.^

 |That may hopefully be useful for people who are forced to add a
 |command line option to one of these tools or to a similar one in
 |the future - of course, if you can avoid adding an option, please
 |refrain from doing so, but sometimes that's just not possible.
 |
 |I figure that, if such a list had been available earlier, it would
 |contain less clashes.  I admit to being responsible for some of the
 |clashes myself, but when i implemented those options years ago, i
 |simply didn't find all the needed information.
 |
 |If you see any errors or omissions, you are welcome to point me to
 |sources of information.
 ...
 |P.S.
 |One curiosity is that the oldest information i could find about
 |groff comes from Kirk McKusick's Berkeley CSRG archive CDs, and not
 |from the official groff git repository.  The oldest BSD release i'm
 |aware of that contained groff is 4.3BSD-Net/2 released on August
 |20, 1991 (or maybe up to two months earlier, sources are contradictory).
 |It contained groff-1.01, released on March 13, 1991, and the complete
 |source code is available.  The first groff release contained in git
 |is groff-1.02, released June 2, 1991.  I wasn't aware of that when
 |Eric S. Raymond assembled the git repo, or of course i would have
 |spoken up.  Even now, i couldn't find sources of groff 0.4 (July
 |14, 1990), 0.5 (August 21, 1990), 0.6 (October 22, 1990), 0.7
 |(December 18, 1990), or 1.0 (January 6, 1991) either, or any
 |information about anything that predates groff-0.4.

This is interesting.  I have only the csrg.git of Jonathan Gray,
not the unix-history.git of Diomidis Spinellis (unfortunately),
and even though that csrg.git mentions groff quite often, it is
only because of necessary macro adjustments, no source code
around.  I didn't know this.

 |P.P.S.
 |Maybe you want to rebase?  ...  Oh, just kidding.  :)

Hmm.  This shouldn't be that hard, the repo only has about two
dozen tags!  I have made this terrible mistake with the mailer
i maintain, and now the timeline branch is practically "sealed"
with a hole from 1980 to 1996, thus requiring an additional or
replacing "history" branch later on.  Better care next time would
be nice, and less follow-up work.

 |P.P.S.
 |The reason for doing this research right now is that i may be forced
 |to add a completely new option to mandoc(1), but i'm still unsure
 |about various details, i'm still pondering.  The rough goal is to
 |help a tool that does bulk conversions, but in a context where
 |catman(8) is probably not ideal; again, it's not a good time to
 |discuss the details of that yet, much is still unclear, i'm only
 |mentioning it such that you can understand the motivation, if you
 |wonder about it.

I am all in favour of those nice double-minus self-describing long
options, which can't be mistreated.  I could donate a small long
option parser that should be just fine.  (It is about 6KB .cc and
12KB .h; C++ plus but easy to convert to C.  And that includes
a long-option validity checker, for development checks.  From
2003, last touched 2005, at that time i was a pretty good
programmer i think.)

--steffen

Re: [Groff] ASCII Minus Sign in man Pages.

[Steffen Nurpmeso]

Ralph Corderoy  wrote:
 |Clarke wrote:
 |> used the simple hyphen character because it was all monospace.
 |...
 |> If a minus sign appeared in regular text, I always used \(mi.
 |
 |It was a lot easier then when the was only ASCII `-' and nothing else.
 |:-)
 ..
 |I'm no clearer.  Except I'm not sure what I want is possible.  So what's
 |"best practice" when aiming at groff, non-groff, old systems,
 |proprietary systems?

I use U+002D hyphen-minus.  The minus sign is a mathematical
symbol, i would say.  Hyphen-minus logically combines two words.
But that came naturally, i didn't really think about it.  Maybe
the text-processor should be so smart to realize that the actual
use cases combines words without an intermediate newline, and
should correct the glyph "to look nicer" in that case?

--steffen

Re: [Groff] ASCII Minus Sign in man Pages.

[Steffen Nurpmeso]

"G. Branden Robinson"  wrote:
 |At 2017-04-21T21:56:24-0400, Doug McIlroy wrote:
 |> I think it's pretty hopeless to ask for AI that can tell
 |> whether a pasted symbol is a hyphen or a minus sign.
 |> The answer is likely to depend on whether it is being
 |> pasted into a program or into a document.
 |
 |Here's my attempt at clarifying the issue.

I for myself will keep all that in my queue; but i think it will
be better to write something like "unless documented otherwise",
and then add such notes for man(7) and mdoc(7).

--steffen

Re: [Groff] ASCII Minus Sign in man Pages.

[Steffen Nurpmeso]

Doug McIlroy  wrote:
 |I think it's pretty hopeless to ask for AI that can tell
 |whether a pasted symbol is a hyphen or a minus sign.
 |The answer is likely to depend on whether it is being
 |pasted into a program or into a document.

Of course you are right.
Just ignore my rash messages, please.

--steffen

Re: [Groff] ASCII Minus Sign in man Pages.

[Steffen Nurpmeso]

"G. Branden Robinson"  wrote:
 |At 2017-04-22T16:15:48+0200, Steffen Nurpmeso wrote:
 |> "G. Branden Robinson"  wrote:
 |>|At 2017-04-21T21:56:24-0400, Doug McIlroy wrote:
 |>|> I think it's pretty hopeless to ask for AI that can tell
 |>|> whether a pasted symbol is a hyphen or a minus sign.
 |>|> The answer is likely to depend on whether it is being
 |>|> pasted into a program or into a document.
 |>|
 |>|Here's my attempt at clarifying the issue.
 |> 
 |> I for myself will keep all that in my queue; but i think it will
 |> be better to write something like "unless documented otherwise",
 |> and then add such notes for man(7) and mdoc(7).
 |
 |Sounds reasonable.  Interested in a revised patch to do just that?  ;-)

Maybe so?  But, like its name says...
A nice rest-weekend i wish.

--steffen
diff --git a/man/groff.7.man b/man/groff.7.man
index ed53ca1a..c4e636a1 100644
--- a/man/groff.7.man
+++ b/man/groff.7.man
@@ -2824,7 +2824,15 @@ Unescaped: left quote, backquote (ASCII 0x60).
 .
 .TP
 .ESC -
-The \- (minus) sign in the current font.
+The mathematical \- (minus) sign in the current font.
+Some macro packages, namely
+.BR groff_man (7)
+and
+.BR groff_mdoc (7) ,
+which support generation of Unix manual pages, map this to
+U+002D hyphen-minus instead.
+(E.g., this usually allows for copy and paste usage of
+manual content.)
 .
 .TP
 .ESC _
diff --git a/man/groff_char.7.man b/man/groff_char.7.man
index 1869f951..719b9f1c 100644
--- a/man/groff_char.7.man
+++ b/man/groff_char.7.man
@@ -268,7 +268,10 @@ single quotation mark; the original character can be obtained with
 .TP
 .B -
 the ISO \%latin1 \[oq]Hyphen, Minus Sign\[cq] (code\ 45) prints as a
-hyphen; a minus sign can be obtained with \[oq]\f(CW\e-\fP\[cq].
+hyphen; a mathematical minus sign can be obtained with
+\[oq]\f(CW\e(mi\fP\[cq].
+Explicit symbols can be found in the table
+.BR Punctuation .
 .
 .
 .TP
diff --git a/tmac/groff_man.7.man b/tmac/groff_man.7.man
index f207ef6d..e618f775 100644
--- a/tmac/groff_man.7.man
+++ b/tmac/groff_man.7.man
@@ -1135,6 +1135,14 @@ preprocessor(s).
 .SH "PORTABILITY AND TROFF REQUESTS"
 .\" 
 .
+The
+.B man
+macros remap some characters, e.g., the minus sign \-.
+To gain specific punctuation and other symbols it is advisable
+to use explicit requests, see
+.BR groff_char (7)
+for more.
+.
 Since the
 .B man
 macros consist of groups of
diff --git a/tmac/groff_mdoc.7.man b/tmac/groff_mdoc.7.man
index 5968d0b6..36541720 100644
--- a/tmac/groff_mdoc.7.man
+++ b/tmac/groff_mdoc.7.man
@@ -4147,6 +4147,14 @@ A normal user will never need it.
 .
 .Sh "FORMATTING WITH GROFF, TROFF, AND NROFF"
 .
+The
+.Nm
+macros remap some characters, e.g., the minus sign \-.
+To gain specific punctuation and other symbols it is advisable
+to use explicit requests, see
+.Xr groff_char 7
+for more.
+.Pp
 By default, the package inhibits page breaks, headers, and footers if
 displayed with a
 .Tn TTY

Re: [Groff] Nesting font macros in man pages

[Steffen Nurpmeso]

"G. Branden Robinson"  wrote:
 |At 2017-04-24T18:29:57+0200, Ingo Schwarze wrote:
 ...
 |I entirely agree with the virtues of semantic of "presentation"-based
 |markup.  However, this could be mitigated by encouraging a consistent
 |style in groff_man(7) itself.  Some coordination with Michael Kerrisk et

I don't think this will work.  Only in an ideal work.

 |al. of the man-pages project would be valuable as well; I think almost
 |all of the advice in man-pages(7) of that package is very sound.

I think at least the structural information guidelines should
somehow end up in the roff_man(7) that ships with roff in the end,
it would mirror what there is roff_mdoc(7).

  ...
 |People keeep writing in man(7).  Let's do what we can to help them write
 |it better.

 |I submit that one reason mdoc didn't take over the world is for the same
 |reason DocBook didn't--it's too huge.  I think that man(7), even with
 |the an-ext stuff added on, is small enough to keep in one's head.
  ...
 |Of course what we need is a converter that goes in the other direction;
 |but that requires the encoding of semantic information that is lacking.

Self-describing macro names may be helpful.
In my opinion mdoc is gross and terrible, and you cannot even use
it to document C code very nicely.  But it has semantic
information and that is necessary for good manuals in a generic
language; you can very well create your own macros and process
them with scripts and tools to create the necessary environment,
but that is not generic.

Currently i think the future is some rich-text thing like asciidoc
or similar, and what would be needed would be good converters to
roff, and then mdoc not man, because it keeps at least a bit of
semantic information.  Or a completely new roff manual language.

I for one keep being disappointed when i see how much work is put
into books and articles, with footnotes, TOC, index, etc.  It
would be nice if you could run mandb and get a real book, cross-
referenced, with index, even better than what texinfo is or was.

 |I'd like to see what we can achieve by fiddling with it _without_
 |harming its portability.  Even as small as man(7) is, people neglect a
 |lot of its capabilities.

Yes, i think people mostly do it by copying over and/or looking
into manual pages they think look good, rather than by reading the
manual, or bying a good tutorial book that leads them step-by-step, 
but fast!, to good results.  That is the material world baby, you
want the burger royal with fifteen, whereas a Ayurveda masseur has
to sit beside his master and wait for i think seven years before
he gets his hands at the subject.

--steffen

Re: [Groff] Nesting font macros in man pages

[Steffen Nurpmeso]

Ingo Schwarze  wrote:
 |G. Branden Robinson wrote on Tue, Apr 25, 2017 at 07:14:58AM -0400:
 ...
 |> If that means a new macro, I'm fine with that.
 ...
 |For man(7), introducing new macros would be worse.  There, it would
 |utterly break portability because other implementations do exist,

Now i really oppose that.  That is utterly shit, Ingo.  You can do
whatever you want, except for "security sandbox" restrictions
(iirc some commands don't work).  You could use the painting
commands if the output works fine on the tty even.  You could
dynamically generate parts of the manual page.  Most people don't,
but they could be almost completely free if they want to, and
i for one consider this as something important.

Of course such things won't work in mandoc then, but 99.9 percent
of all manuals will do just fine, and much, much faster than roff
will ever be able to serve.  While you complain about the somewhat
broken grohtml, the HTML output of mandoc used repeated
per-paragraph style directives and a CSS file, which caused
enormous bloat, last time i tried.

  ...
 |I'm a strong believer in incremental software development.  But
 |there are exceptional cases where incremental improvements are not
 |viable, in particular when the basic paradigm employed is busted
 |and the language is a dense tangle of historically cemented layering
 |violations.  The man(7) language is one of these cases.  Fortunately,
 |it has been obsolete for 25 years now, and mdoc(7) is mature and

Oh, come on Ingo.  man is obsolete for 25 years?  In the BSD
world, of which i feel part of for almost fifteen years myself,
but that is not the motor of the software world, by far.  Of
course you can build a car with only stolen parts.  Still, those
have to come from somewhere.

Btw., if you want really clean man(7) you should point people to
the really good guys, e.g., the plan9port manuals are a phantastic
example of minimalistic and pure pages.

 |> My recommendation is to take the momentum an-ext has, however small, and
 |> press it:
 |> 
 |> a.  Add more macros to fit semantic needs and the hiding of lower-level
 |> requests and escapes.
 |> b.  Hand-hold users to the nth degree with examples and recommended best
 |> practices.
 |> c.  Show people a mapping from groff's "extended" man macro package to
 |> mdoc, so that the route for switching over is clearly signposted.
 |
 |It seems to me that b) is fine, a) is very problematic because it
 |severely harms portability, and c) may or may not help to convince
 |people.  I'm not sure the intermediate step of reinventing man(7)
 |as a semantic language will make the transition easier.  Why should
 |people have to learn a new man(7) language in between, in addition
 |to the old man(7) and in addition to mdoc(7)?

Even though still without voice, a) is in no way problematic if
the original roff command set is used and no wild and funny
programming sessions lead to mandoc incompatibilities.  b) is
fantastic, c) i don't really believe in, mdoc has quite some
similarities to brainfuck, things like

  .Op : Ns Fl c Ar cc-addr Ns \&:
or
  .Fl S Ar var Ns Op Ns = Ns Ar value Ns

are nice for teaching, but no one can really promote something
like this, can he.

And sometimes things have to be adjusted a bit so that things can
overall stay the same.  The roff system is a fantastic
achievement, and if at all possible i will use it until the day
i die.  I am looking forward for my thing.

--steffen

Re: [Groff] Nesting font macros in man pages

[Steffen Nurpmeso]

"G. Branden Robinson"  wrote:

Sorry for answering so late, my daily routine has shifted to night
again, almost sunset, and that really makes me frustrated.

 |At 2017-04-25T20:19:21+0200, Steffen Nurpmeso wrote:
 ...
 |>|> c.  Show people a mapping from groff's "extended" man macro package to
 |>|> mdoc, so that the route for switching over is clearly signposted.
 ...
 |> fantastic, c) i don't really believe in, mdoc has quite some
 |> similarities to brainfuck, things like
 |> 
 |>   .Op : Ns Fl c Ar cc-addr Ns \&:
 |> or
 |>   .Fl S Ar var Ns Op Ns = Ns Ar value Ns
 |> 
 |> are nice for teaching, but no one can really promote something
 |> like this, can he.
 |
 |I have two gripes about mdoc:
 |
 |1. The slavish devotion to two-letter names for things, which like the
 |   man macro package and the oldest parts of *roff itself, make it
 |   self-anti-documenting.  I may be tempting mockery by saying this from
 |   a vi session inside an xterm, but good Lord, we've gotten past the
 |   days of ASR 33 teletypes by now[1].  (That said, I'm sure this
 |   unfriendliness was imposed by the existing *roff implementations at
 |   the time mdoc was designed.)

Sure it was.  I think there are multiple problems.
You have a notion of "callable" and "parsed", and you should be
aware of that or you introduce errors which are hard to find.  It
may be that you don't even see an error in the visual output
because no special font attribute applies or so.  Be aware that
"No" is a command that needs to be escaped.  Not rarely i see *BSD
commits fly by which fix errors in manual pages because of errors
in some nesting level, or missing escaping, and these programmers
use this language for many years or even decades.  Of course this
is part of normal iteration, too, but isn't it better if you have
a as-minimal-as-possible set of commands which clearly stand out.

Generally speaking both of man and mdoc spread the text and make
the source hard to grasp, which i don't consider to be something
viable, and which, together with the missing possibility to add
semantic information, here especially man, for richer output
formats, is surely part of the move away from roff.

  ...
 |2. Most of mdoc's own documentation is too technical, even in
 |   mdoc.samples.  I find the glib and frequent usage of the term
 |   "domains" off-putting and inaccessible, and I don't think I'm
 |   unusually stupid.  (Pauses for a beat.)
 |
 |But, not to pound on Ingo's beloved too much, from what I understand of
 |mdoc's design, I find it much, much better considered than man(7).  It
 |clearly benefited from having a large corpus of existing man pages to
 |consider, so it knew better than man(7) did what sort of problems it was
 |going to have to solve.

If i got that right it came up after the info system, and i will
always wonder why you do have semantic info for targets, but not
for sources, especially if you do invent a command set where many
commands take arguments, e.g., you do have ".Bd -literal", you do
have .Sx to refer to a heading, you do have .Va to refer to
a variable, why not ".Va -index" or the like, so that you can
specify where the .Va has been defined?  That is such a crucial
part of good documentation, especially in science, a good index!,
why was that missing.

 |> And sometimes things have to be adjusted a bit so that things can
 |> overall stay the same.  The roff system is a fantastic
 |> achievement, and if at all possible i will use it until the day
 |> i die.  I am looking forward for my thing.
 |
 |Agreed.  Any proposals I make are with an eye toward making the roff
 |system better, not worse.  That could go without saying--but I guess I

Yes.

 |should emphasize that I'm here not to bury groff, but to praise it.
 |
 |Unlike, I think, [2].

I don't use doclifter.  And i prefer less and the tty over
anything else, really.  A few URLs to kick off, fine, but it is
absurd to go over the internet if the information is often
available locally already.  Anyway..

  ...
 |[2] https://lists.gnu.org/archive/html/groff/2014-02/msg00104.html

--steffen

Re: [Groff] Nesting font macros in man pages

[Steffen Nurpmeso]

Ingo Schwarze  wrote:
 |Steffen Nurpmeso wrote on Tue, Apr 25, 2017 at 08:19:21PM +0200:
 |> the HTML output of mandoc used repeated per-paragraph style
 |> directives and a CSS file, which caused enormous bloat, last
 |> time i tried.
 |
 |Does that still apply to
 |
 |  view-source:http://man.openbsd.org/ksh
 |
 |I spent a few weeks in 2017 improving mandoc HTML output,
 |both with respect to functionality (better markup) and with
 |respect to HTML code quality.

It seems to have improved.  I would not be the first who is
astonished about the title attributes, but i still see quite some
style="margin-left: 6.60ex;" and also style="margin-top: 0.00em;".
It surely will be iterated over as time goes by.  I.e., having
a special class "Bl-item-compact" which inherits that
style="margin-top: 0.00em;" to all of its items.

 |In case there are still aspects that can be improved (in particular,
 |simplified) without loss of semantic markup quality and without
 |loss of presentational quality, specific hints are very welcome.

As above.  That is all for today, i spent three hopeless hours in
the pic lex code, even shallow cloned 67 MB of gnulib for a few KB
of datatable that doesn't get used the right way, and felt more
and more scatological.

 |P.S.
 |Only bacause i'm replying anyway and it's just five lines:

Sure.

 |>   .Op : Ns Fl c Ar cc-addr Ns \&:
 |>   .Fl S Ar var Ns Op Ns = Ns Ar value Ns
 |
 |That's full of cargo cult, things are actually much simpler
 |even for describing such unusually complicated syntax:
 |
 |.Oo : Ns Fl c Ar cc-addr : Oc
 |.Eo [: Fl c Ar cc-addr Ec :]

  .Op : Ns Fl c Ar cc-addr Ns \&:
  .Eo [: Fl c Ar cc-addr Ns :] Ec
  .Oo : Ns Fl c Ar cc-addr : Oc

I would like the last one best, if the Ns could go from the front.
.Eo, hmm this is in SYNOPSIS.  But yes, .Oo is better.  Also

  .Op Fl M Ar type | Fl m Ar file | Fl q Ar file | Fl t

will i think become

  .Oo Fl M Ar type | Fl m Ar file | Fl q Ar file | Fl t Oc

because that is better.  ^.^

 |.Fl S Ar var Ns Op = Ns Ar value
 |.Fl S Ar var Ns Op Pf = Ar value

That indeed is

  .Oo : Ns
  .Fl S Ar var Ns Op Ns = Ns Ar value Ns
  .Pf \&: Oc

Do you have any idea (and yes, i use .Pf, why not also before the
=, i don;t know) how to place this on one line?
Will do, ciao.

--steffen

Re: [Groff] Nesting font macros in man pages

[Steffen Nurpmeso]

Deri James  wrote:
 |On Thu 27 Apr 2017 20:12:09 Ingo Schwarze wrote:
 |> Does that still apply to
 |> 
 |>   view-source:http://man.openbsd.org/ksh
 |
 |compared with a PDF version:-
 |
 |http://chuzzlewit.co.uk/WebManPDF.pl/man:/1/ksh

Terrible, see the spacing errors surrounding the command list
before the "Substitution" heading!  Not your fault of course, but
gr...

--steffen

Re: [Groff] Nesting font macros in man pages

[Steffen Nurpmeso]

Deri James  wrote:
 |On Thu 27 Apr 2017 23:48:29 Steffen Nurpmeso wrote:
 |> Terrible, see the spacing errors surrounding the command list
 |> before the "Substitution" heading!  Not your fault of course, but
 |> gr...
 |> 
 |> --steffen
 |
 |Well, turns out it WAS my fault! Bug in gropdf, will commit after more 
 |testing. Thanks for the heads up, is this Ok?
 |
 |http://chuzzlewit.co.uk/WebManPDF.pl/man:/1/ksh

Yes.

--steffen

Re: [Groff] Nesting font macros in man pages

[Steffen Nurpmeso]

i wrote:
 |Ingo Schwarze  wrote:
 ||Steffen Nurpmeso wrote on Tue, Apr 25, 2017 at 08:19:21PM +0200:
 ...
 |As above.  That is all for today, i spent three hopeless hours in
 |the pic lex code, even shallow cloned 67 MB of gnulib for a few KB
 |of datatable that doesn't get used the right way, and felt more
 |and more scatological.

FYI, every change of a pic source file triggered regeneration of
font-files++ (i always did ^C once pic was done).

--steffen

Re: [Groff] Nesting font macros in man pages

[Steffen Nurpmeso]

i wrote:
 |Ingo Schwarze  wrote:
 ||Steffen Nurpmeso wrote on Tue, Apr 25, 2017 at 08:19:21PM +0200:
 ...
 ||P.S.
 ||Only bacause i'm replying anyway and it's just five lines:
 |
 |Sure.
 |
 ||>   .Op : Ns Fl c Ar cc-addr Ns \&:
 ||>   .Fl S Ar var Ns Op Ns = Ns Ar value Ns
 ||
 ||That's full of cargo cult, things are actually much simpler
 ||even for describing such unusually complicated syntax:
 ||
 ||.Oo : Ns Fl c Ar cc-addr : Oc
 ||.Eo [: Fl c Ar cc-addr Ec :]
 |
 |  .Op : Ns Fl c Ar cc-addr Ns \&:
 |  .Eo [: Fl c Ar cc-addr Ns :] Ec
 |  .Oo : Ns Fl c Ar cc-addr : Oc
 |
 |I would like the last one best, if the Ns could go from the front.

Actually i now see it was on purpose: with .Oo .. .Oc and without
the .Ns stuff there may appear linebreaks inside an option, which
i wanted to avoid.

--steffen

Re: [Groff] [PATCH] correct some \c-related markup

[Steffen Nurpmeso]

"G. Branden Robinson"  wrote:
 |Please find a patch attached.

Ordinary an ordinary, is that true.
I for one always found those one/two/one/two/.. macros very
suspicious, but now i see actual use cases.

--steffen
|Soylent Green is people!

Re: [Groff] : ASCII Minus Sign in man Pages

[Steffen Nurpmeso]

Doug McIlroy  wrote:
 |Originally \(pl and \(mi came from a fixed font (S) while + and \-
 |came from the current font. As I understand your comment, groff
 |has reversed this troff convention. Additionally groff interprets - as
 |a compromise HYPHEN-MINUS.
 |
 |man groff_char, however, tells the original state of affairs.  What is
 |one to believe?

I now think it is better to revert all those per-macro adjustments
altogether and be pure; if people use \- to get "nicer" (smoother
and finer that is) output then pasting from manual is simply
impossible.  Distributions like Debian can then still easily apply
remappings at well-known places and document it in their
guidelines.  And/or the remappings could be covered by
a conditional and a global per-site configuration file can set the
corresponding switch, which macro packages then honour.
I think this will be my distant target.

--steffen
|Soylent Green is people!

Re: [Groff] [PATCH] correct some \c-related markup

[Steffen Nurpmeso]

"G. Branden Robinson"  wrote:
 |At 2017-05-01T19:30:02+0200, Steffen Nurpmeso wrote:
 |> "G. Branden Robinson"  wrote:
 |>|Please find a patch attached.
  ...
 |> I for one always found those one/two/one/two/.. macros very
 |> suspicious, but now i see actual use cases.
 |
 |One of the advantages of some of them is that, if people think to use
 |them, they relieve the writer of having to remember to supply italic
 |corrections:

I came from TeX, and luckily groff then had strings with arguments
already!

  .STRING I \\,\\fI\\$*\\fP\\/

is \*[I almost] as easy (especially with US keyboard) as

  \def\it{\edef\@font@currIsBold{\FALSE}\@font@setFont{it}}%
  \def\tit#1{{\it#1\/}}

the \tit{version} of \TeX.  Almost as clean.

--steffen
|Soylent Green is people!

Re: [Groff] : ASCII Minus Sign in man Pages

[Steffen Nurpmeso]

Ingo Schwarze  wrote:
 |Steffen Nurpmeso wrote on Tue, May 02, 2017 at 11:50:31AM +0200:
 |> I now think it is better to revert all those per-macro adjustments
 |> altogether and be pure; if people use \- to get "nicer" (smoother
 |> and finer that is) output then pasting from manual is simply
 |> impossible.
 |
 |That is clearly the worst suggestion so far.  It is not just a

No, it is not.  Noone at all complained when thousands of lines of
rather or completely messed up stuff came into this software after
~2005, and i want to point out that several dozen pages of text
have been emitted to this list on the question whether \- should
be pastable or not.  My, that is me who has nothing countable in
the groff source, which is a pity, my first two sentences of this
thread were, and that is all about it

  I use U+002D hyphen-minus.  The minus sign is a mathematical
  symbol, i would say.

 |matter of "if (some) people".  Take, for example, mdoc(7).  It has
 |been enforcing \- for .Fl since its inception in 4.3BSD-Reno in
 |1990, and that wasn't a new choice even though man(7) does not

Noone at all seems to have been interested to give her some
feedback, look over the rim of his tea cup and enter a discussion,
otherwise we possibly would also have nice -idx options to several
commands.  Then you can't paste it, period.  Add or use the local
macro package to warp that to hyphen-minus upon request, that is
my opinion.

 |enforce rendering of command line options in any particular way,
 |but leaves the choice to the author; but standard practice, in
 |man(7) as well, has been to use \- for command line options since
 |the first release of man(7) in Version 7 AT&T UNIX in 1979.  And
 |that made sense at the time because the minus sign was ASCII 0x2d
 |in nroff(1), you couldn't cut and paste from a manual printed on
 |paper, and the distinction between Unicode U+002D HYPHEN-MINUS and
 |U+2212 MINUS SIGN did not yet exist.

But i think there were already font slots for graphical symbols
that could be addressed, right?  No, they surely have had lust,
coming back from playing Spacewar or SpaceInvaders or so, and have
some nicer graphical symbol.  That is not en par but just like the
one who drives a up to 60l/100km Ferrari because he gives a s..t.
The guys who are really used to the stuff and penetrated it do
things like

  .SH NAME
  deroff, delatex \- remove formatting requests
  .SH SYNOPSIS

I think he does this either because he and everybody else is used
to that for a long time.  I would prefer U+2014 EM DASH, my
PDF-to-text of the POSIX standard ends up with that one.

  The options are
  .TP
  .B -w

  .B Fhdr.next
  fields) of all currently open headers
  (see
  .I symopen
  in
  .IR mach-symbol (3)).

That is absolutely pastable, whether UTF-8 or not.
(I don't count myself among them, as i have sacrificed the good
for the bad, e.g., style for content, much too often myself.  But
now i am here, and i think that is better.)

 |So you propose that we break copy and paste from more or less all
 |manual pages now (including in -Tutf8 output which is the default
 |on terminals in many systems at this point), even though it has
 |been working just fine for almost 40 years?  You must be jesting.
 |
 |No, making the decision at this point in time that \- has to
 |consistently render as U+2212 MINUS SIGN is not an option at all.
 |That's one half of the reason why i suggested to make it render
 |consistently as U+002D HYPHEN-MINUS.
 |
 |> Distributions like Debian can then still easily apply
 |> remappings at well-known places and document it in their
 |> guidelines.
 |
 |So groff should do something that is unusable and ask downstream
 |distributions to fix it up to make it useable?  That guarantees
 |utter confusion and doesn't make any sense whatsoever.  What are
 |other formatters (like mandoc) supposed to do?  Mandoc doesn't even
 |have the distinction of "upstream" and "distribution" to implement
 |such a split in behavior.  Both FreeBSD and OpenBSD use the mandoc
 |code directly from the HEAD of the VCS.

I think a growing number of Linux distributions will follow.
Mandoc is faster and can even markdown now.  I cannot talk for
groff.

 |By the way, in the meantime, i also received support from NetBSD/pkgsrc
 |for my proposal (\- always U+002D, \(mi always U+2212).  That's
 |Ralph, Branden, NetBSD/pkgsrc, and one relevant FreeBSD developer
 |then, and no protest so far from OpenBSD.  I think i'll start
 |preparing patches and submit them to the groff bugtracker when they
 |are ready.

You are free to do whatever you want, of course.  I don't know
actually what i will do when i finally have time for my own roff
clone, i for myself have found what i think is a Solaris stdio bug
as well as a OpenBSD 6.1 grep(1) bug as well what i think is
a OpenBSD 6.0 make bug, but that i won't figure out no

Re: [Groff] ASCII Minus Sign in man Pages

[Steffen Nurpmeso]

Mike Bianchi  wrote:

I absolutely and completely support this opinion of yours.

Maybe except that it would be nice if some future user could
easily find some documentation and now what to do to get "nice"r
looking output, maybe with some command line argument (variable),
or a configuration file, because all those misuses came in for
a reason, and that cannot simply be neglected, after all.

--steffen
|Ralph says i must not use signatures which spread the light!

Re: [Groff] mom : unicode in .INCLUDE'd files

[Steffen Nurpmeso]

Ralph Corderoy  wrote:
 |>> You could try replacing `.INCLUDE' with `.so'.
 |>
 |> First thing I tried with the OP.  Same problem.  .so is definitely not
 |> playing nice with unicode.
 |
 |Ah, well, in that case, I think this explains it.
 ..
 |$ soelim foo | preconv | groff -Tutf8 | grep .
 |foo: ÄÖÜ SS ÒÓÔÕŎŌ Ç äöü ß òóôõŏō ç
 |bar: ÄÖÜ SS ÒÓÔÕŎŌ Ç äöü ß òóôõŏō ç
 |$
 |$ groff -V -Tutf8 -sk foo
 |preconv foo | soelim | troff -Tutf8 | grotty

In my humble opinion preconv has to go as such, i just do not know
yet.  Just talking.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [Groff] mom : unicode in .INCLUDE'd files

[Steffen Nurpmeso]

Hey, Ingo,

Ingo Schwarze  wrote:
 |Steffen Nurpmeso wrote on Fri, Jul 21, 2017 at 10:30:36PM +0200:
 |
 |> In my humble opinion preconv has to go as such,
 |> i just do not know yet.  Just talking.
 |
 |So much talk...

SIIGHH!!!

 |In mandoc, i completed that work in October 2014:
 |
 |  http://mandoc.bsd.lv/cgi-bin/cvsweb/preconv.c#rev1.9
 |
 |  "commit message:
 |   integrate preconv(1) into mandoc(1); enhances functionality
 |   and reduces code and docs by more than 300 lines"

I think that is the right thing, because

 |Admittedly, mandoc only handles UTF-8 and ISO-LATIN-1, and
 |requires the user to convert files using obsolete encodings
 |to UTF-8 using iconv(1) first.

there is iconv(1), and either preconv catches it all or it is not
needed.  Probably there should be an .iconv request, but that is
probably too late ... anyway, looking at emacs tags cannot be the
solution for roff, in my opinion.

 |The only reason for supporting ISO-LATIN-1 is that many old manual
 |pages in the wild still use it, most even without saying so.
 |Otherwise, mandoc would be UTF-8 only on the input side.

I do not know.. i mean, the really good guys sat down and thought
about it at a dinner and were ready to go, but this was about 25
years ago and Unix is still not en par, so i do not think this can
be a solution for roff, which needs to deal with documents other
than manuals.  I have no idea about non-english (and a few de)
manual pages (but those were often not up-to-date, so i tried to
get rid of them asap anytime i rememember; note this really is an
*unfortunately*, because the very high-quality translations of
ISO C that i have from Prof. Dr. A.-T Schreiner and
Dr. Ernst Janich, typeset in roff, made me forget i ever needed
anything else!), i seem to remember other character sets.  But
since it can be automatized i guess it is ok for mandoc to
require that systems which switch perform an iconv run.

 |In the long run, i think that would be a reasonable direction
 |for groff, too.  Preconv is notorious for causing trouble for
 |casual users, see the several threads that were quoted earlier
 |in this thread, and even very experienced users often get
 |confused about how it works and where in the pipeline it is
 |supposed to be, see this thread itself.
 |
 |"Groff input always has to be UTF-8", that would be a very simple,
 |fool-proof principle.

I do not think this will be the direction to go.  I have no idea,
i really like to get Unicode on the input side, but a conversion
in front of that may be fine, as long as it is picked up
automatically in a way that the author of the document specifies.
And the emacs tags are in the world, and thus need to stay for
quite a while, too. :(

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [Groff] mom : unicode in .INCLUDE'd files

[Steffen Nurpmeso]

"E. Hoffmann"  wrote:
 |Am Fri, 21 Jul 2017 16:28:04 -0400
 |schrieb Peter Schaffter :
 |
 |[...]
 |>> $ soelim foo | preconv | groff -Tutf8 | grep .
 |>> foo: ÄÖÜ SS ÒÓÔÕŎŌ Ç äöü ß òóôõŏō ç
 |>> bar: ÄÖÜ SS ÒÓÔÕŎŌ Ç äöü ß òóôõŏō ç
 |>> $
 |>> $ groff -V -Tutf8 -sk foo
 |>> preconv foo | soelim | troff -Tutf8 | grotty
 |
 |Thanks a lot.
 |
 |So, the solution's first step is to replace the .INCLUDE macro with the
 |plain .so request, and the second step is the preconv-pipe.
 |
 |Something remains.
 |
 |$groff -Tutf8 -V -sk example.mom
 |
 |gives:
 |
 |>preconv -eutf8 example.mom | soelim | troff -Tutf8 | grotty

Hmm, so unless i got something wrong Ralph showed this pipeline
uses the false order, because soelim includes external files after
the main body has already been converted, so that the included
files as such will not be covered by preconv.  Correct would be

  soelim | preconv -eutf8 example.mom | troff -Tutf8 | grotty

But this of course requires that soelim knows it has to handle
other inclusions than .so.  I think the best would be if there
would be a file-inclusion command which can be given a file-
specific character set, as in

  .include -charset=latin15 rest-of-line

or that soelim can learn more directives as alternative spellings
to .so, maybe

  .solearn INCLUDE
or
  .sopush INCLUDE

or whatever, but all this is not available.

As a general thought my impression always has been that normal
users should not be bothered with the pipeline as such, because
i can remember having seen .tr documents and being unable to get
it right because (a) i did not know and (b) i did not know about
the document.  My idea was, if i recall that correctly, having not
looked into this for two years (and one more week to come), that
of an introductional description line that roff can look at and
create the necessary pipeline itself. [Looking into that]  Ah ja,
indeed -- oh, i am sorry if i trash your thread with this, btw! --:

   Introduce a new command that can be used to select the preprocessors
   explicitly, e.g., ".preprocessors tbl,eqn" etc.
   If so, how to deal with included files?  Offer "-" mode which turns
   off preprocessors for a specific file?

   I think the best would be some kind of "shebang", for compatibilities
   sake it must be comment-based, as in '.\"!troff eqn tbl enc=latin1'?
   For example, newer man(1)s read the first line of the manual and
   check for a syntax <^'\" >followed by concat of [egprtv]+ (and in
   fact  *join in* $MANROFFSEQ environment [egprtv]+)
while getopts 'egprtv' preproc_arg; do
case "${preproc_arg}" in
e)  pipeline="$pipeline | $EQN" ;;
g)  GRAP  ;; # Ignore for compatibility.
p)  pipeline="$pipeline | $PIC" ;;
r)  pipeline="$pipeline | $REFER" ;;
t)  pipeline="$pipeline | $TBL" ;;
v)  pipeline="$pipeline | $VGRIND" ;;
*)  usage ;;
esac

   This is good, but pretty much crypto and nothing for normal users.
   But extending this, why not check for <'\" preprocess: tbl eqn"> etc.?
   And as above.
   And this is also documented in groff_tmac.man.  But do not bet on
   this.

No preconv in this pipeline spec, well...

 |Is there something else I can do?

Hard stuff for now.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [Groff] Bitstream vera sans

[Steffen Nurpmeso]

Hi.

mikkel meinike  wrote:
 |Can any of you walk me through what I should do to use the font 'bitstream
 |vera sans' in my groff document? The font is somehow available in my system
 |because I use it in my terminal (rxvt-unicode)

Peter Schaffter has written something that might help you out[1].
With it one can easily convert fonts for use with roff.

  [1] http://www.schaffter.ca/mom/mom-06.html

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [Groff] pdfmom grep (was parallel text processing)

[Steffen Nurpmeso]

Peter Schaffter  wrote:
 |On Fri, Sep 08, 2017, Ralph Corderoy wrote:
 |>> You'll notice that the top of the pdf file has a line of text spit out
 |>> by grep(1) that obviously shouldn't be there.
 |> 
 |> I couldn't come up with the groff 1.22.3-7 command line required to
 |> build the PDF correctly, nor get grep's unwanted output.  Deri suggested
 |> pdfmom's grep might be the culprit, but its stderr should end up on
 |> pdfmom's stderr?
 |
 |Problem solved.
 |
 |The superfluous line at the top of the file ["Binary file (standard
 |input) matches"] isn't stderr, it's stdout, so it becomes part of
 |the pipeline.  The grep in pdfmom is returning a binary file hit when
 |it encounters the diacritic in 
 |
 |  .ds pdf:look(pdf:bm1) L'étranger
 |
 |Since the binary file hit doesn't begin with .ds, it prints literally
 |at the top of the file.
 |
 |The solution is to pass the -a flag to grep.
 |
 |Deri: do you want me to fix this in pdfmom and push the change, or
 |would you prefer to do it yourself?
 |
 |Question: why does grep treat the presence of the diacritic as cause
 |for saying "Binary file (standard input) matches"?

Likely because that is true in your locale?  It is very likely
that this cannot work (i see -k could possibly happen), suppose
you are in a LATIN1 locale and process UTF-8, and it is even worse
when your own locale is more picky than LATIN1.  Strives me this
should be split up so that perl itself performs the grep, in
charset-agnostic mode.  Even very large documents should generate
no limit here, otherwise there is no problem to create the two
pipelines concurrently ...

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [Groff] pdfmom grep (was parallel text processing)

[Steffen Nurpmeso]

i wrote:
 |Peter Schaffter  wrote:
 ||On Fri, Sep 08, 2017, Ralph Corderoy wrote:
 ||>> You'll notice that the top of the pdf file has a line of text spit out
 ||>> by grep(1) that obviously shouldn't be there.
 ...
 ||Problem solved.
 ...
 ||The solution is to pass the -a flag to grep.

This flag is not standardized, though i failed to find a system
that does not have it with a shallow glance (*BSD, Linux).

  ...
 ||Question: why does grep treat the presence of the diacritic as cause
 ||for saying "Binary file (standard input) matches"?
 |
 |Likely because that is true in your locale?  It is very likely
 |that this cannot work (i see -k could possibly happen), suppose
 |you are in a LATIN1 locale and process UTF-8, and it is even worse
 |when your own locale is more picky than LATIN1.  Strives me this
 |should be split up so that perl itself performs the grep, in
 |charset-agnostic mode.  Even very large documents should generate
 |no limit here, otherwise there is no problem to create the two
 |pipelines concurrently ...

Yes, but a very simple implementation is appended that simply
converts the thing into a three-step approach.  This requires one
temporary file.  I am also a bit rusty regarding perl, yet
mom-pdf.mom and camus.mom both work out fine.  (The thing is that
groff is supposed to work on Windows, and as far as i know they
cannot really fork(2), thus i refrained from spending time on
doing something that avoids the temporary file!??  Maybe good
enough for a draft on late Friday evening.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [Groff] pdfmom grep (was parallel text processing)

[Steffen Nurpmeso]

cool, and maybe Freudian.
Attached.

(Ah, and i have tested it with my old groff installation, then
copied it onto a current v1.22.3.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
diff --git a/src/devices/gropdf/pdfmom.pl b/src/devices/gropdf/pdfmom.pl
index a4f250c6..af48d6d5 100644
--- a/src/devices/gropdf/pdfmom.pl
+++ b/src/devices/gropdf/pdfmom.pl
@@ -123,7 +123,36 @@ if ($readstdin)
 
 if ($dev eq 'pdf')
 {
-system("groff -Tpdf -dLABEL.REFS=1 -mom -z $preconv $cmdstring 2>&1 | grep '^\. *ds' | groff -Tpdf -dPDF.EXPORT=1 -dLABEL.REFS=1 -mom -z - $preconv $cmdstring 2>&1 | grep '^\. *ds' | groff -Tpdf -mom $preconv - $cmdstring");
+my (@strings);
+my ($tmpfh, $tmpfn) = tempfile('pdfmom-X', UNLINK => 1);
+die "pdf: binmode tmpfile: $^E" unless binmode $tmpfh;
+
+die "pdf: open 1: $^E" unless open ROFF,
+'groff -Tpdf -dLABEL.REFS=1 -mom -z ' .$preconv. ' ' .$cmdstring.
+' 2>&1 |';
+die "pdf: binmode 1: $^E" unless binmode ROFF;
+while(){
+print $tmpfh $_ if /^\.ds/
+}
+die "pdf: close 1: $^E" unless close ROFF;
+$tmpfh->flush;
+
+die "pdf: open 2: $^E" unless open ROFF,
+'groff -Tpdf -dPDF.EXPORT=1 -dLABEL.REFS=1 -mom -z ' .$tmpfn1. ' ' .
+$preconv. ' ' .$cmdstring. ' 2>&1 |';
+die "pdf: binmode 2: $^E" unless binmode ROFF;
+while(){
+push @strings, $_ if /^\.ds/
+}
+die "pdf: close 2: $^E" unless close ROFF;
+
+die "pdf: open 3: $^E" unless open ROFF,
+'| groff -Tpdf -mom - ' .$preconv. ' ' .$cmdstring;
+for my $s (@strings){
+  print ROFF $s
+}
+die "pdf: close 3: $^E" unless close ROFF
+
 }
 elsif ($dev eq 'ps')
 {

[groff] Fwd: Re: [Groff] Knuth-Plass Algorithm

[Steffen Nurpmeso]

Sorry, hit the wrong button!

-- >8 -- >8 --  Forwarded message  -- 8< -- 8< --
Date: Thu, 09 Nov 2017 16:33:52 +0100
From: Steffen Nurpmeso 
To: Bertrand Garrigues 
Cc: Ingo Schwarze 
Subject: Re: [Groff] Knuth-Plass Algorithm

Bertrand Garrigues  wrote:
  ..
 |Hmm... Bug #40716 "UPGRADE: format a paragraph as a whole rather than
 |line by line" is assigned to me, it's time to publish some of my work...
 |
 |I've started to work on Knuth-Plass algorithm last year, I've written

That is pretty cool and good news for GNU roff!
Congratulations!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[groff] Commit [09040dbf] is wrong

[Steffen Nurpmeso]

Hi,

i am in the process of syncing my GPL2 roff tree once again,
hopefully to be able to start getting that thing going.
Let me first wonder why my valid remark regarding that Unicode
error (i have forgotten what it was, actually) is still not fixed
even if now with that GNU patch-in library thing there is
something regular and usable available.  But anyway i have
forgotten about this.

I am here for something else, the commit mentioned changed

  -if ((*t)->buffer[j] == INLINE_LEADER_CHAR) {
  +if (j < char_block::SIZE && (*t)->buffer[j] == INLINE_LEADER_CHAR) {

where it should have been

  +if (j < (*t)->used && (*t)->buffer[j] == INLINE_LEADER_CHAR) {

instead.  But better would be redoing the entire thing, if that
comment is allowed, including indentation fixes.  Note especially
that, if all the buffer of *t consumed, and *t stepped to next
buffer, an array index of that _next_ *t with _this_ j is
performed.  That cannot be correct?  Note i changed blindly, my
roff clone does not yet compile, and also i have no documents to
feed through this thing for testing yet, anyway.
I come up with (uncompiled and untested):

  void
  char_buffer::write_upto_newline(char_block **t, int *i, int is_html){
enum {a_NONE, a_NL, a_LEADER} ev;
char *b;
int j, u;

if(*t == NULL)
  goto jleave;

j = *i;
u = (*t)->used;
b = (*t)->buffer;
ev = a_NONE;

for(; j < u; ++j){
  if(b[j] == '\n'){
++j;
ev = a_NL;
break;
  }else if(b[j] == HTML_INLINE_LEADER_CHAR){
ev = a_LEADER;
break;
  }
}

writeNbytes(&b[*i], j - *i);
*i = j;

if(ev == a_LEADER){
  if(can_see(t, &j, HTML_IMAGE_INLINE_BEGIN))
write_start_image(INLINE, is_html);
  else if(can_see(t, &j, HTML_IMAGE_INLINE_END))
write_end_image(is_html);
  else if(j < u){
++j;
writeNbytes(&b[*i], 1);
  }
}

// Rotate block if all the buffer was consumed
if(j == u){
  *i = 0;
  if((*t = (*t)->next) != NULL)
write_upto_newline(t, i, is_html);
}
  jleave:;
  }

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] Commit [09040dbf] is wrong

[Steffen Nurpmeso]

i wrote:
  ...
 |I am here for something else, the commit mentioned changed
  ...
 |I come up with (uncompiled and untested):
 ...
 |
 |  void
 |  char_buffer::write_upto_newline(char_block **t, int *i, int is_html){
 |enum {a_NONE, a_NL, a_LEADER} ev;
 |char *b;
 |int j, u;
 |
 |if(*t == NULL)
 |  goto jleave;
 |
 |j = *i;
 |u = (*t)->used;
 |b = (*t)->buffer;
 |ev = a_NONE;
 |
 |for(; j < u; ++j){
 |  if(b[j] == '\n'){

Blush.  This should have been

  ev = (++j < u && b[j] == HTML_INLINE_LEADER_CHAR) ? a_LEADER : a_NL;

instead.  Now fixed.  (Still uncompiled and untested, of course.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] Commit [09040dbf] is wrong

[Steffen Nurpmeso]

Werner LEMBERG  wrote:
 |> Blush.  This should have been
 |> 
 |>   ev = (++j < u && b[j] == HTML_INLINE_LEADER_CHAR) ? a_LEADER : a_NL;
 |> 
 |> instead.  Now fixed.  (Still uncompiled and untested, of course.)
 |
 |Please file a bug report in the issue tracker so that it won't be
 |forgotten.

Oh please, Werner, i cannot open a Savannah bug report for each
little thing i find, maybe if it could be driven via mail -- can
i post to bugs@ instead?  I mean, Savannah listed ~16 persons for
groff, of which several can code C/++, and make a lot of noise, if
there is a fatal bug reported they may place that thing in their
TODO list or let it linger.  It is also in the repo of my clone.
Can i post to bugs@ instead?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] 04/04: tmac: Move macro diagnostics away from `quotes'.

[Steffen Nurpmeso]

 |commit 1294c8d2272e1c43b1b683e287deb1749865e642
 |Author: G. Branden Robinson 
 |Date:   Sat Nov 18 17:55:26 2017 -0500
 |
 |tmac: Move macro diagnostics away from `quotes'.
 |
 |Signed-off-by: G. Branden Robinson 
 |---
 ..
 | tmac/doc-common-u   | 86 ++\
 | ---
 | tmac/doc-syms-u | 12 
 | tmac/doc.tmac-u | 26 

Now i really think you are going too far.  These BSD mdoc(7)
macros are not your private property or only in sofar as BSD does
no longer use groff at all, at least for manual purposes.  But
that surely does not get better when someone who has no conscious
contact with usage of those macros (given that Linux prefers
man(7)) selfishly decides over a style issue and then starts
trampling over those macros.  That said, feel free to do whatever
you want.  But if you move away from americanish `' quotes, why
the heck is it '' that you go for, instead of "".
Thank you, and good night.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] 04/04: tmac: Move macro diagnostics away from `quotes'.

[Steffen Nurpmeso]

Ingo Schwarze  wrote:
 |Steffen Nurpmeso wrote on Sun, Nov 19, 2017 at 02:57:36AM +0100:
 |
 |> selfishly decides over a style issue
 |
 |I think there was a discussion on this list, and what Branden does
 |seems in line with the outcome to me.

Really?  I must have missed that then.

 |> trampling over those macros
 |
 |Please refrain from insulting Branden, who is doing good and no doubt
 |tedious work right now.

Yeah yeah.  Whatever you say.  sed can do a lot of good.

 |Your implicit allegation that these quotes represented BSD heritage
 |does not match the facts.  Here is what Cynthia's final version
 |contained in 4.4BSD-Lite2:
 |
 |  .tm Usage: Ap "cannot be first request on a line (no .Ap)" (#\\n(.c)

I would use double quotes.  No, correct is that i will use double
quotes when i get there.  TZ also went from `' to "".

 |That said, these are diagnostic messages for human consumption and
 |it seems very unlikely to me that anybody has scripts to parse them,
 |so i can't see any downside in unifying the style within groff.
 |Diagnostics in other tools, for example in mandoc, are different
 |anyway, and no standardization of such messages exists or is needed.

And Heirloom-doctools are dead anyway.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] 01/03: contrib/hdtbl/examples/*.roff: Seed RNG.

[Steffen Nurpmeso]

Ok, i finally say something.

g.branden.robin...@gmail.com (G. Branden Robinson) wrote:
 |commit da6ac443f21ef09d90b40d2e8215955c916f396a
 |Author: G. Branden Robinson 
 |Date:   Sun Nov 19 22:19:52 2017 -0500
 |
 |contrib/hdtbl/examples/*.roff: Seed RNG.
 |
 |Support reproducible builds by seeding hdtbl's random number generator
 |(in contrib/hdtbl/examples/common.roff).
 |
 |When A/Bing roff documents after a build to see what I broke with my
 |changes, I always have to ignore the numerous color changes caused by
 |contrib/hdtbl/examples/common.roff seeding its random number generator
 |with the current date/time and process ID.
 |
 |Zeroes turned out to be bad seeds; the tables didn't have much in the
 |way of color gradients.
 |
 |Fix issue https://savannah.gnu.org/bugs/?52462.
 |
 |Signed-off-by: G. Branden Robinson 

Yeah and i really will not look deeply into these commits no more.
As a self-nominated Debian project leader i find it disturbing
that you wanna honour reproducible-builds.org but then (1) do not
look out for $SOURCE_DATE_EPOCH that is (rather read:
unfortunately!) _the_ precondition to signal reproducibility!
(2) change an aspect of a macro package that looks quite
deliberate to me.  If i where you, i would remove those changes
and instead look for SOURCE_DATE_EPOCH in the random generator
itself.  (3) That is likely what i will do shall i ever reach
that point.

Regardless.  Really.  I am writing this because your last commit
introduced a bug in troff source code, where an else clause now
logically belongs to a different if than it should, if i recall
correctly.  The change itself is something good i would say, i had
it TODO-commented myself, too.
Sorry for the noise.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] 01/03: contrib/hdtbl/examples/*.roff: Seed RNG.

[Steffen Nurpmeso]

Hello Branden.

"G. Branden Robinson"  wrote:
 |At 2017-12-02T01:32:01+0100, Steffen Nurpmeso wrote:
  ...
 |> g.branden.robin...@gmail.com (G. Branden Robinson) wrote:
 |>|commit da6ac443f21ef09d90b40d2e8215955c916f396a
 |>|Author: G. Branden Robinson 
 |>|Date:   Sun Nov 19 22:19:52 2017 -0500
 |>|
 |>|contrib/hdtbl/examples/*.roff: Seed RNG.
 |>|
 |>|Support reproducible builds by seeding hdtbl's random number generator
 |>|(in contrib/hdtbl/examples/common.roff).
 ...
 |> Yeah and i really will not look deeply into these commits no more.
 |
 |I welcome code reviews.

Even if they are wrong like my last one?  Sorry.
No, it is about my nerves, better it is.

  ...
 |> (2) change an aspect of a macro package that looks quite
 |> deliberate to me.
 |
 |Well, yeah, it's deliberate.  The macro package author implemented his
 ...
 |Can you explain to me how I've broken an interface that end users are
 |relying upon?

No you have not done that.

 |As an aside, I find the implementation of a PRNG in the roff language to
 |be superfluous but delightful.  I wouldn't want to get rid of it.  Like
 |Greg Ubben's arbitrary-precision RPN calculator in sed, the world is a
 |better place for its existence even if it's not, and perhaps should not
 |be, a standard tool.

Does not work for me.  I am not a mathematician.  And very often
distracted and otherwise inattentive..

  ...
 |You mean this (my last==most recent) commit?

Yep, that was the one i got wrong.
A nice weekend i wish.  (As a side note i find it surprising that
groff is still usable at all given that change in [5ee77445] since
it changes C++ style allocation to C style allocation but only
adjusts a rudimentary set of users.  Very robust it is!)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] [UTROFF] Troff and xml

[Steffen Nurpmeso]

Pierre-Jean  wrote:
 |For some reason, the html file was not joined, here it is...

No it is not.  Maybe your mailer is the cause..  Or the used
version!
But interesting all that.  That would have been my idea for going
HTML too, doing that in all of the macros which shall be usable,
but i never really hatched on this in practice yet.

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] Problems redefining macro $c for -me macros

[Steffen Nurpmeso]

Hey.

Stephanie Björk  wrote:
 |For quite a bit, I've been trying to redefine the .$c macro for the -me
 |macros.  According to the reference manual, the macro package allows the
 |user to redefine how chapters look when they get printed, by redefining
 |that macro.
 |
 |Here's my redefinition.  In the original file, I added no comments, but I
 |will add them now just to make things clearer as to what I'm doing.
 |
 |.de $c
 |.bp
 |.nr ch +1 \" Increment chapter number count
 |.nr eq 0 1 \" Set equation number to 0, with auto-inc of 1.
 |.ft \\n[sf] \" Same font as section font
 |.ps \\n[sp] \" Same size as section font
 |.ce 1000
 |.if \\n(_M=1 Chapter \\n(ch \" If it's a chaptered content, print
 |chapter number
 |
 |\\$1 \" Print the chapter name
 |.ce 0
 |.sp 2v
 |..
 |
 |The problem is that my macro redefinition gets ignored and an error is
 |thrown:
 |
 |main.me:23: name expected (got `\&')

Please, first: i must admit i am standing in no man's land and
found it out only by trial and error.

It seems that the eqn preprocessor does not like that you use .EQ
.. .EN before that ".de $c".  If you move that .EQ .. .EN
downwards then anything is fine.  Except for placement of page
numbers, the fonts i do not know about, and the ".fam" requests
without argument provoke a division by zero error.  Despite all
that it seems to solve the problem.

Oh, surprisingly (eqn is for mathematicians!): using the eqn
"delim" request with dollars seems to start an inline equation for
".de $c"!  You can use the -N eqn command line option to prevent
crossing newline boundaries, but i am, you recognize this?, acting
beyond my current capabilities.  It seems to me eqn(1) should not
interpret data on command lines as inline equations?  No, this
cannot be a solution either, think of equations as part of
chapter names...  No, as inelegant as it is, it seems you must
ensure that the dollar $ delimiter becomes activated after you
have adjusted the me macros.

Staying alive on a saturday night maybe,
Ciao!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] A macro package for lists in TROFF

[Steffen Nurpmeso]

Stephanie Björk  wrote:
 |So, after having been on the mailing list for a bit, I've found that we are
 |all sharing quite cool things here.  Just a day ago, I wrote something

I do not.  My macros are a bad hack.

 |quite nice in Troff -- a macro package that provides for something that
 |most macro packages I have so far known lack.  I figured also that this is
 |the best place to share any ``movements'' in /[GTN]roff/ as the community
 |is small.
 |
 |So, I made an okay-functioning macro package to typeset lists (currently,
 |only bulleted lists are possible) that can be nested.  Each nesting can
 |have a custom indentation.  When a nesting is complete, the macro remembers
 |how much that custom indentation is and exdents it by the exact same
 |amount.  You can have as many nested orders as desired.

See.  I have a fixed limit of five levels.  (To have named strings
which format the numbers / represent the bullets.)

 |Each bullet can also have some custom bullet characters and all the other
 |fancy things only obvious in the source code.
 |
 |The project is here: https://github.com/katt64/troff-lists (bul.tmac is the
 |beating heart of it all)
 |It currently cannot do numbered lists because those are complicated and I
 |will do them later when I have time.

I was indeed impressed by the stack macro -- it is
pretty cool as it de-facto creates a type, so to say!
This is an idea that not yet crossed my mind.  I would surely have
implemented it right away to also support strings, so that it
becomes real work later if anything needs to be adjusted, though.

 |Yes, I admit that it does exploit Groff and Troff to the point I could be
 |arrested for software abuse.  But, yes, it's quite a concept.

That is ... gigantic.  I wonder where my Pixies records are,
..this monkeys gone to heaven.

 |Rgds,

Yes, there has got to be time for that.

 |Stephanie

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] html output of Op vs Oo Oc

[Steffen Nurpmeso]

Jan Stary  wrote:
 |This is groff 1.22.3 as installed by the OpenBSD port.
 |
 |Below please find a short manpage written in mdoc(7),
 |which I am trying to process into html with
 |
 | groff -Thtml -mdoc rtpdump.1 > rtpdump.html
 |
 |One point where it seems to fail is
 |
 | .Oo Ar address Oc Ns / Ns Ar port
 |
 |- the html output contains a paragraph break
 |
 |  ... [
 |
 |after the opening [ of the .Oo, which I believe is an error.
 |The same happens later with another .Oo ... Oc
 |
 |Is this known? A plain .Op renders fine,
 |but Oo ... Oc seems to have this bug.

Not always.  Who knows?  But not yet known to me until now, thanks
for the test case!  Maybe i can reply to this in a few years from
now again, that would be nice.

Have a nice weekend, all.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] mdoc(7) .Lk: complete rewrite of the macro

[Steffen Nurpmeso]

Ingo Schwarze  wrote:
 |i just posted a patch containing a complete rewrite of the mdoc(7) .Lk
 |macro to:  https://savannah.gnu.org/bugs/index.php?52849

I have not seen the patch yet, but .Lk is terrible and
unpredictable by the document author, as you say.
Making it not go in stand-out mode would be a great improvement in
my eyes, one can use .Dl Lk or so if that is desired.

 |The point is to make it callable, get rid of the hard-to-predict
 |and counter-intuitive switching between in-line and display rendering,

Yes.

 |and to make behaviour and implementation better harmonize with other
 |mdoc macros.  For more details and a demo input file showing the
 |effects, see the bug tracker.
 |
 |Because of its current fragility, the macro is often used in non-
 |portable ways, resulting in ugly and inconsistent output.  The goal
 |is to make it easier to use and more robust.

Absolutely.

 |I'm looking for consensus here before moving the mandoc(1)
 |implementation in the direction that we will agree on.
 |So feedback is appreciated on both the changes in functionality
 |and on the new implementation.
 |
 |For convenience, i'm also appending the patch to this posting.

I would be happy to include that patch of which i assume it is
working for my thing.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] Changing A Defined String

[Steffen Nurpmeso]

Robert Thorsby  wrote:
 |Temperatures here in AU have been in the range 35-45 for the past week  
 |and are forecast to be the same for the next week.  So with no  
 |inclination towards serious work I have turned my attention to  
 |rewriting my letterhead shell script, as one does.

And you have all those poisoning animals down there, too!
Luckily the great reef is already almost dead...

 |My letters carry the date in full -- Thursday, 25 January 2018 -- which  
 |is placed into the preamble of the groff file via my shell script:
 |
 |date --date="..." "+.ds DATE*FULL %A, %-d %B %Y" >> draftletter.gr
 |
 |But occasionally I also want to use the date in a ``shorter'' version  
 |that depends on the ``full'' version.  I appreciate that I can simply  
 |create two definitions, but once defined they would be independent of  
 |each other.
 ...
 |Can anyone assist with proper groff request(s) to replace the bashism  
 |so that any amendment to DATE*FULL is carried through automagically to  
 |DATE*SHORT?  I don't use any macro package.

I would use the fantastic possibility the wonderful Werner Lemberg
added to groff, strings with arguments:

  .ds template Thursday 25 January 2018
  .ds full \\$*
  .ds short \\$1 \\$3
  .ds DATE*FULL \\*[full \*[template]]
  .ds DATE*SHORT \*[short \*[template]]
  full \*[DATE*FULL] short \*[DATE*SHORT]

Hope this helps,
Ciao from Germany under west stream (mild)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] Changing A Defined String

[Steffen Nurpmeso]

Tadziu Hoffmann  wrote:
 |Just a short addendum:
 |
 |Since you know that you'll only be stripping off one of the
 |known weekday names, there's also a simpler solution:
  ...
 |However, there is still a caveat with these solutions: although
 |\*[DATE*SHORT] may look like a (single-line) string expansion,
 |it is actually a (multi-line) macro call in disguise.  This
 |means that the following will not work:
 |
 |  .ds LH Formatted on \*[DATE*SHORT]
 |
 |(for example, to set the page header in some hypothetical
 |document).

Why this?  If i use \\*[DATE*SHORT] anything is fine, so it is
because the macro is evaluated while the string is defined.
Is this restriction documented somewhere?  If not it is a bug to
keep on the TODO list, thank you!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] Changing A Defined String

[Steffen Nurpmeso]

Tadziu Hoffmann  wrote:
 |> Why this?  If i use \\*[DATE*SHORT] anything is fine, so it is
 |> because the macro is evaluated while the string is defined.
 |
 |Yes.
 |
 |If you use the "string" like this:
 |
 |  Some text before \*[DATE*SHORT], and some text after
 |
 |the expansion will yield
 |
 |  Some text before \c
 |  .XX \\*[DATE*FULL]
 |  , and some text after
 |
 |and this in turn will eventually expand to
 |
 |  Some text before \c
 |  December 31, 2038
 |  , and some text after
 |
 |giving as the total effect
 |
 |  Some text before \c
 |  December 31, 2038, and some text after
 |
 |which is completely okay in running text.
 |
 |When using it as
 |
 |  .ds LH Formatted on \*[DATE*SHORT]
 |
 |it will yield
 |
 |  .ds LH Formatted on \c
 |  December 31, 2038
 |
 |which simply stores "\c" in the string LH, and writes the
 |date into the running text instead.

Ok.  Thanks, yes i am very rusty, it has been a long time since
i looked into the macro side..

 |> Is this restriction documented somewhere?  If not
 |> it is a bug to keep on the TODO list, thank you!
 |
 |It's not a bug, it's a reminder not to use tricks that confuse
 |strings and macros, even if they are treated internally very
 |similarly during expansion.

It seems to me it would be nice to have some kind of "auto-div"
that is active as long as a .ds creation is in progress, so that
this is kept together.?  What do you mean?

A nice rest weekend from my side,
Ciao

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] modernization, maintanership, separate packages

[Steffen Nurpmeso]

Doug McIlroy  wrote:
 |All these threads are tangled in my mind, so ...
 |
 |-a: I use this quite regularly for quick peeks at line and page
 |breaks without the trouble of writing a file and looking at it
 |in another window. It is certainly the option I type most--the
 |rest are buried in shell scripts.
 |
 |separate maintenance. macro languages suffer from being almost
 |write-only. It's only a slight exaggeration to say that each
 |package requires its own special expert. I would favor separate
 |maintenance, with the maintainer filing a regression test.
 |The groff maintainer need only run all the regressions and
 |check with the package maintainer on failure.

Oh yes, i wish there would be much better regression tests, such
which span the entire set of pre- and postprocessors.

I am working on my port since December (with discontinuities), and
it seems it will end up as a really large rewrite of the codebase,
for example with a different memory handling of C strings (no
longer C++ new[], but normal malloc).  I admit i live in a bit
of a fear that it will, once this big thing is out, quite some
time to find the usual bugs that happen to happen.  It would be
much, much easier if there would be a good test suite.

(I was thinking about that back in December, and i will ask for
large and complicated documents, which use different macro sets
and which require as many as possible preprocessors, once i have
something working.  I hope i will get some responses, then.
Those could then be used as templates for a sharable test suite,
with text turned to evaporated random garbage (to be repeated with
a macro etc. as necessary).)

A good compartmentalized test suite, like Ingo Schwarze is
developing for mdoc / man(?) of his mandoc, is something that is
on my list.  For the MUA i maintain it took four years to have
that started, however ...

 |It's helpful to ship a small bundle of macro packages with
 |groff, just as a small bundle of fonts is shipped. But specialties
 |(e.g. chem) would best be available for download from the groff
 |website rather thancluttering the distribution. 
 |
 |I would like to see font files as downloadable packages, too.

I would like to see TTF support, then your desire would have been
satisfied by Linux distributions and BSD already, too.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [groff] groff as the basis for comprehensive documentation?

[Steffen Nurpmeso]

Ralph Corderoy  wrote:
 |Ingo wrote:
 |> The name of that standard section in man(7) and mdoc(7) is "EXIT
 |> STATUS", not "Exit Status" nor "Exit status" nor "exit status".
 |
 |The shouting section heading makes it easier to find that heading rather
 |than the same word occurring elsewhere, e.g. `ENVIRONMENT'.

Alternatively you have active links and an index and can jump to
whatever section or anchor there is.  For print-outs normal case
would be much nicer.

 |And if the .SH's parameter isn't shouting then perhaps there's a reason
 |for it and it should be preserved, even if it just shows up the bug to
 |fix.

Much nicer.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)