Your message dated Tue, 27 Sep 2022 17:42:12 -0500
with message-id <20220927224212.vdrtqagynr7wyhjh@illithid>
and subject line Re: groff: nroff wrapper skript should translate ISO-8859-15
into latin1
has caused the Debian Bug report #435800,
regarding groff-base: want nroff to treat ISO 8859-15 charmap as ISO Latin-1
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
435800: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435800
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: groff
Version: 1.18.1.1-12
Severity: normal
The groff package ships an nroff wrapper that tries to detect the
correct value for the -T option. This script should treat a ISO-8859-15
charmap the same way as ISO-8859-1.
Note that ISO-8859-15 is supposed to replace ISO-8859-1. The only
difference is that it defines a character Code für the EURO currency
symbol.
Hence I propose the following patch:
--- /usr/bin/nroff 2006-04-17 14:11:28.000000000 +0200
+++ - 2007-08-03 11:22:01.069054000 +0200
@@ -8,7 +8,7 @@
case "`locale charmap 2>/dev/null`" in
UTF-8)
T=-Tutf8 ;;
- ISO-8859-1)
+ ISO-8859-1 | ISO-8859-15)
T=-Tlatin1 ;;
IBM-1047)
T=-Tcp1047 ;;
@@ -18,7 +18,7 @@
case "${LC_ALL-${LC_CTYPE-${LANG}}}" in
*.UTF-8)
T=-Tutf8 ;;
- iso_8859_1 | *.ISO-8859-1)
+ iso_8859_1 | *.ISO-8859-1 | iso_8859_15 | *.ISO-8859-15 )
T=-Tlatin1 ;;
*.IBM-1047)
T=-Tcp1047 ;;
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-xen-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages groff depends on:
ii groff-base 1.18.1.1-12 GNU troff text-formatting system (
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-21 GCC support library
ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library
ii libsm6 1:1.0.1-3 X11 Session Management library
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3
ii libx11-6 2:1.0.3-7 X11 client-side library
ii libxaw7 1:1.0.2-4 X11 Athena Widget library
ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar
ii libxmu6 1:1.0.2-2 X11 miscellaneous utility library
ii libxpm4 1:3.5.5-2 X11 pixmap library
ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library
Versions of packages groff recommends:
ii gs-gpl [gs] 8.54.dfsg.1-5 The GPL Ghostscript PostScript int
ii imagemagick 7:6.2.4.5.dfsg1-0.14 Image manipulation programs
ii libpaper1 1.1.21 Library for handling paper charact
pn netpbm <none> (no description available)
ii psutils 1.17-24 A collection of PostScript documen
-- no debconf information
--- End Message ---
--- Begin Message ---
package groff groff-base
# nroff and the latin*.tmac files are in groff-base
reassign 435800 groff-base
retitle 435800 groff-base: want nroff to treat ISO 8859-15 charmap as ISO
Latin-1
tag 435800 + upstream
severity 435800 wishlist
thanks
As noted in my message to this bug of 5 months ago, this report is
invalid. There are 8 code points that differ between ISO 8859-1 and ISO
8859-15. For some of those unique to -15 there is no fallback that does
not lose information.
There is, however, a different problem with the latin9.tmac file that I
recently identified. It is being tracked upstream at:
https://savannah.gnu.org/bugs/index.php?63112
I am closing this bug because it was invalidly premised.
> The groff package ships an nroff wrapper that tries to detect the
> correct value for the -T option. This script should treat a
> ISO-8859-15 charmap the same way as ISO-8859-1.
It should not.
> Note that ISO-8859-15 is supposed to replace ISO-8859-1. The only
> difference is that it defines a character Code für the EURO currency
> symbol.
That is false, as already documented (with specifics) in this bug's log.
Regards,
Branden
signature.asc
Description: PGP signature
--- End Message ---
