On Wed, Aug 09, 2006 at 10:03:56AM +0200, Werner LEMBERG wrote: > Colin Watson wrote: > > FWIW, I've been (rightly) under pressure for a while to update > > Debian's groff, but have found it very difficult to forward-port the > > notorious Debian Japanese patch; > > Forward-porting this patch is not useful, I think. If you really want > to spend more time please implement glyph class support as mentioned > on this list a longer time ago so that we can easily add glyph > properties for whole ranges.
For Unicode fonts (which ought to be increasingly the norm), the proposal to write out all glyph properties in the font file seems odd; as far as I understand the point of Bruno's Unicode fonts versus enumerated fonts is to avoid the need to write out properties in font files which are really properties of the Unicode code points. Can these properties not be autogenerated from UnicodeData.txt (and others, e.g. EastAsianWidth.txt) and used automatically for all Unicode fonts? Glyph classes would then be useful for efficient internal storage, but there would be no urgent need to represent them in the font files. > What about creating a new package, say, groff-jp, which provides an > older version of groff together with the Japanese patch? `man' could > then call groff-jp to format Japanese man pages, and a more recent > version of groff for everything else. This is possible (there used to be a jgroff package), but it's a fairly significant amount of unrewarding packaging work and I'd prefer to avoid it if possible. Furthermore it would either bloat the base system with both groff and jgroff or require all Japanese users to know (or be told) to install jgroff. Neither is particularly clean. It feels like groff is quite close to being able to render CJK reasonably well - the major omissions seem to be width handling and kinsoku shori (is that an accurate assessment?) - and, if I can jump forward to that with at most a few temporary hacks, then from my perspective that's far preferable to the large hack of a whole new groff package. (In addition, the Debian patches also create an "ascii8" device, which is a curious little hack that effectively passes through characters encoded according to the current locale - so if the input to ascii8 is ISO-8859-2, then you get ISO-8859-2 output. At present, man uses this device for Czech, Croatian, Hungarian, Polish, Russian, Slovak, and Turkish. Obviously this device is typographically dubious at best, so I'll replace it by use of preconv/soelim/whatever and an iconv postprocessing step; latin2.tmac and latin5.tmac would work as well but those appear to be largely superseded by preconv.) -- Colin Watson [EMAIL PROTECTED] _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
