Re: [Heirloom] No courier font (.CW) in -ms

[G. Branden Robinson]

Hi Philip!

At 2020-10-14T02:43:36+, Philip Bushee wrote:
> I'm using Heirloom doctools on OpenBSD.  I'm using the version on the
> ports system[1].  I'm trying to use the .CW macro to mark a text in
> typwriter font (courier).  But it does not work.
> Using \f(CW works, however.
> 
> Does .CW work at all on -ms with Heirloom doctools?
> 
> [1]: https://openports.se/textproc/heirloom-doctools

I don't see any evidence in recent Heirloom Doctools Git that it
does[1].

It's my understanding that the .CW ms macro is a Berkeley extension;
evidence for this can be found in the fact that it's not documented in
the original AT&T Version 7 ms manual[2], but does appear in the
Berkeley expanded verison of that manual[3].  At some point it got added
to Documenter's Workbench[4].

groff ms supports it, but in groff I think it would be better to use the
.fam request.  That way it is the font _family_ that switches (from
Times to Courier), and you can still use the .B, .I, and .R macros in
the traditional way.  Example attached.

Also, in groff, the string \*[FAM] can be set when the document is set
up to determine the default font family.  So you could say:
.ds FAM H
to set the family to Helvetica before calling any macros which
initialize the package (which is most of them--paragraph macros, cover
page macros, and so on).

Regards,
Branden

[1] 
https://github.com/n-t-roff/heirloom-doctools/blob/master/troff/troff.d/tmac.d/s.in
[2] https://www.troff.org/using-ms.pdf
[3] https://www.hactrn.net/ietf/rfcgen/textms.html
[4] https://github.com/n-t-roff/DWB3.3/blob/master/macros/ms/tmac.s.sr


switch-fam.ms
Description: Troff MS-macros document


signature.asc
Description: PGP signature

Re: Learning troff - where to start?

[Ingo Schwarze]

Hi,

Damian McGuckin wrote on Wed, Oct 14, 2020 at 11:41:59AM +1100:
> On Wed, 14 Oct 2020, Greg 'groggy' Lehey wrote:

>> But that brings us back to where we came in: where is there
>> well-structured documentation for the current groff?

> Agreed.  It is not there.

I wonder where this myth is coming from.

It is here, generated from the texinfo sources:

  https://www.gnu.org/software/groff/manual/html_node/

For groff itself, this is excellent documentation with respect to
completeness, precision, structure, and indexing.

Some specific macro packages are documented in additional documents,
for example manual pages and HTML files, which are also of good
quality.

Yes, there are details that can be polished, and Branden is working
on that.  If you feel bored, you can also start quibbles regarding
the choice of markup language.  But the big picture is that groff
documentation is in better shape than the documentation of many
other software packages.

Given the size and complexity of groff, new users might wish to
read a simpler document first, for example CSTR#54, or another
classical text, several of which were mentioned, just like a newbie
to the C programming language might still use Kernighan/Richie to
get an initial understanding what the basic ideas of the language
are.

But none of that means groff isn't properly documented, and it
doesn't feel helpful to me conveying such an impression when new
users ask questions.

Yours,
  Ingo

Re: Learning troff - where to start?

[Ingo Schwarze]

Hi Federico,

Federico Lucifredi via wrote on Tue, Oct 13, 2020 at 08:04:10PM -0400:

> For man page writing, I collected the available resources in this
> blog post a while ago - happy to hear about new resources.

If you are curious about new resources, you could mention the
concept of semantic markup and the mdoc(7) language, which was
new twenty years before you wrote your blog post.

Sure, some people might argue that semantic markup is useless or
evil and physical markup is simply better, though i rarely hear
that opinion.  Sure, some people might argue that some semantic
markup languages are too large and complicated for practical use,
and i definitely make that argument regarding DocBook with its 500
different elements and tens of thousands of nesting rules.  Some
people even make that argument for mdoc(7) with its about seventy
macros.

But advertising an article to "collect *the* available resources"
(emphasis is mine) in 2020 if that artcile does not mention the
possibility of writing manual pages with semantic markup feels
surprising to me.  In particular since the first sentence of the
post gives me the impression that this is not intended as Linux-only
but as community-independent.  For all BSD communities, the information
presented in the article is outdated by about three decades, and
for Illumos, it no longer applies, either.

Finally, there is an obvious, rather serious error.  I do not think
misattribution should be taken lightly:

  the man macro package, originally written by James Clark

The correct statement is:

  The man language first appeared as a macro package for the roff
  typesetting system in Version 7 AT&T UNIX.  It was later rewritten
  by James Clark as a macro package for groff.

I'm not sure which member(s) of the Bell Labs originally designed
and implemented the man(7) macros, but it clearly wasn't James Clark.

Yours,
  Ingo

> https://f2.svbtle.com/writing-man-pages

Re: Learning troff - where to start?

[Johann Höchtl]

Dear Peter,

while I first thought a follow-up question would warrant a separate thread,
now as you mention mom, I feel comfortable not to wander astray.

Of course I discovered mom and wow it looks feature-rich and very polished.
I wonder how big of an effort it would be to make it "portable".

Groff is certainly feature-rich, stable and polished with great
documentation. But I also value l8n, being able to input utf8-characters
directly into the source or easily switch fonts. Not to mention PAO
(paragraph-at-once) from Knuth-Plass. In that respect both Heirloom and
Neatroff are compelling alternatives and it would be great for mom if she
would be available there too.

Best, Johann

Am Mi., 14. Okt. 2020 um 03:10 Uhr schrieb Peter Schaffter <
pe...@schaffter.ca>:

> On Wed, Oct 14, 2020, Damian McGuckin wrote:
> > How many people use features of 'groff' that are not in 'troff'?
>
> The mom macros rely heavily on extensions to groff that were
> implemented during Werner's term.  Since many (most?) new groff
> users these days gravitate towards mom, I'd say quite a lot of
> people rely on those features.
>
> I learned troff entirely from ctsr54.  It is not for nothing that
> it remains the canonical starting point for exploring groff.
>
> Prentice-Hall published _Troff Typesetting for UNIX Systems_
> (Emerson, Paulsel) in 1987.  It's still available online.  It might
> be the very thing the OP is looking for.
>
> --
> Peter Schaffter
> https://www.schaffter.ca
>
>

FWD: [bug #59268] [PATCH] tmac.am: non-portable $< syntax

[Ingo Schwarze]

Hi Branden,

given that we are working towards release, i started testing on
non-Linux platforms, first on OpenBSD.  After that, i'm planning
to test on Oracle Solaris 11 and on SUN Solaris 10.

This is the first (but not the only) fatal issue i found.
I'm looking for an OK to push the fix.

No Changelog entry is needed because the bug was never released
and the patch doesn't change functionality but merely fixes the
build.

Yours,
  Ingo

- Forwarded message from Ingo Schwarze -

URL:
  

 Summary: [PATCH] tmac.am: non-portable $< syntax
 Project: GNU troff
Submitted by: schwarze
Submitted on: Wed 14 Oct 2020 11:56:23 AM UTC
Category: Macro - man
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: schwarze
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: [1.23]

___

Details:

Groff no longer builds with POSIX make(1):

$ make
make  all-am
Using $< in a non-suffix rule context is a GNUmake idiom (Makefile:12441)
*** Error 2 in /co/groff/build (Makefile:5317 'all')

This was broken in:
commit 31536c517dfe49b4e4a715a732f76b701531e90a
Author: G. Branden Robinson 
Date:   Wed Aug 12 00:02:51 2020 +1000

The attached patch fixes the error.

___

commit a5c5868e3ec7b996129b4f5e8ea63304b55cfbc2
Author: Ingo Schwarze 
Date:   Wed Oct 14 13:52:29 2020 +0200

tmac.am: do not use $< in a non-portable way

diff --git a/tmac/tmac.am b/tmac/tmac.am
index de5d1746..05eb259e 100644
--- a/tmac/tmac.am
+++ b/tmac/tmac.am
@@ -207,14 +207,14 @@ M4WORDS = 
define|divert|include|index|shift|undefine|undivert
 M4CHECK = tmac/check-groff_man-stamp
 
 $(M4CHECK): tmac/groff_man.7.man.in
-   ! grep -E '(^|[[:space:]])($(M4WORDS))($$|[[:space:]])' $<
-   > $@
+   ! grep -E '(^|[[:space:]])($(M4WORDS))($$|[[:space:]])' \
+ $(tmac_srcdir)/groff_man.7.man.in > $@
 
 tmac/groff_man.7.man: tmac/groff_man.7.man.in $(M4CHECK)
-   m4 -D_groff_man_not_style $< > $@
+   m4 -D_groff_man_not_style $(tmac_srcdir)/groff_man.7.man.in > $@
 
 tmac/groff_man_style.7.man: tmac/groff_man.7.man.in $(M4CHECK)
-   m4 -D_groff_man_style $< > $@
+   m4 -D_groff_man_style $(tmac_srcdir)/groff_man.7.man.in > $@
 
 # The installation of groff compatibility wrappers for vendor-provided
 # non-GNU macro sets is controlled by 'compatibility_wrappers' (see the

Re: Learning troff - where to start?

[Federico Lucifredi]

Hello Raf,

> 
> Also, when it comes to history of *roff from the UNIX manpages
> angle, this[0] is a good place to visit.
> 
> [0] https://manpages.bsd.lv/history.html
> 

That is awesome, it is one of the best stories of man yet (there was a good 
conference talk a few years back as well, I will look for the link).

For completeness, I will point out history of man on Linux is missing there, 
with Andries Brouwer and myself, as well as Colin Watson and Fabrizio Polacco 
missing in the cast of maintainers.

Thanks for sharing!

Best -F

Re: Learning troff - where to start?

[Federico Lucifredi]

Hello Ingo,

> On Oct 14, 2020, at 7:10 AM, Ingo Schwarze  wrote:
> 
> Finally, there is an obvious, rather serious error.  I do not think
> misattribution should be taken lightly:
> 
>  the man macro package, originally written by James Clark
> 
> The correct statement is:
> 
>  The man language first appeared as a macro package for the roff
>  typesetting system in Version 7 AT&T UNIX.  It was later rewritten
>  by James Clark as a macro package for groff.
> 
> I'm not sure which member(s) of the Bell Labs originally designed
> and implemented the man(7) macros, but it clearly wasn't James Clark.

Interesting. As far as I can tell, the origin of that statement is in man 7 
groff_man:

http://manpages.ubuntu.com/manpages/trusty/man7/groff_man.7.html

I have no insight myself on the original authorship, just quoting from the 
manual. 

Best -F

Re: Learning troff - where to start?

[Ingo Schwarze]

Hi Federico,

Federico Lucifredi wrote on Wed, Oct 14, 2020 at 08:21:49AM -0400:
> On Oct 14, 2020, at 7:10 AM, Ingo Schwarze  wrote:

>> Finally, there is an obvious, rather serious error.  I do not think
>> misattribution should be taken lightly:
>> 
>>  the man macro package, originally written by James Clark
>> 
>> The correct statement is:
>> 
>>  The man language first appeared as a macro package for the roff
>>  typesetting system in Version 7 AT&T UNIX.  It was later rewritten
>>  by James Clark as a macro package for groff.
>> 
>> I'm not sure which member(s) of the Bell Labs originally designed
>> and implemented the man(7) macros, but it clearly wasn't James Clark.

> Interesting. As far as I can tell, the origin of that statement
> is in man 7 groff_man:
> http://manpages.ubuntu.com/manpages/trusty/man7/groff_man.7.html

That document says:

  DESCRIPTION
  The man macros used to generate man pages with groff
  were written by James Clark.

That is correct.

You are saying:

  For man pages, what you need is knowledge of the man macro package,
  originally written by James Clark [...]

That is a blatant misrepresentation.

It is akin to talking about "the C programming language, invented
by Richard M. Stallman, ..."

Besides, your statement is also incorrect in so far as for many
projects, what you need is mdoc instead (even though it is true
that the Linux man pages project and several other software projects
still use the old man(7) macros).

Besides, the Ubuntu page you quoted is outdated, with an incomplete
AUTHORS section.  The latest stable groff release (from two years ago)
says:

  AUTHORS
  The GNU version of the man macro package was written by James
  Clark and contributors.  The extension macros were written by
  Werner Lemberg  and Eric S. Raymond .

This text was added in 2017.

Admittedly, it would be better to also credit the original authors,
not only the authors of the GNU reimplementation, as it is done
here, for example:

  https://mandoc.bsd.lv/man/man.7.html

But what the groff_man(7) manual page says is not wrong.

> I have no insight myself on the original authorship,
> just quoting from the manual. 

You are misquoting.

Yours,
  Ingo

Re: Learning troff - where to start?

[Deri]

On Wednesday, 14 October 2020 03:20:17 BST Damian McGuckin wrote:
> The UTP Revival Project recreated the source code because Tim and 
Sale
> were unable to locate a copy of the original source. It is located at:
> 
> http://home.windstream.net/kollar/utp/


There is a version with clickable contents and index here:-

https://github.com/DeriJames/UTP-1.1/raw/master/utp_book.pdf

Re: Learning troff - where to start?

[Werner LEMBERG]

> Admittedly, it would be better to also credit the original authors,
> not only the authors of the GNU reimplementation, as it is done
> here, for example:
>
>   https://mandoc.bsd.lv/man/man.7.html

Mhmm, my name is missing...

Anyway, there are some serious typos on that page, for example

  MT   Begin a mailto block.  This is a non-standard GNU extension.
   It has the following syntax:

 .<
 MT address
 link description to be shown
 .<
 ME


   Werner

FWD: [bug #59270] [PATCH] node.h: avoid C++11 feature (non-const init in class)

[Ingo Schwarze]

Hi,

this is the second portability issue that killed the build for me.
Again, i'm looking for an OK to push the fix.

Since i have little experience with C++, please check that the fix
is correct and matches your intent.

I don't think a Changelog entry is needed here, either.  This mini-issue
never made it into a release and no user-visible change is intended.

Yours,
  Ingo


- Forwarded message from Ingo Schwarze -

URL:
  

 Summary: [PATCH] node.h: avoid C++11 feature (non-const init
in class)
 Project: GNU troff
Submitted by: schwarze
Submitted on: Wed 14 Oct 2020 01:34:45 PM UTC
Category: Core
Severity: 3 - Normal
  Item Group: Build/Installation
  Status: None
 Privacy: Public
 Assigned to: schwarze
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

Compilation fails with GCC 4.2.1, which is the latest GNU compiler available
under GPLv2:

In file included from ../src/roff/troff/div.cpp:29:
../src/roff/troff/node.h:629: error: ISO C++ forbids initialization of member
'is_dying'
../src/roff/troff/node.h:629: error: making 'is_dying' static
../src/roff/troff/node.h:629: error: ISO C++ forbids in-class initialization
of non-const static member 'is_dying'
*** Error 1 in . (Makefile:6860 'src/roff/troff/div.o': @echo " CXX "
src/roff/troff/div.o;depbase=`echo src/roff/troff/div.o | sed 's|...)
*** Error 2 in /co/groff/build (Makefile:5317 'all')

While requiring C++11 is likely to make sense for many newer projects,
i don't think there is any benefit in groff requiring it, at least
not as long as it is trivial to avoid.

Compatibility with C++03 was broken in this commit:
commit c788cf8c6bbe939fa11f7ec032e525a7e33f41b6
Author: G. Branden Robinson 
Date:   Tue Sep 29 07:02:25 2020 +1000

The attached patch fixes the build with gcc 4.2.1.

___


commit 138c2a21c8cfe7108473d4da2bdf3ac5fb9736f2
Author: Ingo Schwarze 
Date:   Wed Oct 14 15:19:04 2020 +0200

node.h: do not rely on C++11 features, fixes build with gcc 4.2.1

diff --git a/src/roff/troff/node.cpp b/src/roff/troff/node.cpp
index 4a4e7e1b..72fff1ce 100644
--- a/src/roff/troff/node.cpp
+++ b/src/roff/troff/node.cpp
@@ -1613,6 +1613,7 @@ output_file *the_output = 0;
 
 output_file::output_file()
 {
+   is_dying = false;
 }
 
 output_file::~output_file()
diff --git a/src/roff/troff/node.h b/src/roff/troff/node.h
index e1c1960f..1fba4603 100644
--- a/src/roff/troff/node.h
+++ b/src/roff/troff/node.h
@@ -626,7 +626,7 @@ class output_file {
   char make_g_plus_plus_shut_up;
 public:
   output_file();
-  bool is_dying = false;
+  bool is_dying;
   virtual ~output_file();
   virtual void trailer(vunits);
   virtual void flush() = 0;

Re: Learning troff - where to start?

[Mike Bianchi]

> Isn't it sad that nothing more modern is available?

Since it is open source,
it might make sense to have a team produce a groff version?
Mike

Sent from my Adesso PCK-308UW.

On Wed, Oct 14, 2020 at 10:26:27AM +1100, Greg 'groggy' Lehey wrote:
> On Tuesday, 13 October 2020 at 22:49:03 +0200, J.-J. wrote:
> > Le mardi 13 octobre 2020 � 14:41 +0200, Johann H�chtl a �crit :
> >> * What would be a good starting point (tutorial) into troff and its
> >> core principles?
> >>
> >> * What is the canonical documentation of troff all the existing
> >> implementations seem to derive from and describe their deltas in
> >> their respective documentation?
> >
> > Here is in my opinion the best book on the subject
> > (and it's now  FREE!) :
> >
> > https://www.oreilly.com/openbook/utp/
> 
> An excellent book, and one that I have used a lot.  But nobody can
> claim that it's up-to-date (it predates groff), and there are many
> features in groff that weren't in the troff version described.  Isn't
> it sad that nothing more modern is available?
> 
> Greg
> --
> Sent from my desktop computer.
> Finger g...@lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA

-- 
 Mike Bianchi
 Foveal Systems

 973 822-2085

 mbian...@foveal.com
 http://www.AutoAuditorium.com
 http://www.FovealMounts.com

Re: Learning troff - where to start?

[Ingo Schwarze]

Hi Werner,

Werner LEMBERG wrote on Wed, Oct 14, 2020 at 03:27:24PM +0200:
> Ingo Schwarze wrote:

>> Admittedly, it would be better to also credit the original authors,
>> not only the authors of the GNU reimplementation, as it is done
>> here, for example:
>>
>>   https://mandoc.bsd.lv/man/man.7.html

> Mhmm, my name is missing...

Oops.  That error was introduced in 2012 when man-ext was first
mentioned.  Not sure how that happened and why it was never spotted;
the file an-ext.tmac was always clear about the authorship.
Sorry about it.

Fixed by the commit below, which will be in the next release.

Given that misattributions are awkward, i also regenerated
  https://mandoc.bsd.lv/man/man.7.html
right away.  The following will automatically update tomorrow:
  http://man.openbsd.org/man.7

> Anyway, there are some serious typos on that page, for example
> 
>   MT   Begin a mailto block.  This is a non-standard GNU extension.
>It has the following syntax:
> 
>  .<
>  MT address
>  link description to be shown
>  .<
>  ME

Weird.  Apparently, the CSS file was outdated or incorrectly linked,
not sure which.  The problem went away after regenerating the pages,
probably because they now link the CSS correctly.

Thanks for mentioning the CSS problem, too.

Yours,
  Ingo


Log Message:
---
add missing mention of Werner Lemberg, 
noticed by Werner himself on ;
while here, add missing .An macros

Modified Files:
--
mandoc:
man.7

Revision Data
-
Index: man.7
===
RCS file: /home/cvs/mandoc/mandoc/man.7,v
retrieving revision 1.145
retrieving revision 1.146
diff -Lman.7 -Lman.7 -u -p -r1.145 -r1.146
--- man.7
+++ man.7
@@ -612,8 +612,13 @@ The
 language first appeared as a macro package for the roff typesetting
 system in
 .At v7 .
-It was later rewritten by James Clark as a macro package for groff.
-Eric S. Raymond wrote the extended
+It was later rewritten by
+.An James Clark
+as a macro package for groff.
+.An Eric S. Raymond Aq Mt e...@thyrsus.com
+and
+.An Werner Lemberg Aq Mt w...@gnu.org
+wrote the extended
 .Nm
 macros for groff in 2007.
 The stand-alone implementation that is part of the

Re: Learning troff - where to start?

[Federico Lucifredi]

Hello Ingo,

> On Oct 14, 2020, at 9:06 AM, Ingo Schwarze  wrote:
> [..]
> 
>> Interesting. As far as I can tell, the origin of that statement
>> is in man 7 groff_man:
>> http://manpages.ubuntu.com/manpages/trusty/man7/groff_man.7.html
> 
> That document says:
> 
>  DESCRIPTION
>  The man macros used to generate man pages with groff
>  were written by James Clark.
> 
> That is correct.
> 
> You are saying:
> 
>  For man pages, what you need is knowledge of the man macro package,
>  originally written by James Clark [...]
> 
> That is a blatant misrepresentation.

No misrepresentation is intended. Be nice. 

> 
> It is akin to talking about "the C programming language, invented
> by Richard M. Stallman, …"

I removed the “originally” bit, which I believe corrects the flaw (if I am 
reading you correctly). 

Best -F

Re: Learning troff - where to start?

[James K. Lowden]

On Wed, 14 Oct 2020 11:13:39 -0400
Federico Lucifredi  wrote:

> >  For man pages, what you need is knowledge of the man macro package,
> >  originally written by James Clark [...]
> 
> I removed the ?originally? bit, which I believe corrects the flaw (if
> I am reading you correctly). 

If I may, why not just strike the whole phrase?  For your purpose, does
it matter who wrote the man macros?  That information is easily
obtained directly from the groff documentation.  

groff is written in C++, designed by Bjarne Stroustrup of Bell Labs 

--jkl

Re: Learning troff - where to start?

[Peter Schaffter]

On Wed, Oct 14, 2020, Johann Höchtl wrote:
> Groff is certainly feature-rich, stable and polished with
> great documentation.  But I also value l8n, being able to
> input utf8-characters directly into the source or easily
> switch fonts.  Not to mention PAO (paragraph-at-once) from
> Knuth-Plass.  In that respect both Heirloom and Neatroff are
> compelling alternatives and it would be great for mom if she would
> be available there too.

I haven't inspected either Heirloom or Neatroff closely so I don't
know how big a job porting would be.  I'm not likely to undertake it
myself, though if anyone wanted to, I'd be more than happy to act as
a go-to resource.

What difficulties do you have entering UTF8 directly into the
source?  I've produced groff documents in most of the Western
European and Scandinavian languages with direct UTF8 input.  Are
your troubles with languages other than those?  Also not sure what
you mean by "easily switch fonts."  Since '.ft " is as easy as
it gets, I assume you mean something else.

-- 
Peter Schaffter
https://www.schaffter.ca

Re: Learning troff - where to start?

[Morten Bo Johansen]

On 2020-10-14 Peter Schaffter wrote:

> What difficulties do you have entering UTF8 directly into the
> source?  I've produced groff documents in most of the Western
> European and Scandinavian languages

I thought we Scandinavians were also considered part of Western
Europe, including our languages?

;-)

 Morten

Re: Learning troff - where to start?

[Steffen Nurpmeso]

Morten Bo Johansen wrote in
 :
 |On 2020-10-14 Peter Schaffter wrote:
 |
 |> What difficulties do you have entering UTF8 directly into the
 |> source?  I've produced groff documents in most of the Western
 |> European and Scandinavian languages
 |
 |I thought we Scandinavians were also considered part of Western
 |Europe, including our languages?
 |
 |;-)

Finnish is definetely not as far as i know, and some people count
Finland to Scandinavia.

--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: Learning troff - where to start?

[Johann Höchtl]

On 14.10.20 18:41, Peter Schaffter wrote:


   Also not sure what
you mean by "easily switch fonts."  Since '.ft " is as easy as
it gets, I assume you mean something else.

I have been imprecise. By switching fonts I actually meant making fonts 
available to groff, which requires fontforge to generate the Type1 font 
and metrics and then afmtodit.



Best, Johann

Re: Learning troff - where to start?

[Thomas Dupond]

Peter Schaffter did make this shell script for font installation available on 
his website :

http://schaffter.ca/mom/mom-05.html#install-font

Regards, Thomas


‐‐‐ Original Message ‐‐‐
Le mercredi, octobre 14, 2020 8:16 PM, Johann Höchtl  
a écrit :

>
>
> On 14.10.20 18:41, Peter Schaffter wrote:
>
> > Also not sure what
> > you mean by "easily switch fonts." Since '.ft " is as easy as
> > it gets, I assume you mean something else.
>
> I have been imprecise. By switching fonts I actually meant making fonts
> available to groff, which requires fontforge to generate the Type1 font
> and metrics and then afmtodit.
>
> Best, Johann

Re: Learning troff - where to start?

[Damian McGuckin]

On Wed, 14 Oct 2020, Mike Bianchi wrote:


Isn't it sad that nothing more modern is available?


Since it is open source,
it might make sense to have a team produce a groff version?


I did follow up with that site. In case you missed it:

 http://home.windstream.net/kollar/utp/

And Deri provided his copy of the PDF with clickable contents and index 
page.



Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: Releasing groff 1.22.5?

[Bertrand Garrigues via]

Hi Ingo,

On Mon, Oct 12 2020 at 06:08:27 PM, Ingo Schwarze  wrote:
> A major problem with gnulib emerged just now that we should perhaps
> treat as a blocker.
[...]
> The code in
>
>   gnulib/lib/vasnprintf.c
>
> line 4879 puts a format string containing a %n directive into
> writeable memory and subsequently passes that memory as a first
> argument to printf(3).
>
> Using %n at all is insecure programming practice.
[...]

That seems to be only for old versions of glibc or a few operating
systems:

   # if ! (((__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3))\
&& !defined __UCLIBC__)\
   || (defined __APPLE__ && defined __MACH__)  \
   || (defined _WIN32 && ! defined __CYGWIN__))
   fbp[1] = '%';
   fbp[2] = 'n';
   fbp[3] = '\0';
   # else

>From what I understand in their comment after the #else they try do to
their best to avoid using %n.  You are referring to line 4879, which
means you were looking on the gnulib integrated on the 1.22.4.  We also
have the same logic on the up-to-date gnulib (line 5126):

   /* On systems where we know that snprintf's return value
  conforms to ISO C 99 (HAVE_SNPRINTF_RETVAL_C99) and that
  snprintf always produces NUL-terminated strings
  (HAVE_SNPRINTF_TRUNCATION_C99), it is possible to avoid
  using %n
   [...]
   #else   /* AIX <= 5.1, HP-UX, IRIX, OSF/1, Solaris <= 9, BeOS */

   fbp[1] = '%';
   fbp[2] = 'n';
   fbp[3] = '\0';
   #endif

Does your build bump into the code after the #else?

> The way gnulib detects whether to compile that code seems to be
> very broken.  On the one hand, gnulib performs extremely complex
> tests that resemble an (overly aggressive) regression suite rather
> than mere feature tests.  If i understand correctly, if *anything*
> in that suite fails, no matter whether it's important or just a
> very weird corner case, gnulib tends to compile the file
> gnulib/lib/vasnprintf.c.

I think we have vasnprintf.c only because it is a dependency of the
vsnprintf module (listed in 'gnulib_modules' in bootstrap.conf).

> On the other hand, that file does lots
> of very complicated version number and operating system name tests
> on its own at compile time rather than at ./configure time, so it
> is very difficult to figure out what is actually happening, and
> even more so to check whether what is happening in a specific
> compilation run is correct.
>
> For example, it appears that one among large numbers of effects
> that can trigger compilation of gnulib/lib/vasnprintf.c is that the
> operating system denies %n in writeable memory, and as a consequence
> gnulib/lib/vasnprintf.c is compiled and then proceeds to use %n in
> writeable memory.
[...]

>From what I understand we build this code only on some old platforms.
The code that uses %n is not built on my system.

[...]
> While i did rarely run into operating systems that failed to provide
> the non-standard function vasprintf(3) - a GNU extension also
> available in all BSDs - groff does not use that function.  I do not
> remember ever running into a system lacking any of the standard
> functions * fprintf(3) - first appeared in Version 7 AT&T UNIX *
> snprintf(3) and vsnprintf(3) - first in 4.4BSD
>
> So my favourite solution would be to just stop using all the gnulib
> *printf* modules.  I'm not aware of any portability problems they
> might help to solve, not even on historic systems like Solaris 9,

the *printf* modules from gnulib were used in replacement of some printf
functions implemented directly in groff's source code.  I believe that
the gnulib's versions are much better maintained.  Perhaps that now
groff builds fine without any replacement function at all, but that
would require to spend extra time to check that, so unless it is clearly
proven that there is a problem in gnulib's replacement functions I don't
see any reason to remove them.

> but they most definitly cause severe portability and security issues
> on several operating systems, in particular on modern ones.
>
> What do you think?
>
> Should i do testing without these three modules on OpenBSD, Linux,
> and various versions of Solaris to see if that improves matters?

I think that unless you find out that the code using %n is really
compiled and used on one of your build, it's not worth spending time on
that.

Regards,
Bertrand