Bug 83608 - groff-1.18.1-9 adds extra spaces to show Japanese man pages
Summary: groff-1.18.1-9 adds extra spaces to show Japanese man pages
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: groff
Version: phoebe
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Florian La Roche
QA Contact: Mike McLean
Depends On:
Blocks: 79578
TreeView+ depends on / blocked
Reported: 2003-02-06 09:09 UTC by Nakai
Modified: 2007-04-18 16:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-10 08:04:15 UTC

Attachments (Terms of Use)
groff-good.png (7.09 KB, image/png)
2003-02-06 09:10 UTC, Nakai
no flags Details
groff-bad.png (4.84 KB, image/png)
2003-02-06 09:11 UTC, Nakai
no flags Details

Description Nakai 2003-02-06 09:09:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.2.1) Gecko/20030115

Description of problem:
groff-1.18.1-9 adds extra spaces when it formats to show Japanese
man pages.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. man man (or something)
2. all Japanese chars have extra space...

Actual Results:  See the screen shot: groff-bad.png

Expected Results:  See the screen shot: groff-good.png

Additional info:

Comment 1 Nakai 2003-02-06 09:10:51 UTC
Created attachment 89887 [details]

output of groff-1.18.1-8

Comment 2 Nakai 2003-02-06 09:11:28 UTC
Created attachment 89888 [details]

output of groff-1.18.1-9

Comment 3 Nakai 2003-02-06 09:14:25 UTC
groff-1.18.1-9 also cuts several strings and breaks the Japanese sentence.
(See above groff-bad.png screen shot)

Comment 4 Tim Waugh 2003-02-06 17:47:53 UTC
This is the kind of output we're getting from grotty, in hex bytes:

cc be 08 cc be 20 c1 b0 08 c1 b0 0a

----- ^H ----- SP ----- ^H ----- \n

(where '----' indicates a two-byte glyph)

The ^H is for overstriking.

Everything looks fine to me.  kterm bug?

Previously it would have looked something like:
cc 08 cc be 08 be 20 c1 08 c1 b0 08 b0 0a
which is incorrect (breaking up multibyte characters)

Comment 5 Miloslav Trmac 2003-02-06 18:22:34 UTC
Perhaps I am missing something, but this really seems to be a groff bug.

While the reported new groff behavior is better than before, there should be
no 0x20 (' ') characters there at all, and the terminal emulator is
correctly displaying the spaces.

Comment 6 Tim Waugh 2003-02-06 18:36:18 UTC
Sorry, you're right.

To examine byte output I'm using:

zcat $(man -w rpm)|troff -c -mandoc -Tnippon | head -44 | strace -ewrite grotty

Comment 7 Tim Waugh 2003-02-06 19:08:01 UTC
Please try groff-1.18.1-11.

Comment 8 Eido Inoue 2003-02-06 20:08:42 UTC
um, don't you need more the one BS to overstrike a two-character cell wide glyph?

Comment 9 Jay Turner 2003-02-07 18:59:57 UTC
I still think that we have a problem here, even with groff-1.18.1-11 installed.
 The output of "LANG=ja_JP.UTF-8 man nroff" looks nothing like what is posted in
the bug report (note, this is when running inside kterm).  In addition, I'm
still seeing what appear to be extra spaces when running 'man groff'

Comment 10 Florian La Roche 2003-02-09 16:39:58 UTC
Please test groff-1.18.1-14 and check if that fixes your problems. Please
test on console, GUI etc and let me know if something is still broken.


Florian La Roche

Comment 11 Florian La Roche 2003-02-09 17:38:36 UTC
groff-1.18.1-14 or -15 should have this ok.


Florian La Roche

Comment 12 Nakai 2003-02-10 08:04:15 UTC
Confirmed with groff-1.18.1-15

Comment 13 Nakai 2003-02-10 08:12:05 UTC
Comment #9: You should try LANG=ja_JP.eucJP

Comment 14 Nakai 2003-02-10 09:20:49 UTC
JLESSCHARSET=japanese LANG=ja_JP.eucJP man man

on kterm might be good for QA

Note You need to log in before you can comment on or make changes to this bug.