Element->Font Info
Encoding
tabNumber of Characters
field by one (probably to
257
)OK
Element->Character Info
Unicode Name
field (in this case
you'd type in dotlessi
)Set From Name
buttonOK
Element->Font Info
Encoding
tabEncoding
to ISO-10646-1 (Unicode)
OK
View->Goto
dotlessi
OK
Element->Font Info
againEncoding
back to whatever it was
The PostScript used in OpenType is slightly different from that used in .pfa and .pfb files. pfa/b files are Type1 fonts while OpenType uses Type2 fonts. Type2 is almost a superset of Type1 with a few minor changes and many extensions. Adobe's extensions to Type1 (flex hints, hint substitution, counter hints) by using subroutines have been added to Type2 as direct instructions.
In a half-hearted attempt to get around this problem I have caused PfaEdit to generate characters with names "mu", "uni00B5" and "uni03BC" whenever either U+00B5 or U+03BC is defined (and similarly for Omega and Delta).
When postscript was invented every character in a font was given a name, and an encoding which was specified by a 256 element array mapping character codes to names.
Then they started thinking about CJK fonts (and perhaps Unicode), which have huge character sets, and coming up with reasonable ASCII names for 10,000 characters was a) a waste of space, b) fairly meaningless. So then adobe created CID-keyed fonts which have no character names and no encodings. Every character has an index (a CID), which is just a number, and this is sort of treated as a name. Then external to the font is another resource (a cmap) which provides the encoding for the font (and can support really grungy encoding schemes like SJIS), by mapping a sequence of input bytes to a CID.
Adobe provides certain standard cmap resources (ie. one for SJIS, one for JIS, one for Extended Unix whatever). Because these files are fairly painful to write Adobe has assigned standard meanings to CIDs so that everyone can use the same cmap file. -- Well actually there are 5 or 6 different standards, Japanese (JIS208), Japanese (JIS212), Korean, Chinese (Hong Kong, Taiwan), Chinese (Mainland, Singapore), Identity (Unicode) -- So CID 1 might be space, CID 2 might be "!", CID 935 might be "Katakana ka", etc.
So my cidmap files just give me a mapping between Adobe's CIDs and Unicode. So that PfaEdit will know what character it is working on. If they aren't present things should work ok, but PfaEdit would fill the font view with "?" rather than the appropriate character. And PfaEdit wouldn't be able to reencode the font into Unicode or anything else.
So the cidmap files are only useful for people working on CID keyed CJK fonts. So most europeans/americans won't need them.
Essentially you designate one (or several) directories as a "font directory". You move your fonts to that directory. You build up certain data structures that X needs, and you tell X to include this directory in your font path. Sadly different versions of X and the X font server use slightly different conventions. You may need to alter these procedures a bit.
For example, if you want to install a bdf font called frabnuts-13.bdf then you might:
$ mkdir my_fonts $ mv frabnuts-13.bdf my_fonts $ cd my_fonts $ bdftopcf frabnuts-13.bdf >frabnuts-13.pcf $ mkfontdir $ xset fp+ `pwd`
and your fonts should be installed. After that, whenever you start X you
need to remind it of where your fonts live, so you should add
$ xset fp+ /home/me/my_fonts
to your .xsession (or equivalent).
If you want to install postscript fonts
You should generate them as postscript binary (.pfb) files, then move both
the .pfb and the .afm file into (one of) your font directory(ies) and run
type1inst
in it.
type1inst will probably complain that your font doesn't have a foundry and
will probably get the encoding wrong. You can either:
If you want to install truetype fonts
You move the .ttf file into your font directory and run mkttfdir and
mkfontdir.
(mkttfdir
has a small problem with fonts created by PfaEdit, it will almost invariably
complain that it doesn't recognize the foundry. You can safely ignore this,
but if it bothers you then add a line to ttmkfdir.c at 936
{ "PFED", "PfaEdit" },
Some versions of X (ie, those shipped by redhat) rely on the x font server
to do font work rather than the X server itself. You may want to use chkfontpath
to add your new directory to the font server's font path (rather than xset
fp).
You may also need to insure that the font directory (and all its parent
directories) are readable to world. (the font server runs as a non-priviledged
user)
I haven't seen anything that says X supports opentype fonts yet, but since freetype does (and I think X's rasterizer uses freetype) then X might support them too. Installing them will require manual editing of fonts.scale though (mkttfdir uses freetype1 which doesn't support otf files).
That sounds really confusing. I appologize, I'm not a good writer and there are too many choices in configuring X...
/Mac OS X/Library/Fonts/
), in the System/Library/Fonts
directory, or in the user's appropriate fonts sub-directory
(~/Library/Fonts
).
Caveat: I do not understand how to generate a font that
handles 2 byte encodings on the mac. All the docs I've read seem to imply
a 1 byte limitation. So all of these fonts will have a FOND that only knows
about the first 256 characters.
Caveat: A postscript font is useless on a macintosh unless
it is acompanied by at least one bitmap font. If you generate a postscript
font make sure you also generate an NFNT as well (this has the FOND).
Caveat: The mac is picky about the filename used to contain
a postscript file. It is based on the postscript font name but suffers a
transformation. Don't try to rename this file. Basically the rules are (see
Adobe
Technical Note 0091):
This will replace a set of splines with a spline that differs from the original by no more than .1 unit.