Re: [Groff] Re: unicode support, part 14: unicode fonts

[Colin Watson]

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                                       address@hidden