Re: [groff] 05/16: doc/meref.me.in: Update and revise.

2023-09-12 Thread G. Branden Robinson
Hi Dave,

At 2023-09-11T19:43:48-0500, Dave Kemper wrote:
> I have comments on two of the numerous changes of this commit.
> 
> >  this material can then be resequenced
> > +by the
> > +.b pdfswitchtopage
> > +macro (for PDF output),
> >  by a tool that processes the output format,
> >  or physically moved
> >  to the beginning of the printed document.
> 
> Before this insertion, this was two verb phrases joined by an "and";
> now it's written as a series of three items, but two are prepositional
> phrases and one is a verb phrase, which is not a grammatical series.

Fair point.  Wil fix.

> > -Useful for forcing out footnotes,
> > -but other than
> > -that hardly ever used.
> > -Must be followed by a
> > +.\" Useful for forcing out footnotes,
> > +.\" but other than
> > +.\" that hardly ever used.
> 
> I sympathize with wanting to save "page" space (and, more generally,
> striving for concision), but completeness and clarity ought to take
> priority, and I feel this deletion reduces those.
> 
> A .bp or end of input are typically satisfactory ways to end a page or
> a document, so a macro that ends a page but can only precede one of
> those two things sounds nigh useless; the removed sentence was the
> only thing that motivated the macro's use.  Conversely, users who find
> a footnote missing in their document will no longer be able to
> discover the macro that will restore it by searching the -me manual
> for the word "footnote."  And even if they happen across .ep in the
> manual, without that sentence there's still little clue this is the
> solution they were looking for.

You're a more seasoned me(7) user than I am; the only application of
`ep` that I _can_ think of is to flush pending footnotes without causing
a new page to start (which would be blank if the footnote area doesn't
overflow).

Does that match your understanding?  Is there another use case?

Regards,
Branden


signature.asc
Description: PGP signature


Re: 1.23 prints some strange error

2023-09-12 Thread Walter Alejandro Iglesias
Hi Branden,

On Mon, Sep 11, 2023 at 03:33:03PM -0500, G. Branden Robinson wrote:
> This suggests to me that preconv(1) _must_ be run before you try to
> process your documents with this technique.
>  [...]

> Please share input file(s) that reproduce the problem, and a command
> line that produces the diagnostic message you quoted above.

I cleaned up a bit the quoted text to make room for the following.  Here
we go:

  $ uname -a
  Linux bell 6.4.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.13-1 (2023-08-31) 
x86_64 GNU/Linux
  $ groff --version | head -1
  GNU groff version 1.23.0
  $ mkdir test
  $ cd test
  $ cat << EOF > doc.tr
  .mso list.tr
  EOF
  $ cat << EOF > list.tr
  .hw a-hí
  .hw a-ño
  .hw ár-bol
  .hw cu-brí-a
  .hw e-té-re-o
  .hw ca-mión
  .hw ú-te-ro
  .hw pin-güi-no
  EOF
  $ GROFF_TMAC_PATH=. nroff doc.tr
  troff:./list.tr:1: error: expected ordinary or special character, got an 
escaped '%'
  troff:./list.tr:4: error: expected ordinary or special character, got an 
escaped '%'

As you see, from the UTF-8 chars used in Spanish (á, é, í, ó, ú, ü, ñ),
groff seems to only have problems with the 'í' in particular.  Let's try
another test using preconv(1).

  $ export GROFF_TMAC_PATH=.
  $ cat << EOF > doc.tr
  .hla es
  .mso list.tr
  Ahí, el árbol nos cubría con su sombra.
  Un pingüino pasaba caminando por la playa.
  EOF
  $ cat << EOF > list.tr
  .hw a-hí
  .hw ár-bol
  .hw cu-brí-a
  .hw som-bra
  .hw pin-güi-no
  .hw pa-sa-ba
  .hw ca-mi-nan-do
  .hw pla-ya
  EOF
  $ preconv -e UTF-8 doc.tr | nroff | cat -s
  troff:./list.tr:1: error: expected ordinary or special character, got an 
escaped '%'
  troff:./list.tr:3: error: expected ordinary or special character, got an 
escaped '%'
  Ahí, el árbol nos cubría con su sombra.  Un pingüino pasaba cami‐
  nando por la playa.

The errors remain.  Finally, I told you that changing .mso request to
.so made the error messages disappear, that's because in my Makefile I
run soelim(1) before.  Last test:

  $ cat << EOF > doc.tr
  .hla es
  .so list.tr   \" notice here I changed the request
  Ahí, el árbol nos cubría con su sombra.
  Un pingüino pasaba caminando por la playa.
  EOF
  $ preconv -e UTF-8 doc.tr | nroff | cat -s
  troff:./list.tr:1: error: expected ordinary or special character, got an 
escaped '%'
  troff:./list.tr:3: error: expected ordinary or special character, got an 
escaped '%'
  Ahí, el árbol nos cubría con su sombra.  Un pingüino pasaba cami‐
  nando por la playa.
  $ soelim doc.tr | preconv -e UTF-8 | nroff | cat -s
  Ahí, el árbol nos cubría con su sombra.  Un pingüino pasaba cami‐
  nando por la playa.

This last command throws no error, that's because soelim(1) allows
preconv(1) to process the list.tr file.

Anyways.  My doubt comes from the fact that so far (with groff 1.22.4
under OpenBSD) I haven't needed to preprocess that .hw list with
preconv, and that only the 'í' (iacute) triggers the error.  All
suggests that that error is just noise.


> 
> Regards,
> Branden


-- 
Walter



Re: [groff] 05/16: doc/meref.me.in: Update and revise.

2023-09-12 Thread Dave Kemper
On 9/12/23, G. Branden Robinson  wrote:
> You're a more seasoned me(7) user than I am; the only application of
> `ep` that I _can_ think of is to flush pending footnotes without causing
> a new page to start (which would be blank if the footnote area doesn't
> overflow).

That's the only situation I've ever needed to use it in.  Where Allman
wrote "hardly ever," I don't know if he had another obscure use in
mind or was merely hedging his bets.