groff
[Top][All Lists]
Advanced

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

Re: [Groff] Installing Russian Type-1 Fonts


From: Werner LEMBERG
Subject: Re: [Groff] Installing Russian Type-1 Fonts
Date: Thu, 18 Aug 2011 23:26:52 +0200 (CEST)

> 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



reply via email to

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