[Top][All Lists]

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

Re: fontdefs files

From: Valeriy E. Ushakov
Subject: Re: fontdefs files
Date: Tue, 21 Dec 1999 01:31:09 +0300

On Mon, Dec 20, 1999 at 11:32:00AM -1000, Robert Valliant wrote:

> 1. Spacing - is the spacing (16, 16, 30, 16, 16, 9) in the fontdefs
>    file critical?

No.  Lout just looks for two words after the "fotdef" keyword and a
sequence of 4 words inside the curlies.  You can use wahtever spacing
you like, including splitting the "fontdef" on multiple lines.

> 2. Can there be spaces in family or face names? According to DSC 3,
>    there can be no spaces in font names. But what about lout family
>    and face names? I chose to remove the spaces.

I'm not sure (and too lasy to verify it ;), but my educated guess is
that you can simply enclose the name into quotes if it's so important
to keep the spaces in the name (though I can't think of any reason for

> 3. Does lout look for any particular face names? Several I found
>    include normal, normalitalic, thin, medium, etc.

Standard Lout *packages* standardize on few names.  E.g. @I expects
that there's a "Slope" face, and @B expects there's "Bold".  Lout
itself, the engine, doesn't care.

> 4. About recoding. I had the program scan the .afm file and examine
>    the 'C nnn' entries. If it found anything over 128, it set "recode".
>    I am not sure if this is correct or not. I note that in the
>    standard fontdefs file, neither symbol nor dingbats is recoded. Yet
>    in the PI and symbol .afms on the Bitstream CD, both have chars
>    above 128. Am I missing something here?

Text fonts are typically recoded because they usually provide a common
character repertoire.  Since Lout (like early PostScript, but unlike
Unicode) doesn't distinguish between character and glyph, you document
your input encoding that will be used with the font in the LCM file
and then simply recode the font to match the input encoding.  E.g. not
a single Cyrillic font that I used had koi8-r as its "native"
encoding.  Recode simply takes care of it.

OTOH, with "symbol" (in the broad sense) fonts you will probably never
input raw codes and will use @Char glyphname instead.  So recoding is
usually not necessary.  The LCM file for a "symbol" font usually just
documents the existing "native" encoding of the font.  You may wish to
recode a "symbol" font if it has glyphs that are inaccessible with
default encoding.

Hope that helps.

SY, Uwe
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen

reply via email to

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