> (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
