Re: problem with mm macros

[G. Branden Robinson]

Hi Andreas,

At 2021-02-25T15:43:50+0100, Andreas Eder wrote:
> I'm a newcomer to roff and have just begun reading the book 'UNIX
> Document Processing and Typesetting'. There is an example of a letter
> in there thay I enclose here, necause it shows the poblem:
[...]
> Now the problem is that groff doesn't show the author's title below
> the author's name. Both heirloom and neatroff do, so it is maybe a bug
> in groff? Also both heirloom and neatroff show name and tile in bold,
> whereas groff only shows the name an does not do so in bold.
> 
> Maybe someone with more experience in roff can explain what goes
> wrong.

There were some errors in your input, and groff 1.22.4 mm was not very
helpful about identifying them, nor did its groff_mm(7) man page make
terribly clear what you should be doing.

When I try your input with groff 1.23.0, released last month, I get the
following error.

$ ~/groff-stable/bin/groff -ww -b -mm -Tutf8 ATTIC/eder-letter.mm |cat -s
m.tmac:.../groff-stable/share/groff/1.23.0/tmac/mm/5.MT:48: error: title not 
defined; call TL and AU before MT

A problem is that, as noticed in the original thread from 2½ years ago,
is that you should have been using either:

1.  The `AU` and `TL` macros _both_ with `MT`, or

2.  The `WA` and `WE` macros with `LT`.

Another problem was that you gave 2 arguments to the `FC` macro when it
accepts only one.

The man page has some new language about these matters.

   Document styles
 groff mm offers three different frameworks for document
 organization.  COVER/COVEND is a flexible means of preparing any
 document requiring a cover page.  LT/LO aids preparation of typical
 Anglophone correspondence (business letters, for example).  The MT
 memorandum type mechanism implements a group of formal styles
 historically used by AT&T Bell Laboratories.  Your document can
 select at most one of these approaches; when used, each disables
 the others.
