Update of bug #42870 (group groff):
Status: Invalid => None
Open/Closed: Closed => Open
_______________________________________________________
Follow-up Comment #12:
[comment #8 comment #8:]
> I cannot reproduce the complaint about `hw` not working with 8-bit
characters.
OK, but that's not the complaint. The complaint is that it _requires_ 8-bit
characters when specifying something in the Latin-1 Supplement block, rather
than accepting the equivalent escape.
For .hcode, this is demonstrable with the test case I posted in bug #66040.
$ file resume
resume: troff or preprocessor input, ISO-8859 text
$ iconv -f iso-8859-1 resume
.ll 1n
r\['e]sum\['e]
.hcode \['e] \['e]
r\['e]sum\['e]
.hcode \['e] é
r\['e]sum\['e]
$ groff -a -ww -Wbreak resume
<beginning of page>
r<'e>sum<'e>
r<'e>sum<'e>
r<'e><hy>
sum<'e>
Specifically, the complaint is that the second .hcode in the test file has an
effect while the first one--nominally equivalent--does not.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?42870>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
