Hi Walter, At 2023-10-25T14:25:42+0200, Walter Alejandro Iglesias wrote: > > This transcript isn't as useful as it could be, because it didn't > > disclose to me what character encoding was used for list.tr on the > > file system. Running the file(1) command on it and sharing that > > would help. > > I think I said it several times that list.tr is a utf-8 file. And I > wouldn't trust file(1) on that.
Okay; "od -c list.tr | head -n 5" or similar would be fine too. > In OpenBSD preconv (1.22.4) is compiled without iconv. Okay. I expect that preconv to handle only Latin-1 or UTF-8 input, then. > I had to downgrade Devuan to stable, which comes with groff 1.22.4, > and preconv compiled *with* iconv. I cannot reproduce the bug here. > So, this has all the numbers to be a regression, in your place I'd try > to figure out in with patch between 1.22.4 and the current version was > introduced. I can't demonstrate a regression. Here's what I get when using Debian's 1.22.4. $ printf 'la t\355a\n' | /usr/bin/preconv -e latin1 | /usr/bin/nroff \ | head -n 1 la tía $ printf 'la t\355a\n' | /usr/bin/nroff -K latin1 | head -n 1 /usr/bin/nroff: invalid option -K $ printf 'la t\355a\n' | /usr/bin/nroff | head -n 1 la tía Commands 1 and 3 produce the same output for me as groff 1.23.0. Command 2 fails on groff 1.22.4 because we hadn't added support for '-K' to nroff yet--but it is just a shorthand for command 1 anyway. (In case anyone was wondering, command 3 works, but if we ever get GNU troff to read UTF-8 input, it will stop, unless we add yet another command-line option.) > I know that my bug report isn't as helpful as it could be, but right > now I'm doing other things, sorry. Maybe someone else can reproduce the problem? Regards, Branden
signature.asc
Description: PGP signature