[...]
Macros
[...]
 AU [name [initials [loc [dept [ext [room [arg1 [arg2 [arg3]
 Specify author.  AU terminates a document title started
 with TL, and can be called without arguments for that
 purpose.  Author information is used by cover sheets, MT
 memoranda, and SG.  Further arguments comprise initials,
 location, department, telephone extension, room number or
 name, and up to three additional items.  Repeat AU to
 identify multiple authors.

 Use WA/WE instead to identify the author for documents
 employing LT.
[...]
 FC [closing‐text]
 Output the string Letfc, or the specified closing‐text, as
 the formal closing of a letter.
[...]
 LT [style]
 Format a letter in the designated style, defaulting to BL
 (see below).  A letter begins with the writer’s address
 (WA/WE), followed by the date (ND), the inside address
 (IA/IE), the body of the letter (P and other general‐
 purpose mm macros), the formal closing (FC), the signature
 (SG), and notations (NS/NE).  Any of these may be omitted.
 Letter options specified with LO add further annotations,
 which are extensible; see section “Internals” below.

 style   Description
 BL  Blocked: the writer’s address, date, formal
 closing, and signature are indented to the center
 of the line.  Everything else is left‐aligned.
 SB  Semi‐blocked: as BL, but the first line of each
 paragraph is indented by 5m.
 FB  Fully blocked: everything begins at the left
 margin.
 SP  Simplified: as FB, but a formal closing is omitted,
 and the signature is set in full capitals.

I used DWB 3.3 mm as my basis for comparison.  It requires as well the
`IA`/`IE` macros for an inside address to be called for `LT` letters,
but they need not have any content.  groff mm doesn't demand them.

DWB 3.3 mm also does not put anything in boldface or italics in `LT`
letters.  The examples in its manual also do not exhibit such style
changes.

groff mm (in 1.23.0) uses only one blank line of vertical spacing at
most between segments of the letter.  I judged this to be the best
approach since there is no standard defining how large these gaps should
be--one vee seemed a reasonable minimum that people could alter within a
letter with `SP` calls, as you did, and anything not covered by that
technique, we can add registers for, probably in the `Letxxx` name
space.

I had problems with Heirloom Doctools mm.  It appears to believe that no
authors are defined.  It also throws some garbage on the output.  But it
also doesn't do any font style changes as you seemed to be expecting.
This at least is consistent with DWB 3.3 (Heirloom's predecessor).

~/heirloom$ ./bi

Re: PDF outline not capturing Cyrillic text

[Deri]

On Saturday, 12 August 2023 07:35:20 BST G. Branden Robinson wrote:
> Hi Deri,
> 
> At 2023-06-23T22:40:42+0100, Deri wrote:
> > On Friday, 23 June 2023 19:17:58 BST Robin Haberkorn wrote:
> > > So it seems that the main problem really lies in grops and/or gropdf
> > > which should ideally work with the Unicode escapes produced by
> > > preconv.  I am not sure if we would still need .pdfmomclean. But
> > > whatever useful stuff it currently does, it should probably be in
> > > pdfmark.tmac (and/or pdf.tmac?) instead.
> 
> [...]
> 
> > The features you require are coming. This is an example of Russian
> > with bookmarks in cyrillic. I'm afraid I don't know what it means and
> > I have forgotten where I got the text.
> 
> [attachment stripped]
> 
> That's my "makhnovshchina.groff" demo from back in March.
> 
> https://lists.gnu.org/archive/html/groff/2023-03/msg00100.html
> 
> Regards,
> Branden

Hi Branden,

That's it. And here's the result using the deri-gropdf-ng branch.

Cheers 

Deri




maknovshchina.pdf
Description: Adobe PDF document

Re: [PATCH v2] man*/: ffix (migrate to `MR`)

[Alejandro Colomar]

Hi Branden, Ingo,

On 2023-08-01 16:12, G. Branden Robinson wrote:
> At 2023-08-01T15:35:10+0200, Alejandro Colomar wrote:
>> [CC += groff]
>>
>> Hi Jakub, Branden,
>>
>> On 2023-08-01 03:31, G. Branden Robinson wrote:
>>> Hi Jakub,
>>>
>>> At 2023-08-01T00:16:41+0200, Jakub Wilk wrote:
 * G. Branden Robinson , 2023-07-31 12:52:
> Use the man(7) macro `MR`, new to groff 1.23.0,

 Given that this version of groff was released approximately
 yesterday¹, this is very premature.

 NACK from me.

 ¹ More precisely, about a month ago.
>>>
>>> 5 July UTC, to be (a little) more precise.
>>>
>>> Linux man-pages release scheduling is Alex's prerogative, not mine.
>>
>> I just made a new release, so that we have plenty of time for the next
>> one.
> 
> I saw that, and thought, "ooh, that's a bit quick--surely he didn't..."
> 
> And no, you didn't (include the giant `MR` migration patch).

Not yet.  I hope to have MR support in mandoc(1) before I release that.
Ingo, would you mind?  :)

> 
> I trust the announcement didn't give Jakub a heart attack...
> 
>> I don't expect to make a new one in months.  :)
> 
> I can't cast stones about release frequency, that's for sure.
> 
>>> He asked me (a long time ago) to deliver this after groff 1.23.0 was
>>> released.  That is what I have tried to do.
>>
>> Thanks!
> 
> A pleasure.  Not merely to promulgate my "baby", but also to get a lot
> of that cargo-culty stuff around tables cleaned out of the Linux
> man-pages.  Tidy man(7) sources make for happier documentation writers
> who have an easier time getting what they want.

Yup!

> 
>>> groff 1.22.4 man(7) does not support the `MF` string (see below).
>>> That could be backported too, but there seems no point before there
>>> is a concrete need.
>>>
 After applying the patch, the man page references are typeset in
 italics,
>>>
>>> For great justice!  (See below.)
>>
>> Still I think this should be documented in our commit.  Would you
>> please send a paragraph (and the position at which you'd place it)
>> with which I can amend the commit?
> 
> Yes.  That was on oversight on my part; I was scrubbing out all font
> changes (with "-P -cbou") because my concern was with unexpected changes
> to adjustment and hyphenation.  The style change for man page topics
> (from bold to italics) was a "known factor" (to me).

Would you mind sending an updated commit message?

> 
> Also, I saw that some "=3D" quoted-printable ugliness got into the
> commit message, buried inside groff command-line options where people
> unaccustomed to writing them might not mentally screen out the noise.

Heh, I noticed some weirdness about it, but it happened to be after a
-rCHECKSTYLE, so it seemed like it could be some improvements that you
had applied upstream to CHECKSTYLE.  =3 definitely made sense to that
register.

> 
> Please double-check for that before pushing to kernel.org.

Please send one that I don't need to modify.  I don't like modifying
other's stuff, in case I break it.  :)

> 
 which is ugly
>>>
>>> See my recent exchanges with Lennart Jablonka on this list.
>>>
 and against man-pages(7) recommendations.
>>
>> Well, we should update those to use MR.
> 
> And man(7) too, I guess.  What do you think?

I want to kill that page.  Please have a look at it, take anything
good that it has for groff_man{,_style}(7), and ping me when I
should sharpen the scythe.  ;)

Cheers,
Alex

> 
>> Branden is right that italics is more appropriate.  He has defended
>> that position very well, so I'll let him defend that point.  The
>> conversation to which he referred was:
>>
>> 
> 
> Yes.  That message includes Ingo's acknowledgement of my historical
> analysis, which can be found in the parent message.
> 
> https://lists.gnu.org/archive/html/groff/2021-08/msg00023.html
> 
> But we had a fairly wide-ranging discussion, much of which will not be
> of interest to someone who updates to man-pages 6.6.6 🤘, sees italics
> appearing where they had been accustomed to bold, and flies into a rage.
> 
> I reckon the virtuous thing to do would be to write an ms(7) article
> about the history of cross reference styling in Unix man pages.  I
> regret that my conjecture about _why_ the GNU/Linux community shifted
> the style (VGA text mode limitations) remains unsupported by testimonial
> accounts from people who deliberately made this change.
> 
> Maybe this change will attract the attention of those folks.  Even if
> they get angry with me in the process, I'm willing to risk being called
> out as the price of improving the historical record.  :)
> 
>> But we should document in the commit message that the MR default
>> implies a behavior change in our pages.
> 
> Yes.  And it's not hard to offer MANROFFOPT="-dMF=B" as an initial
> workaround.  One could throw this into one's shell startup file, but
> only man-db man(1) honors that variable.  The more syst

Anyone want to write an article about fonts in groff?

[Jim Hall]

Hi everyone!

I was thinking about writing a few articles for Technically We Write
about fonts in groff. But I thought "This would be a great article for
someone else to write" so I wanted to suggest it here.

Here are two article ideas:

1. An article about how fonts work in groff (each is "mounted" to a
different font "position" number) and showing how to use different
fonts in a groff document. For example, to mount Helvetica Narrow
(HNR) to font position 5 (I think that's unused in -me) and set the
.sh and .uh fonts in -me to that:

.fp 5 HNR
.nr sf 5

2. How to convert a TrueType font and use them in groff documents. I
found this how-to article that seems to explain it pretty well, but I
haven't tried it yet:

http://www.port.de/cgi-bin/groff/AddingFonts


If anyone is interested in writing an article like this, let me know!


Jim

PDF book improvements

[Alejandro Colomar]

Hi Deri,

My end goal is to be able to embed the creation of the PDF book in the
Makefiles.  To that end, as a first step, I'd like to reuse part of
what we already have in the Makefile.  Currently, we process all files
with -Tpdf, which I guess we'll be able to reuse.

 $ make build-pdf -kij >/dev/null 2>&1
 $ touch man2/gettimeofday.2 
 $ make build-pdf V=1 | sed '/^[[:upper:]]/s/^/\n/'

 PRECONV.tmp/man/man2/gettimeofday.2.tbl
 preconv   man2/gettimeofday.2 >.tmp/man/man2/gettimeofday.2.tbl

 TBL.tmp/man/man2/gettimeofday.2.eqn
 tbl <.tmp/man/man2/gettimeofday.2.tbl >.tmp/man/man2/gettimeofday.2.eqn

 EQN.tmp/man/man2/gettimeofday.2.pdf.troff
 ! (eqn -Tpdf   <.tmp/man/man2/gettimeofday.2.eqn 2>&1 
>.tmp/man/man2/gettimeofday.2.pdf.troff) \
 | grep ^ >&2

 TROFF  .tmp/man/man2/gettimeofday.2.pdf.set
 ! (troff -Tpdf -wbreak  -man  <.tmp/man/man2/gettimeofday.2.pdf.troff 2>&1 
>.tmp/man/man2/gettimeofday.2.pdf.set) \
 | grep ^ >&2

 GROPDF .tmp/man/man2/gettimeofday.2.pdf
 gropdf   <.tmp/man/man2/gettimeofday.2.pdf.set 
>.tmp/man/man2/gettimeofday.2.pdf

What part of this "pipeline" can we reuse?  I guess we can reuse the
.pdf.troff files.  The .pdf.set files probably cannot be reused for
the single book, as they'll have the page numbers and so on already
set, right?

So, I'm imagining that we could cat(1) your front cover with all
these files, and then process with troff(1) and gropdf(1).  Does
that make sense?

Could we also reuse the .pdf.set files and only run gropdf(1) on
the catenation of them?

Cheers,
Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: PDF book improvements

[Alejandro Colomar]

On 2023-08-12 23:46, Alejandro Colomar wrote:
> Hi Deri,
> 
> My end goal is to be able to embed the creation of the PDF book in the
> Makefiles.  To that end, as a first step, I'd like to reuse part of
> what we already have in the Makefile.  Currently, we process all files
> with -Tpdf, which I guess we'll be able to reuse.
> 
>  $ make build-pdf -kij >/dev/null 2>&1
>  $ touch man2/gettimeofday.2 
>  $ make build-pdf V=1 | sed '/^[[:upper:]]/s/^/\n/'
> 
>  PRECONV  .tmp/man/man2/gettimeofday.2.tbl
>  preconv   man2/gettimeofday.2 >.tmp/man/man2/gettimeofday.2.tbl
> 
>  TBL  .tmp/man/man2/gettimeofday.2.eqn
>  tbl <.tmp/man/man2/gettimeofday.2.tbl >.tmp/man/man2/gettimeofday.2.eqn
> 
>  EQN  .tmp/man/man2/gettimeofday.2.pdf.troff
>  ! (eqn -Tpdf   <.tmp/man/man2/gettimeofday.2.eqn 2>&1 
> >.tmp/man/man2/gettimeofday.2.pdf.troff) \
>  | grep ^ >&2
> 
>  TROFF.tmp/man/man2/gettimeofday.2.pdf.set
>  ! (troff -Tpdf -wbreak  -man  <.tmp/man/man2/gettimeofday.2.pdf.troff 
> 2>&1 >.tmp/man/man2/gettimeofday.2.pdf.set) \
>  | grep ^ >&2
> 
>  GROPDF   .tmp/man/man2/gettimeofday.2.pdf
>  gropdf   <.tmp/man/man2/gettimeofday.2.pdf.set 
> >.tmp/man/man2/gettimeofday.2.pdf
> 
> What part of this "pipeline" can we reuse?  I guess we can reuse the
> .pdf.troff files.  The .pdf.set files probably cannot be reused for
> the single book, as they'll have the page numbers and so on already
> set, right?
> 
> So, I'm imagining that we could cat(1) your front cover with all
> these files, and then process with troff(1) and gropdf(1).  Does
> that make sense?
> 
> Could we also reuse the .pdf.set files and only run gropdf(1) on
> the catenation of them?

Oh, and another thing.  I have a branch that uses the new MR macros.
It would be interesting to use them to do the hyperlinking.

If you want to check the branch, it's here:

However, I rebase that branch against master, to update it with any
new man-page references that are introduced by new patches, so please
don't rely on its stability (If you need something stable, we can
agree on something).

Cheers,
Alex

> 
> Cheers,
> Alex
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5



OpenPGP_signature
Description: OpenPGP digital signature

Re: PDF book improvements

[Alejandro Colomar]

On 2023-08-12 23:46, Alejandro Colomar wrote:
> Hi Deri,
> 
> My end goal is to be able to embed the creation of the PDF book in the
> Makefiles.  To that end, as a first step, I'd like to reuse part of
> what we already have in the Makefile.  Currently, we process all files
> with -Tpdf, which I guess we'll be able to reuse.
> 
>  $ make build-pdf -kij >/dev/null 2>&1
>  $ touch man2/gettimeofday.2 
>  $ make build-pdf V=1 | sed '/^[[:upper:]]/s/^/\n/'
> 
>  PRECONV  .tmp/man/man2/gettimeofday.2.tbl
>  preconv   man2/gettimeofday.2 >.tmp/man/man2/gettimeofday.2.tbl
> 
>  TBL  .tmp/man/man2/gettimeofday.2.eqn
>  tbl <.tmp/man/man2/gettimeofday.2.tbl >.tmp/man/man2/gettimeofday.2.eqn
> 
>  EQN  .tmp/man/man2/gettimeofday.2.pdf.troff
>  ! (eqn -Tpdf   <.tmp/man/man2/gettimeofday.2.eqn 2>&1 
> >.tmp/man/man2/gettimeofday.2.pdf.troff) \
>  | grep ^ >&2
> 
>  TROFF.tmp/man/man2/gettimeofday.2.pdf.set
>  ! (troff -Tpdf -wbreak  -man  <.tmp/man/man2/gettimeofday.2.pdf.troff 
> 2>&1 >.tmp/man/man2/gettimeofday.2.pdf.set) \
>  | grep ^ >&2
> 
>  GROPDF   .tmp/man/man2/gettimeofday.2.pdf
>  gropdf   <.tmp/man/man2/gettimeofday.2.pdf.set 
> >.tmp/man/man2/gettimeofday.2.pdf
> 
> What part of this "pipeline" can we reuse?  I guess we can reuse the
> .pdf.troff files.  The .pdf.set files probably cannot be reused for
> the single book, as they'll have the page numbers and so on already
> set, right?
> 
> So, I'm imagining that we could cat(1) your front cover with all
> these files, and then process with troff(1) and gropdf(1).  Does
> that make sense?
> 
> Could we also reuse the .pdf.set files and only run gropdf(1) on
> the catenation of them?

I added a script to sort these files, as you do with your sortman()
perl function.  I called it sortman too :)


$ cat scripts/sortman 
#!/bin/sh

# Copyright 2023, Alejandro Colomar 
# SPDX-License-Identifier: GPL-3.0-or-later

export LC_COLLATE=en_US.UTF-8;

sed   -E '/\/intro./ s/.*\.([1-8])$/\10\t&/' \
| sed -E '/\/intro./!s/.*\.([1-8])$/\11\t&/' \
| sed -E '/\/intro./!s/.*\.([1-8].+)/\1\t&/' \
| sort \
| cut -f2;


We'll probably need this to sort the files in the shell.

> 
> Cheers,
> Alex
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5



OpenPGP_signature
Description: OpenPGP digital signature