Created attachment 417335 [details] screenshot of fprintf(3) with both man-db and man Description of problem: See screenshot: With man-db, when trying to see Japanese man page fprintf(3) if some long line exists such line is split on unexpected positions and as the result fprintf(3) manual page cannot be seen easily with man-db. With man (in F-13) long lines are split on expected positions. Version-Release number of selected component (if applicable): man-db-2.5.7-2.fc14.i686 How reproducible: 100% Steps to Reproduce: 1. install man-pages-ja 2. man fprintf in LANG=ja_JP.UTF-8 3. Actual results: See screenshot Expected results: New line should begin at expected positions like in F-13 man
Hi. I will take it. Seems like a 'groff' problem. Jan
Proper word and line breaking rules are defined by JIS X 4051:2004 <http://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=en&bunsyoId=JIS+X+4051%3A2004&dantaiCd=JIS&status=1&pageNo=0>. Wikipedia offers loose excerpt of some basic rules <http://en.wikipedia.org/wiki/Kinsoku_shori>. More complex overview provides <http://www.jepa.or.jp/press_release/reqEPUBJ.html> and <http://www.w3.org/TR/2009/NOTE-jlreq-20090604/>. In addition to rules forbidding line break, groff must understand kana or kanji occupies two columns of fixed width terminal usually, whereas latin letters one column only. As man pages usually mix both of them, groff must compute proper width of each symbol precisely to get correct display width of a text.
Finally some update. I expect there will be some progress in upstream on this problem soon: [Groff] character width in font files http://www.mail-archive.com/groff@gnu.org/msg05443.html
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Jan and Tasaka-san, You might want to try a test package with the patches about which we are discussing with the upstream: http://ueno.fedorapeople.org/groff/groff-1.20.1-3.fc13.src.rpm
(In reply to comment #5) > Jan and Tasaka-san, > > You might want to try a test package with the patches about which we are > discussing with the upstream: > > http://ueno.fedorapeople.org/groff/groff-1.20.1-3.fc13.src.rpm I tried this on F-14 and it seems good.
(In reply to comment #5) > You might want to try a test package with the patches about which we are > discussing with the upstream: Thanks, it works well! However I don't want to include your patches now, as you qualified them as a "proof-of-concept". I definitely will not do it for F14. But I'm considering it into Rawhide. Do you have some strong arguments?
I'd fine with it. Thanks for testing.
I think this should be fixed in F-14, because for Japanese people this issue is rather critical. Setting F14Target.
(In reply to comment #9) > I think this should be fixed in F-14, because for Japanese people > this issue is rather critical. Setting F14Target. I completely understand you. But I don't want to put some code, which is not ready and verified, into stable release. This situation is really unpleasant. Daiki, are you still working on your patches? Can we expect some progress soon? Do you think, your changes are safe enough to be included in F14 as they are?
(In reply to comment #9) > I think this should be fixed in F-14, because for Japanese people > this issue is rather critical. Setting F14Target. Frankly I though that this was not that critical - Debian has the same issue since the last year and I have seen only a few people complaining :) (In reply to comment #10) > Daiki, are you still working on your patches? Can we expect some progress soon? > Do you think, your changes are safe enough to be included in F14 as they are? I'm now asking the original patch author about the status of his work but no response so far. While it will take some time for the patch to be applied in upstream (because of paperwork, etc.), it might be worth asking them to check if the patch will not cause regression. I'll do that anyway.
Daiki, some news?
Unfortunately, still no response from the upstream. FWIW I updated the patches & SRPM to fix "TODO" lines in the original patch: http://ueno.fedorapeople.org/groff/ (There are still a couple of TODOs left, which look harmless to me). Perhaps it might be a good time to start testing in rawhide?
I agree. The patch won't make things worse. :-) I will push that into Rawhide soon. Daiki, please, could you poke people on groff list again? Send the updated patches with your comments and that we are going to try it in Fedora Rawhide? I would be very glad if we managed to get this included upstream.
Fixed in groff-1.20.1-3.fc15 Daiki, thank you! Great work!
I've left some comments on this patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552201 (also upstream, but their mailing list archive hasn't updated yet). Folks on this bug may be interested. Just to be explicit (although Jan implied it in comment 1), I expect that the appearance of this bug had everything to do with the switch from groff 1.18.1.4 with the old multibyte patch in Fedora 13 to groff 1.20.1 with no such patch in Fedora 14, and nothing to do with the switch from man to man-db that happened in the same release cycle.