Re: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces

[Werner LEMBERG]

> (CCing Daiki Ueno and the groff list, since I have some comments on
> the patch and this is a convenient hook for them.)
>
>> I received a patch from him and tested. It worked well,
>> particularly for Japanese and Korean. As far as my tests, it won't
>> break any other languages (tested with C, fr_FR.UTF-8, nl_NL.UTF-8,
>> and ru_RU.UTF-8.)
>>
>> Here is a debdiff against 1.20.1-10.

Right now I'm going to integrate and test the patches.  However, a
very important piece is still missing: documentation!  I won't commit
the changes otherwise.

Please provide a patch for groff.texinfo which fully documents
`.class' (probably by adding a new section `Classes' to `Fonts and
Symbols'), the `classes' keyword for font files, and a proper
extension of the description of the `.cflags' request.  Similarly, I
need updates to the `NEWS', `groff_diff.man', and `groff.man' files.
BTW, this can be rough and sketchy: There's no need to polish the
documentation since I'll do this.

Note that I don't need ChangeLog entries; I've written them already by
myself while reading the code.

>   - nroff: supply "-mja" to groff if running under Japanese locales.
>
> We should be trying to reduce the cases where Japanese is handled
> uniquely, particularly in code rather than in configuration such as
> macro files, and this change introduces one.  Furthermore, relying
> on the locale is a problematic approach we should be trying to
> escape, as it makes it harder to test Japanese pages in English
> locales or vice-versa.

I second that; it's not necessary to do that so I'll omit these
changes to nroff.

> Werner, is there any chance that you might be able to release 1.20.2
> in the near future?

I'll release 1.21 after integrating your and Daiki-san's patches.
Sorry for the large delay.

> Are there any specific blockers (perhaps I could help), or is it just
> a lack of time?  I certainly understand the latter, but would really
> like to be able to take advantage of the change above ...

The main blocker is missing enthusiasm for groff :( Last year I was
extremely busy, and recently I've moved from Germany to Austria, and
in my spare time I've mainly concentrated on FreeType.

> I have to say I agree with Werner in
> http://lists.gnu.org/archive/html/groff/2010-08/msg00000.html when
> he suggests that this would be better done some other way.  Fonts
> aren't ideal, though, because then we'd have to have separate font
> files for Japanese.

There is perhaps a misunderstanding.  I don't object to using wcwidth;
this is used for TTY output only, and grotty outputs characters, not
glyphs, thus it doesn't harm if the logic for character widths is in
the UTF8 part of grotty.  Given how groff + grotty works the
implementation is OK, and the actual changes to the groff code are
less than 10 lines.  What I object, as you've correctly noted, is to
provide special locale-dependent support files.

> Perhaps you could add a new charinfo flag and set this in ja.tmac
> using a character class?  I don't know if that design is perfect
> either, but my feeling is that this kind of problem is why we came
> up with the idea of character classes in the first place.

Yes!  It would allow to overwrite the global wcwidth values if
necessary.  For example, we could provide a new request `.charwidth'
which has the same syntax as `.cflags'.  Values for `.charwidth' are
then only taken into account if a new `charwidth' keyword is present
in the DESC file.  However, I don't consider that as essential, and I
will release 1.21 without this yet-to-be-written stuff.

Another minor thing which isn't urgent: I think that the (current)
contents of ja.tmac is essentially universal, not restricted to
Japanese.  For speed considerations it is OK that character classes
are not part of standard calls to groff, however, what about moving
them to a file `cjk.tmac' which then gets included by ja.tmac,
kr.tmac, etc.?


    Werner