Re: latin1 handling of groff (Re: man&groff from woody)

[Taketoshi Sano <sano@debian.org>]

Thanks. I can see russian manpage in xterm now.

 (This is sent to debian-i18n list.  I send the copy of this mail
  to the maintainer of groff package, with the hope that he can
  make use of this information.)

In <[🔎] 20001015020001.A6799@logic.ru>, on "Sun, 15 Oct 2000 02:00:02 +0400",
  Peter Novodvorsky <nidd@debian.org> wrote:

> 1). If you're using libc6 >= 2.1.92: there is error in Ben's package,
> I've sent him a patch already. You can just make
> ln -s /usr/lib/locale/ru_RU.koi8r /usr/lib/locale/ru_RU.KOI8-R

Thanks for your information.  Japanese locale also needs the similar
link creation for locales 2.1.94-3 which has ja_JP.eucjp but we need
ja_JP.eucJP.

But now I use potato system, so I don't suffer from this problem.

> 2). Load xterm with cyrillic fonts (-fn option) and russian
> locale(ru_RU.KOI8-R!).

What I forgot is just to use load the required fonts.

I use 

   xterm -fn '-etl-fixed-medium-r-normal-*-16-*-72-72-c-*-koi8-1' &

after checking the font name by xfontsel.  This is the only font
on my system for koi8.

> 3). man rpm (for eg.) 

Yeah. Now I see something like

HA3BAH(reveresed N)E
              rpm - MeHe(something like triangle)*ep nakeTOB OT RedHat

and so on.  I think this is the russian characters. Thanks.

 (Unfortunately, I don't know Russian, so I can't read or understand 
  these strings still. But it looks like human characters, anyhow ;)

> This is done with groff compiled w/o japanese support.

FYI, I use locally built groff 1.16-1.2, using the source retreived
from project/experimental.

The patch for groff 1.16-1 is here.

diff -ruN old/groff-1.16/src/include/device.h groff-1.16/src/include/device.h
--- old/groff-1.16/src/include/device.h	Sun Feb  6 18:36:30 2000
+++ groff-1.16/src/include/device.h	Fri Oct 13 15:10:13 2000
@@ -18,4 +18,9 @@
 with groff; see the file COPYING.  If not, write to the Free Software
 Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */
 
+#ifndef _DEVICE_H
+#define _DEVICE_H
+
 extern const char *device;
+
+#endif /* _DEVICE_H */
diff -ruN old/groff-1.16/src/include/eucmac.h groff-1.16/src/include/eucmac.h
--- old/groff-1.16/src/include/eucmac.h	Fri Oct 13 15:46:27 2000
+++ groff-1.16/src/include/eucmac.h	Fri Oct 13 15:19:12 2000
@@ -22,6 +22,9 @@
 #ifndef _EUCMAC_H
 #define _EUCMAC_H
 
+#include <string.h>
+#include "device.h"
+
 #ifdef NIPPON
 typedef unsigned int	wchar;
 #else
@@ -35,11 +38,23 @@
 
 inline int is_euc_code(wchar wc)
 {
+  if ( device ) {
+	if ((strncmp(device, "latin1", 6) == 0) ||
+	    (strncmp(device, "ascii8", 6) == 0)) {
+		return(0);
+	}
+  }
   return((wc & EUCMASK) == EUCMASK);
 }
 
 inline int is_euc_byte(unsigned char c)
 {
+  if ( device ) {
+	if ((strncmp(device, "latin1", 6) == 0) ||
+	    (strncmp(device, "ascii8", 6) == 0)) {
+		return(0);
+	}
+  }
   return(c >= 0xa1 && c <= 0xfe);
 }


This patch just disables the jgroff patch effect for latin1 and
ascii8 devices.  Possibly you can use this for groff 1.15.3-2 in
woody.

Perhaps the wide char handling in groff should be drastically improved.
The current design is not very suited for smart wide char handling.
utf-8 support will have much troubles without the new design scheme
using mbrtowc() etc.

But this may be the target for 1.20 or 2.0 of the groff (we should
discuss this problem with the upstream of the groff as well as our
Debian maintainer of groff), so I think we should have some trick
for this problem currently.

Regards.
-- 
  Taketoshi Sano: <sano@debian.org>,<sano@debian.or.jp>,<kgh12351@nifty.ne.jp>