On 5/19/05, Werner LEMBERG <[EMAIL PROTECTED]> 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 _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
