groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: -s flag (soelim) not working?


From: G. Branden Robinson
Subject: Re: -s flag (soelim) not working?
Date: Mon, 19 Sep 2022 15:43:25 -0500

Hi Peter,

At 2022-09-19T13:38:35-0400, Peter Schaffter wrote:
> I recently discovered that documents with .so'd files containing
> non-ASCII input require preprocessing with soelim(1).  If we have
> 
> file: source
> .pl 1v
> .ds FOO àéîöù
> 
> file: main
> .so source
> .nop \*[FOO]
> 
> running
>   groff -Tutf8 -k main
> spits out garbage, whereas
>   soelim main | groff -Tutf8 -k
> correctly renders string FOO.
> 
> soelim(1) doesn't mention utf8 input, merely
>   "It is useful if files included with .so need to be preprocessed."
> 
> Since it is non-evident that utf8 input (as opposed to inputting
> named glyphs) in sourced files needs to be preprocessed (i.e.
> with soelim), saying something about it in the manpage would be
> helpful.  I'm fairly certain most users, on reading "...need to be
> preprocessed" think tbl, pic, eqn, grap, chem..., not utf8 input.
> 
> Now, the '-s' flag issue...  Unless I am misunderstanding or
> misreading something,
>   soelim main | groff -Tutf8 -k
> and
>   groff -Tutf8 -ks main
> should produce identical output, however the -s flag is ignored and
> groff spits out garbage.  What's up?

I believe this issue came up last month as well.

https://lists.gnu.org/archive/html/groff/2022-08/msg00231.html

Apparently groff has "always" been this way, since preconv was written.

Bjarni noted this and complained about it in Savannah #59442, back in
November 2020.

https://savannah.gnu.org/bugs/?59442

I raised some concerns about changing the preprocessing order--I was
concerned about EBCDIC input and about files named in .so requests.
I was able to talk myself out of being worried about EBCDIC issues but
not so much the other.  (Also it would be really nice if some OS/390
Unix groff user would talk to us!)

Ingo suggested deferring consideration of the issue, since we were,
ehrm, "close to a release".

Certainly the question can be reconsidered.

Right now the workaround for sourced files that need to be "preconv"ed
is to run preconv on them externally and store them that way (so, to
pre-preconv them :-| ).  That might reduce maintainability,
unfortunately, because \[uXXXX] escape sequences are not friendly to
humans.  That is one reason I think Savannah #58796 is a good idea.

https://savannah.gnu.org/bugs/?58796

Regards,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]