> I got the font working, although I do not completely understand what
> is going on internally.
Please don't hesitate to ask! Ideally, you could then improve the
documentation based on your questions :-)
> In addition, the CMCyr package, which I registered with Groff, is
> only an extension to the Computer Modern fonts having only
> Russian-specific symbols, and it needs to be combined with the basic
> CM fonts before it can be used with Groff, which I don't know how to
> do yet.
Well, the cmcyr package uses the virtual font mechanism of TeX to
combine cm with cmcyr, something not available in groff. However,
groff supports a fallback font mechanism instead. For example,
groff's `TI' font (for devdvi) is `cmti10'. Let's assume that `CTI'
is the Cyrillic complementary font `cmcti10', then you can write
.fspecial TI CTI
and groff accesses CTI for glyphs not found in TI (before any other
special fonts).
> In this connection, does anybody know of a tool for merging Type-1
> fonts, with non-intersecting glyph sets, of course?
I think you can do that with fontforge, using its scripting
capabilities. However, it's best to ask this on the fontforge mailing
list.
> I got a question about groff's handling of UTF-8 input.
> GROFF_CHAR(7) says:
>
> On ASCII platforms, input character codes in the range 0 to 127
> (decimal) represent the usual 7-bit ASCII characters, while
> codes between 127 and 255 are interpreted as the corresponding
> characters in the latin1 (ISO-8859-1) code set by default. This
> mapping is contained in the file latin1.tmac and can be changed
> by loading a different input encoding.
>
> As I understand, the -KUTF-8 option causes the input UTF-8-encoded
> file to be converted into 8-bit.
No. It converts the input into GGL entities. It completely avoids
character codes larger than 0x7E.
> GROFF_FONT(5) says this about glyph-definition lines in font files:
>
> The code field gives the code which the postprocessor uses to
> print the glyph.
> [...]
> The entity_name field gives an ASCII string identifying the
> glyph which the postprocessor uses to print that glyph. This
> field is optional and is currently used by grops to build
> subencoding arrays for PS fonts containing more than 256
> glyphs...
>
> Is this part obsolete, particularly -- the lines about grops using
> glyph names _only_ when dealing with fonts with more than 256
> characters? Said CMCyr fonts have only 66 characters yet seem to be
> accessed by glyph name...
Internally, groff uses a default encoding vector for Type 1 fonts (in
file `text.enc') which gets accessed by indices. Glyphs not part of
this encoding must be accessed with a different encoding vector (all
such encoding vectors are `subencoding arrays'). However, this is
completely unimportant for the user! If possible, always use glyph
names and nothing else. \N'...' is really only for emergency cases.
> According to the manual, GGL is a fixed set of glyphs, and I didn't
> find glyphs for Russian letters among them (in groff_char.7).
Correct.
> Conversely, the glyphs for Russian letters seem to be calculated
> algorithmically:
Correct. For example, the glyph with the AGL name `afii10065'
(Cyrillic small letter a) is called `u0430' in groff.
Werner
