[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] grops and Unicode, Unicode in general.

From: Alejandro López-Valencia
Subject: Re: [Groff] grops and Unicode, Unicode in general.
Date: Fri, 20 May 2005 07:15:27 -0500

On 5/19/05, Werner LEMBERG <address@hidden> wrote:
> > > Volunteers, volunteers!  I'm swamped with other work.
> >
> > And which approach do you like best? The one you initially proposed
> > -- having internal Char type or going in wchar_t-transparent
> > direction (we would get multibyte input as a bonus)?  The latter
> > seems to me a better approach (judged by standards :), but I'm not
> > sure about portability issues that may arise (there may still be
> > platforms out there that still do not have wide characters).
> I still vote for not using wchar_t.  groff is often used to replace
> old troff installations on old OS versions, and wchar support on such
> platforms is regularly broken.
> > > They aren't stable yet.  The developer has started to play with
> > > fontforge and changed some metrics so that URW is no longer
> > > compatible (w.r.t. metrics) with the standard PS fonts.
> >
> > Hmm. Perhaps, some old release without these issues could be chosen?
> > These fonts were quite good looking from the very beginning (for my
> > non-professional eye :).
> But the older (good) fonts directly produced by URW don't have
> Cyrillic glyphs...  Can you investigate the state of those fonts,
> probably by contacting the author(s) or the ghostscript people, and
> checking the ghostscript bugs page?  Maybe they've meanwhile released
> a new version which fixes those problems.

No, they haven't. In fact, the Aladdin people decided to include the
botched versions in GS 8.x, which was a very dumb thing to do. *Sigh*.
The current source for these fonts is CTAN and TeX distributions based
on the CTAN collection, because there are some TeX users that *care*
about fonts.

Wartan guesses correctly that the best way would be to start from the
original URW++ fonts and add the Cyrillic glyphs to them, but with
some caveats:

1. The addition *must* be done by hand to guarantee that the outline,
hint and subroutine programs are not damaged by a graphical font
editor (believe me, *all* graphical editing be it with a high end tool
(Fontlab, Asia Font Studio, Ikarus or DTL FontMaster), or with a
half-baked tool such as Fontforge *will* destroy the original digital
font program) and each iteration will have lower quality. Postscript
hand editing is not that difficult and it has been done before (e.g.,
when Tom Kacvinsky[1] was at the AMS he corrected most of the hinting
and metrics problems with the AMS Math fonts by hand; I'm not sure if
that work was  published ever).

2. The fonts must have different names. This is one case where it is
clear that a font should not be licensed under the GPL, because a
person can come in and destroy it by forking without renaming it
first. A forced rename license such as the one used on the Bitstream
Vera fonts (the default desktop fonts used in recent GNU Gnome 2.x
distributions) is a more appropriate solution.

3. You don't need to have all glyphs in single font container!!! I
guess most people think that X has the same limitations of MS Windows
and MacOS with fonts. Well... No. X is very happy to use virtual
fontsets, so you can place your Cyrillic glyphs in physically
different containers that appear as one to the graphics display
engine; in fact, that's how CID fonts work, sort of. And you can
recode them on-the-fly so that the glyphs are delivered as Unicode
characters to the client applications. The same goes for groff. 
Therefore you could use the original URW++ fonts untouched and add the
Cyrillic glyphs from different physical sources. You could lose the
ability to search eventual PDF output but only if you don't take care
to recode the data stream to some Unicode encoding recognized by the
PDF spec before creating such output.

[1] Personal communication.
Alejandro López-Valencia

reply via email to

[Prev in Thread] Current Thread [Next in Thread]