aboutsummaryrefslogtreecommitdiff
path: root/nx-X11/extras/ttf2pt1/README.html
diff options
context:
space:
mode:
Diffstat (limited to 'nx-X11/extras/ttf2pt1/README.html')
-rw-r--r--nx-X11/extras/ttf2pt1/README.html1182
1 files changed, 0 insertions, 1182 deletions
diff --git a/nx-X11/extras/ttf2pt1/README.html b/nx-X11/extras/ttf2pt1/README.html
deleted file mode 100644
index b1d6c9c22..000000000
--- a/nx-X11/extras/ttf2pt1/README.html
+++ /dev/null
@@ -1,1182 +0,0 @@
-<HTML>
-<HEAD>
-<TITLE>
-TTF2PT1 - A True Type to PostScript Type 1 Converter
-</TITLE>
-</HEAD>
-<BODY>
-<!-- =defdoc t1 ttf2pt1 1 -->
-<H2>
-<!-- =section t1 NAME -->
-TTF2PT1 - A True Type to PostScript Type 1 Font Converter
-<!-- =stop -->
-</H2>
-
-<!
-(Do not edit this file, it is generated from README.html!!!)
->
-<TT>
-[
-<blockquote>
-<!-- =section t1 HISTORY -->
- Based on ttf2pfa by Andrew Weeks, and help from Frank Siegert.
-<BR>
- Modification by Mark Heath.
-<BR>
- Further modification by Sergey Babkin.
-<BR>
- The Type1 assembler by I. Lee Hetherington with modifications by
- Kai-Uwe Herbing.
-<!-- =stop -->
-</blockquote>
-]
-</TT>
-<p>
-
-Ever wanted to install a particular font on your XServer but only could find
-the font you are after in True Type Format?
-<p>
-
-Ever asked <TT>comp.fonts</TT> for a True Type to Type 1 converter and got a List
-of Commercial software that doesn't run on your Operating System?
-<p>
-
-Well, this program should be the answer. This program is written in C (so it
-should be portable) and therefore should run on any OS. The only limitation
-is that the program requires some method of converting Big endian integers into
-local host integers so the network functions ntohs and ntohl are used. These
-can be replaced by macros if your platform doesn't have them.
-Of course the target platform requires a C compiler and command line ability.
-<p>
-
-<!-- =section t1 DESCRIPTION -->
-Ttf2pt1 is a font converter from the True Type format (and some other formats
-supported by the FreeType library as well) to the Adobe Type1 format.
-<p>
-
-The versions 3.0 and later got rather extensive post-processing algorithm that
-brings the converted fonts to the requirements of the Type1 standard, tries to
-correct the rounding errors introduced during conversions and some simple
-kinds of bugs that are typical for the public domain TTF fonts. It
-also generates the hints that enable much better rendering of fonts in
-small sizes that are typical for the computer displays. But everything
-has its price, and some of the optimizations may not work well for certain
-fonts. That's why the options were added to the converter, to control
-the performed optimizations.
-<p>
-<!-- =stop -->
-
-The converter is simple to run, just:
-<p>
-
-<!-- =section t1 SYNOPSIS -->
-<blockquote>
- <tt>ttf2pt1 <i>[-options] ttffont.ttf [Fontname]</i></tt>
-</blockquote>
-or
-<blockquote>
- <tt>ttf2pt1 <i>[-options] ttffont.ttf -</i></tt>
-</blockquote>
-<!-- =stop -->
-<p>
-
-<!-- =section t1 OPTIONS -->
-The first variant creates the file <tt>Fontname.pfa</tt> (or <tt>Fontname.pfb</tt> if the
-option '<b>-b</b>' was used) with the converted font and <tt>Fontname.afm</tt> with the
-font metrics, the second one prints the font or another file (if the option
-'<b>-G</b>' was used) on the standard output from where it can be immediately
-piped through some filter. If no <tt>Fontname</tt> is specified for the first
-variant, the name is generated from <tt>ttffont</tt> by replacing the <tt>.ttf</tt>
-filename suffix.
-<p>
-
-Most of the time no options are neccessary (with a possible exception
-of '<b>-e</b>'). But if there are some troubles with the resulting font, they
-may be used to control the conversion.
-The <B>options</B> are:
-<p>
-
-<!-- ==over 2 -->
-<!-- ==item * -->
-<TT><B>-a</TT></B> - Include all the glyphs from the source file into the converted
- file. If this option is not specified then only the glyphs that have
- been assigned some encoding are included, because the rest of glyphs
- would be inaccessible anyway and would only consume the disk space.
- But some applications are clever enough to change the encoding on
- the fly and thus use the other glyphs, in this case they could
- benefit from using this option. But there is a catch: the X11 library
- has rather low limit for the font size. Including more glyphs increases
- the file size and thus increases the chance of hitting this limit.
- See <A HREF="app/X11/README.html"><tt>app/X11/README</tt></A> for the description of a
- patch to X11 which fixes this problem.
-<p>
-
-<!-- ==item * -->
-<TT><B>-b</TT></B> - Encode the resulting font to produce a ready <tt>.pfb</tt> file.
-<p>
-
-<!-- ==item * -->
-<TT><B>-d <i>suboptions</i></TT></B> - Debugging options. The suboptions are:
-<p>
-
-<blockquote>
- <TT><B>a</TT></B> - Print out the absolute coordinates of dots in outlines. Such
- a font can not be used by any program (that's why this option is
- incompatible with '<b>-e</b>') but it has proven to be a valuable debuging
- information.
-<p>
-
- <TT><B>r</TT></B> - Do not reverse the direction of outlines. The TTF fonts have
- the standard direction of outlines opposite to the Type1 fonts. So
- they should be reversed during proper conversion. This option
- may be used for debugging or to handle a TTF font with wrong
- direction of outlines (possibly, converted in a broken way from
- a Type1 font). The first signs of the wrong direction are the
- letters like "P" or "B" without the unpainted "holes" inside.
-<p>
-</blockquote>
-
-<!-- ==item * -->
-<TT><B>-e</TT></B> - Assemble the resulting font to produce a ready <tt>.pfa</tt> file.
-<I>
- [ </I>S.B.<I>: Personally I don't think that this option is particularly useful.
- The same result may be achieved by piping the unassembled data
- through t1asm, the Type 1 assembler. And, anyways, it's good to
- have the t1utils package handy. But Mark and many users think that
- this functionality is good and it took not much time to add this option. ]
-</I>
-<p>
-
-<!-- ==item * -->
-<TT><B>-F</TT></B> - Force the Unicode encoding: any type of MS encoding specified
- in the font is ignored and the font is treated like it has Unicode
- encoding. <B>WARNING:</B> <I>this option is intended for buggy fonts
- which actually are in Unicode but are marked as something else. The
- effect on the other fonts is unpredictable.</I>
-<p>
-
-<!-- ==item * -->
-<TT><B>-G <i>suboptions</i></TT></B> - File generation options. The suboptions may be lowercase
- or uppercase, the lowercase ones disable the generation of particular
- files, the corresponding uppercase suboptions enable the generation of the
- same kind of files. If the result of ttf2pt1 is requested to be printed on
- the standard output, the last enabling suboption of <b>-G</b> determines
- which file will be written to the standard output and the rest of files
- will be discarded. For example, <b>-G A</b> will request the AFM file.
- The suboptions to disable/enable the generation of the files are:
-<p>
-
-<blockquote>
- <TT><B>f/F</TT></B> - The font file. Depending on the other options this file
- will have one of the suffixes <tt>.t1a</tt>, <tt>.pfa</tt> or <tt>.pfb</tt>. If the conversion result
- is requested on the standard output ('<tt>-</tt>' is used as the output file name)
- then the font file will also be written there by default, if not overwritten
- by another suboption of <b>-G</b>.
- <b>Default: enabled</b>
-<p>
-
- <TT><B>a/A</TT></B> - The Adobe font metrics file (<tt>.afm</tt>).
- <b>Default: enabled</b>
-<p>
-
- <TT><B>e/E</TT></B> - The dvips encoding file (<tt>.enc</tt>).
- <b>Default: disabled</b>
-<p>
-
-</blockquote>
-
-<!-- ==item * -->
-<TT><B>-l <I>language</I>[+<I>argument</I>]</TT></B> - Extract the fonts for the specified language from a
- multi-language Unicode font. If this option is not used the converter
- tries to guess the language by the values of the shell variable LANG.
- If it is not able to guess the language by LANG it tries all the
- languages in the order they are listed.
-<p>
-
- After the plus sign an optional argument for the language extractor
- may be specified. The format of the argument is absolutely up to
- the particular language converter. The primary purpose of the
- argument is to support selection of planes for the multi-plane
- Eastern encodings but it can also be used in any other way. The
- language extractor may decide to add the plane name in some form
- to the name of the resulting font. None of the currently supported
- languages make any use of the argument yet.
-<p>
-
- As of now the following languages are supported:
-<br>
- &nbsp;&nbsp;<TT>latin1</TT> - for all the languages using the Latin-1 encoding
-<br>
- &nbsp;&nbsp;<TT>latin2</TT> - for the Central European languages
-<br>
- &nbsp;&nbsp;<TT>latin4</TT> - for the Baltic languages
-<br>
- &nbsp;&nbsp;<TT>latin5</TT> - for the Turkish language
-<br>
- &nbsp;&nbsp;<TT>cyrillic</TT> - for the languages with Cyrillic alphabet
-<br>
- &nbsp;&nbsp;<TT>russian</TT> - historic synonym for cyrillic
-<br>
- &nbsp;&nbsp;<TT>bulgarian</TT> - historic synonym for cyrillic
-<br>
- &nbsp;&nbsp;<TT>adobestd</TT> - for the AdobeStandard encoding used by TeX
-<br>
- &nbsp;&nbsp;<TT>plane+<i>argument</i></TT> - to select one plane from a multi-byte encoding
-<p>
-
- The argument of the "<tt>plane</tt>" language may be in one of three forms:
-<p>
- &nbsp;&nbsp;<tt>plane+<b>pid=</b><i>&lt;pid&gt;</i><b>,eid=</b><i>&lt;eid&gt;</i></tt>
-<br>
- &nbsp;&nbsp;<tt>plane+<b>pid=</b><i>&lt;pid&gt;</i><b>,eid=</b><i>&lt;eid&gt;</i><b>,</b><i>&lt;plane_number&gt;</i></tt>
-<br>
- &nbsp;&nbsp;<tt>plane+<i>&lt;plane_number&gt;</i></tt>
-<p>
-
- Pid (TTF platform id) and eid (TTF encoding id) select a particular
- TTF encoding table in the original font. They are specified as decimal
- numbers. If this particular encoding table is not present in the font
- file then the conversion fails. The native ("ttf") front-end parser supports
- only pid=3 (Windows platform), the FreeType-based ("ft") front-end supports
- any platform. If pid/eid is not specified then the TTF encoding table is
- determined as usual: Unicode encoding if it's first or an 8-bit encoding
- if not (and for an 8-bit encoding the plane number is silently ignored).
- To prevent the converter from falling back to an 8-bit encoding, specify
- the Unicode pid/eid value explicitly.
-<p>
-
- Plane_number is a hexadecimal (if starts with "<b>0x</b>") or decimal number.
- It gives the values of upper bytes for which 256 characters will be
- selected. If not specified, defaults to 0. It is also used as a font
- name suffix (the leading "0x" is not included into the suffix).
-<p>
-
-<!-- =stop -->
- <B>NOTE:</B>
-<!-- =section t1 BUGS -->
- It seems that many Eastern fonts use features of the TTF format that are
- not supported by the ttf2pt1's built-in front-end parser. Because of
- this for now we recommend using the FreeType-based parser (option
- '<b>-p ft</b>') with the "<tt>plane</tt>" language.
-<p>
-<!-- =stop -->
-
-<!-- =section t1 OPTIONS -->
-<I>
- <B>NOTE:</B>
- You may notice that the language names are not uniform: some are the
- names of particular languages and some are names of encodings. This
- is because of the different approaches. The original idea was to
- implement a conversion from Unicode to the appropriate Windows
- encoding for a given language. And then use the translation tables
- to generate the fonts in whatever final encodings are needed. This
- would allow to pile together the Unicode fonts and the non-Unicode
- Windows fonts for that language and let the program to sort them out
- automatically. And then generate fonts in all the possible encodings
- for that language. An example of this approach is the Russian language
- support. But if there is no multiplicity of encodings used for some
- languages and if the non-Unicode fonts are not considered important
- by the users, another way would be simpler to implement: just provide
- only one table for extraction of the target encoding from Unicode
- and don't bother with the translation tables. The </I>latin*<I> "languages"
- are examples of this approach. If somebody feels that he needs the
- Type1 fonts both in Latin-* and Windows encodings he or she is absolutely
- welcome to submit the code to implement it.
-</I><p>
-
- <B>WARNING:</B>
- Some of the glyphs included into the AdobeStandard encoding are not
- included into the Unicode standard. The most typical examples of such
- glyphs are ligatures like 'fi', 'fl' etc. Because of this the font
- designers may place them at various places. The converter tries to
- do its best, if the glyphs have honest Adobe names and/or are
- placed at the same codes as in the Microsoft fonts they will be
- picked up. Otherwise a possible solution is to use the option '<b>-L</b>'
- with an external map.
-<p>
-
-<!-- ==item * -->
-<TT><B>-L <I>file</I>[+[pid=<I>&lt;pid&gt;</I>,eid=<I>&lt;eid&gt;</I>,][<I>plane</I>]]</TT></B> - Extract the fonts for the specified
- language from a multi-language font using the map from this file. This is
- rather like the option '<b>-l</b>' but the encoding map is not
- compiled into the program, it's taken from that file, so it's
- easy to edit. Examples of such files are provided in
- <tt>maps/adobe-standard-encoding.map</tt>, <tt>CP1250.map</tt>. (<b>NOTE:</b>
- <I>the 'standard encoding' map does not include all the glyphs of the
- AdobeStandard encoding, it's provided only as an example</I>.) The
- description of the supported map formats is in the file
- <tt>maps/unicode-sample.map</tt>.
-<p>
-
- Likewise to '<b>-l</b>', an argument may be specified after the map file
- name. But in this case the argument has fixed meaning: it selects the
- original TTF encoding table (the syntax is the same as in '<b>-l plane</b>')
- and/or a plane of the map file. The plane name also gets added after dash
- to the font name. The plane is a concept used in the Eastern fonts with big
- number of glyphs: one TTF font gets divided into multiple Type1 fonts,
- each containing one plane of up to 256 glyphs. But with a little
- creativity this concept may be used for other purposes of combining
- multiple translation maps into one file. To extract multiple planes
- from a TTF font <tt>ttf2pt1</tt> must be run multiple times, each time with
- a different plane name specified.
-<p>
-
- The default original TTF encoding table used for the option '<b>-L</b>' is
- Unicode. The map files may include directives to specify different original
- TTF encodings. However if the pid/eid pair is specified with
- it overrides any original encoding specified in the map file.
-<p>
-
-<!-- ==item * -->
-<TT><B>-m <i>type</i>=<i>value</i></TT></B> - Set maximal or minimal limits of resources.
- These limits control the the font generation by limiting the resources
- that the font is permitted to require from the PostScript interpreter.
- The currently supported types of limits are:
-<p>
-
-<blockquote>
- <TT><B>h</TT></B> - the maximal hint stack depth for the substituted hints.
- The default value is 128, according to the limitation in X11. This seems to
- be the lowest (and thus the safest) widespread value. To display the
- hint stack depth required by each glyph in a <tt>.t1a</tt> file use the script
- <tt>scripts/cntstems.pl</tt>.
-<p>
-</blockquote>
-
-<!-- ==item * -->
-<TT><B>-O <i>suboptions</i></TT></B> - Outline processing options. The suboptions
- may be lowercase or uppercase, the lowercase ones disable the features,
- the corresponding uppercase suboptions enable the same features.
- The suboptions to disable/enable features are:
-<p>
-
-<blockquote>
- <TT><B>b/B</TT></B> - Guessing of the ForceBold parameter. This parameter helps
- the Type1 engine to rasterize the bold fonts properly at small sizes.
- But the algorithm used to guess the proper value of this flag makes
- that guess based solely on the font name. In rare cases that may cause
- errors, in these cases you may want to disable this guessing.
- <b>Default: enabled</b>
-<p>
-
- <TT><B>h/H</TT></B> - Autogeneration of hints. The really complex outlines
- may confuse the algorithm, so theoretically it may be useful
- sometimes to disable them. Although up to now it seems that
- even bad hints are better than no hints at all.
- <b>Default: enabled</b>
-<p>
-
- <TT><B>u/U</TT></B> - Hint substitution. Hint substitution is a technique
- permitting generation of more detailed hints for the rasterizer. It allows
- to use different sets of hints for different parts of a glyph and change
- these sets as neccessary during rasterization (that's why "substituted").
- So it should improve the quality of the fonts rendered at small sizes.
- But there are two catches: First, the X11 library has rather low limit for
- the font size. More detailed hints increase the file size and thus increase
- the chance of hitting this limit (that does not mean that you shall hit it
- but you may if your fonts are particularly big). This is especially
- probable for Unicode fonts converted with option '<b>-a</b>', so you may want to
- use '<b>-a</b>' together with '<b>-Ou</b>'. See <A HREF="app/X11/README.html"><tt>app/X11/README</tt></A> for the description of
- a patch to X11 which fixes this problem. Second, some rasterizers (again,
- X11 is the typical example) have a limitation for total number of hints
- used when drawing a glyph (also known as the hint stack depth). If that
- stack overflows the glyph is ignored. Starting from version 3.22 <tt>ttf2pt1</tt>
- uses algorithms to minimizing this depth, with the trade-off of slightly
- bigger font files. The glyphs which still exceed the limit set by option
- '<b>-mh</b>' have all the substituted hints removed and only base hints left.
- The algorithms seem to have been refined far enough to make the fonts with
- substituted hints look better than the fonts without them or at least the
- same. Still if the original fonts are not well-designed the detailed
- hinting may emphasize the defects of the design, such as non-even thickness
- of lines. So provided that you are not afraid of the X11 bug the best idea
- would be to generate a font with this feature and without it, then compare
- the results using the program <tt>other/cmpf</tt> (see the description
- in <A HREF="other/README.html"><tt>other/README</tt></A>) and decide which one looks better.
- <b>Default: enabled</b>
-<p>
-
- <TT><B>o/O</TT></B> - Space optimization of the outlines' code. This kind of optimization
- never hurts, and the only reason to disable this feature is for comparison
- of the generated fonts with the fonts generated by the previous versions of
- converter. Well, it _almost_ never hurts. As it turned out there exist
- some brain-damaged printers which don't understand it. Actually this
- feature does not change the outlines at all. The Type 1 font manual
- provides a set of redundant operators that make font description shorter,
- such as '10 hlineto' instead of '0 10 rlineto' to describe a horizontal
- line. This feature enables use of these operators.
- <b>Default: enabled</b>
-<p>
-
- <TT><B>s/S</TT></B> - Smoothing of outlines. If the font is broken in some
- way (even the ones that are not easily noticeable), such smoothing
- may break it further. So disabling this feature is the first thing to be
- tried if some font looks odd. But with smoothing off the hint generation
- algorithms may not work properly too.
- <b>Default: enabled</b>
-<p>
-
- <TT><B>t/T</TT></B> - Auto-scaling to the 1000x1000 Type1 standard matrix. The
- TTF fonts are described in terms of an arbitrary matrix up to
- 4000x4000. The converted fonts must be scaled to conform to
- the Type1 standard. But the scaling introduces additional rounding
- errors, so it may be curious sometimes to look at the font in its
- original scale.
- <b>Default: enabled</b>
-<p>
-
- <TT><B>v/V</TT></B> - Do vectorization on the bitmap fonts. Functionally
- "vectorization" is the same thing as "autotracing", a different word is
- used purely to differentiate it from the Autotrace library. It tries to
- produce nice smooth outlines from bitmaps. This feature is still a work
- in progress though the results are already mostly decent.
- <b>Default: disabled</b>
-<p>
-
- <TT><B>w/W</TT></B> - Glyphs' width corection. This option is designed to be
- used on broken fonts which specify too narrow widths for the
- letters. You can tell that a font can benefit from this option
- if you see that the characters are smashed together without
- any whitespace between them. This option causes the converter
- to set the character widths to the actual width of this character
- plus the width of a typical vertical stem. But on the other hand
- the well-designed fonts may have characters that look better if
- their widths are set slightly narrower. Such well-designed fonts
- will benefit from disabling this feature. You may want to convert
- a font with and without this feature, compare the results and
- select the better one. This feature may be used only on proportional
- fonts, it has no effect on the fixed-width fonts.
- <b>Default: disabled</b>
-<p>
-
- <TT><B>z/Z</TT></B> - Use the Autotrace library on the bitmap fonts. The results
- are horrible and <b>the use of this option is not recommended</b>. This option is
- present for experimental purposes. It may change or be removed in the
- future. The working tracing can be achieved with option <tt><b>-OV</b></tt>.
- <b>Default: disabled</b>
-<p>
-</blockquote>
-
-<!-- ==item * -->
-<TT><B>-p <I>parser_name</I></TT></B> - Use the specified front-end parser to read the font file.
- If this option is not used, ttf2pt1 selects the parser automatically based
- on the suffix of the font file name, it uses the first parser in its
- list that supports this font type. Now two parsers are supported:
-<p>
-
- &nbsp;&nbsp;<TT>ttf</TT> - built-in parser for the ttf files (suffix <tt>.ttf</tt>)
-<br>
- &nbsp;&nbsp;<TT>bdf</TT> - built-in parser for the BDF files (suffix <tt>.bdf</tt>)
-<br>
- &nbsp;&nbsp;<TT>ft</TT> - parser based on the FreeType-2 library (suffixes <tt>.ttf</tt>,
- <tt>.otf</tt>, <tt>.pfa</tt>, <tt>.pfb</tt>)
-<p>
-
- The parser <tt>ft</tt> is <b>NOT</b> linked in by default. See <tt>Makefile</tt>
- for instructions how to enable it. We do no support this parser on
- Windows: probably it will work but nobody tried and nobody knows how
- to build it.
-<p>
-
- The conversion of the bitmap fonts (such as BDF) is simplistic yet,
- producing jagged outlines. When converting such fonts, it might be
- a good idea to turn off the hint substitution (using option <b>-Ou</b>)
- because the hints produced will be huge but not adding much to the
- quality of the fonts.
-<p>
-
-<!-- ==item * -->
-<TT><B>-u <I>number</I></TT></B> - Mark the font with this value as its
- UniqueID. The UniqueID is used by the printers with the hard disks
- to cache the rasterized characters and thus significantly
- speed-up the printing. Some of those printers just can't
- store the fonts without UniqueID on their disk.The problem
- is that the ID is supposed to be unique, as it name says. And
- there is no easy way to create a guaranteed unique ID. Adobe specifies
- the range 4000000-4999999 for private IDs but still it's difficult
- to guarantee the uniqueness within it. So if you don't really need the
- UniqueID don't use it, it's optional. Luckily there are a few millions of
- possible IDs, so the chances of collision are rather low.
- If instead of the number a special value '<tt><b>A</b></tt>' is given
- then the converter generates the value of UniqueID automatically,
- as a hash of the font name. (<b>NOTE:</b> <i> in the version 3.22 the
- algorithm for autogeneration of UniqueID was changed to fit the values
- into the Adobe-spacified range. This means that if UniqueIDs were used
- then the printer's cache may need to be flushed before replacing the
- fonts converted by an old version with fonts converted by a newer version</i>).
- A simple way to find if any of the fonts in a given directory have
- duplicated UniqueIDs is to use the command:
-<p>
-
- <tt>&nbsp;&nbsp;cat *.pf[ab] | grep UniqueID | sort | uniq -c | grep -v ' 1 '</tt>
-<p>
-
- Or if you use <tt>scripts/convert</tt> it will do that for you automatically
- plus it will also give the exact list of files with duplicate UIDs.
-<p>
-
-<!-- ==item * -->
-<TT><B>-v <I>size</I></TT></B> - Re-scale the font to get the size of a typical uppercase
- letter somewhere around the specified size. Actually, it re-scales
- the whole font to get the size of one language-dependent letter to be
- at least of the specified size. Now this letter is "A" in all the
- supported languages. The size is specified in the points of the
- Type 1 coordinate grids, the maximal value is 1000. This is an
- experimental option and should be used with caution. It tries to
- increase the visible font size for a given point size and thus make
- the font more readable. But if overused it may cause the fonts to
- look out of scale. As of now the interesting values of size for
- this option seem to be located mostly between 600 and 850. This
- re-scaling may be quite useful but needs more experience to
- understand the balance of its effects.
-<p>
-
-<!-- ==item * -->
-<TT><B>-W <i>level</i></TT></B> - Select the verbosity level of the warnings.
- Currently the levels from 0 to 4 are supported. Level 0 means no warnings
- at all, level 4 means all the possible warnings. The default level is 3.
- Other levels may be added in the future, so using the level number 99 is
- recommended to get all the possible warnings. Going below level 2 is
- not generally recommended because you may miss valuable information about
- the problems with the fonts being converted.
-<p>
-
-<!-- ==item * -->
-<B>Obsolete option:</B>
-<TT><B>-A</TT></B> - Print the font metrics (.afm file) instead of the font on STDOUT.
- Use <b>-GA</b> instead.
-<p>
-
-<!-- ==item * -->
-<B>Very obsolete option:</B>
-<br>
- The algorithm that implemented the forced fixed width had major
- flaws, so it was disabled. The code is still in the program and
- some day it will be refined and returned back. Meanwhile the
- option name '<b>-f</b>' was reused for another option. The old version was:
-<br>
-<TT><B>-f</TT></B> - Don't try to force the fixed width of font. Normally the converter
- considers the fonts in which the glyph width deviates by not more
- than 5% as buggy fixed width fonts and forces them to have really
- fixed width. If this is undesirable, it can be disabled by this option.
-<p>
-<!-- ==back -->
-
-The <tt>.pfa</tt> font format supposes that the description of the characters
-is binary encoded and encrypted. This converter does not encode or
-encrypt the data by default, you have to specify the option '<b>-e</b>'
-or use the <tt>t1asm</tt> program to assemble (that means, encode and
-encrypt) the font program. The <tt>t1asm</tt> program that is included with
-the converter is actually a part of the <tt>t1utils</tt> package, rather old
-version of which may be obtained from
-<p>
-
-<blockquote>
-<A HREF="http://ttf2pt1.sourceforge.net/t1utils.tar.gz">
- http://ttf2pt1.sourceforge.net/t1utils.tar.gz
-</A>
-</blockquote>
-<p>
-
-Note that <tt>t1asm</tt> from the old version of that package won't work properly
-with the files generated by <tt>ttf2pt1</tt> version 3.20 and later. Please use
-<tt>t1asm</tt> packaged with <tt>ttf2pt1</tt> or from the new version <tt>t1utils</tt>
-instead. For a newer version of <tt>t1utils</tt> please look at
-<p>
-
-<blockquote>
-<A HREF="http://www.lcdf.org/~eddietwo/type/">
- http://www.lcdf.org/~eddietwo/type/
-</A>
-</blockquote>
-<p>
-<!-- =stop -->
-
-<!-- =section t1 EXAMPLES -->
-So, the following command lines:
-<p>
-
-<blockquote>
- <tt>ttf2pt1 -e ttffont.ttf t1font</tt>
-<br>
- <tt>ttf2pt1 ttffont.ttf - | t1asm &gt;t1font.pfa</tt>
-</blockquote>
-<p>
-
-represent two ways to get a working font. The benefit of the second form
-is that other filters may be applied to the font between the converter
-and assembler.
-<p>
-<!-- =stop -->
-
-<H4>
-Installation and deinstallation of the converter
-</H4>
-<!
-------------------------------------------------
->
-
-The converter may be easily installed systemwide with
-
-<blockquote>
- <tt>make install</tt>
-</blockquote>
-
-and uninstalled with
-
-<blockquote>
- <tt>make uninstall</tt>
-</blockquote>
-
-By default the <tt>Makefile</tt> is configured to install in the hierarchy
-of directory <tt>/usr/local</tt>. This destination directory as well as
-the structure of the hierarchy may be changed by editing the <tt>Makefile</tt>.
-
-<H4>
-Installation of the fonts
-</H4>
-<!
--------------------------
->
-
-Running the converter manually becomes somewhat boring if it has to
-be applied to a few hundreds of fonts and then you have to generate the
-<tt>fonts.scale</tt> and/or <tt>Fontmap</tt> files. The <A HREF="FONTS.html"><tt>FONTS</tt></A> file describes how to use
-the supplied scripts to handle such cases easily. It also discusses
-the installation of the fonts for a few widespread programs.
-<p>
-
-<H4>
-Other utilities
-</H4>
-<!
----------------
->
-
-A few other small interesting programs that allow a cloase look at
-the fonts are located in the subdirectory '<tt>other</tt>'. They
-are described shortly in <A HREF="other/README.html">others/README</a>.
-<p>
-
-<H4>
-Optional packages
-</H4>
-<!
------------------
->
-
-Some auxiliary files are not needed by everyone and are big enough that
-moving them to a separate package speeds up the downloads of the main
-package significantly. As of now we have one such optional package:
-<p>
-
-&nbsp;&nbsp;<b>ttf2pt1-chinese</b> - contains the Chinese conversion maps
-<p>
-
-The general versioning policy for the optional packages is the following:
-These packages may have no direct dependency on the ttf2pt1 version.
-But they may be updated in future, as well as some versions of optional
-packages may have dependencies on certain versions of ttf2pt1.
-To avoid unneccessary extra releases on one hand and keep the updates in
-sync with the ttf2pt1 itself on the other hand, a new version of an optional
-package will be released only if there are any changes to it and it will be
-given the same version number as ttf2pt1 released at the same time. So not
-every release of ttf2pt1 would have a corresponding release of all optional
-packages. For example, to get the correct version of optional packages for an
-imaginary release 8.3.4 of ttf2pt1 you would need to look for optional
-packages of the highest version not higher than (but possibly equal to) 8.3.4.
-<p>
-
-<H4>
-TO DO:
-</H4>
-<!
-------
->
-
-<ul>
-<li> Improve hinting.
-<li> Improve the auto-tracing of bitmaps.
-<li> Implement the family-level hints.
-<li> Add generation of CID-fonts.
-<li> Handle the composite glyphs with relative base points.
-<li> Preserve the relative width of stems during scaling to 1000x1000 matrix.
-<li> Add support for bitmap TTF fonts.
-<li> Implement better support of Asian encodings.
-<li> Implement automatic creation of ligatures.
-</ul>
-
-<H4>
-TROUBLESHOOTING AND BUG REPORTS
-</H4>
-<!
--------------------------------
->
-<!-- =section t1 BUGS -->
-<!-- ==head2 Troubleshooting and bug reports -->
-
-Have problems with conversion of some font ? The converter dumps core ? Or your
-printer refuses to understand the converted fonts ? Or some characters are
-missing ? Or some characters look strange ?
-<p>
-
-Send the bug reports to the ttf2pt1 development mailing list at
-<A HREF="mailto:ttf2pt1-devel@lists.sourceforge.net">ttf2pt1-devel@lists.sourceforge.net</A>.
-<p>
-
-Try to collect more information about the problem and include it into
-the bug report. (Of course, even better if you would provide a ready
-fix, but just a detailed bug report is also good). Provide detailed
-information about your problem, this will speed up the response greatly.
-Don't just write "this font looks strange after conversion" but describe
-what's exactly wrong with it: for example, what characters look wrong
-and what exactly is wrong about their look. Providing a link to the
-original font file would be also a good idea. Try to do a little
-troublehooting and report its result. This not only would help with
-the fix but may also give you a temporary work-around for the bug.
-<p>
-
-First, enable full warnings with option '<b>-W99</b>', save them to
-a file and read carefully. Sometimes the prolem is with a not implemented
-feature which is reported in the warnings. Still, reporting about such
-problems may be a good idea: some features were missed to cut corners,
-in hope that no real font is using them. So a report about a font using
-such a feature may motivate someone to implement it. Of course, you
-may be the most motivated person: after all, you are the one wishing
-to convert that font. ;-) Seriously, the philosophy "scrath your own itch"
-seems to be the strongest moving force behind the Open Source software.
-<p>
-
-The next step is playing with the options. This serves a dual purpose:
-on one hand, it helps to localize the bug, on the other hand you may be
-able to get a working version of the font for the meantime while the
-bug is being fixed. The typical options to try out are: first '<b>-Ou</b>', if
-it does not help then '<b>-Os</b>', then '<b>-Oh</b>', then '<b>-Oo</b>'.
-They are described in a bit more detail above. Try them one by one
-and in combinations. See if with them the resulting fonts look better.
-<p>
-
-On some fonts ttf2pt1 just crashes. Commonly that happens because the
-font being converted is highly defective (although sometimes the bug
-is in ttf2pt1 itself). In any case it should not crash, so the reports
-about such cases will help to handle these defects properly in future.
-<p>
-
-We try to respond to the bug reports in a timely fashion but alas, this
-may not always be possible, especially if the problem is complex.
-This is a volunteer project and its resources are limited. Because
-of this we would appreciate bug reports as detailed as possible,
-and we would appreciate the ready fixes and contributions even more.
-<p>
-<!-- =stop -->
-<!-- =section t1 FILES -->
-<!-- ==over 2 -->
-<!-- ==item * -->
-<!-- =text TTF2PT1_LIBXDIR/t1asm -->
-<!-- ==item * -->
-<!-- =text TTF2PT1_SHAREDIR/* -->
-<!-- ==item * -->
-<!-- =text TTF2PT1_SHAREDIR/scripts/* -->
-<!-- ==item * -->
-<!-- =text TTF2PT1_SHAREDIR/other/* -->
-<!-- ==item * -->
-<!-- =text TTF2PT1_SHAREDIR/README -->
-<!-- ==item * -->
-<!-- =text TTF2PT1_SHAREDIR/FONTS -->
-<!-- ==back -->
-<!-- =stop -->
-
-<H4>
-CONTACTS
-</H4>
-<!
---------
->
-<!-- =section t1 SEE ALSO -->
-<!-- ==over 4 -->
-<!-- ==item * -->
-<!-- =text L&lt;ttf2pt1_convert(1)&gt; -->
-<!-- ==item * -->
-<!-- =text L&lt;ttf2pt1_x2gs(1)&gt; -->
-<!-- ==item * -->
-<!-- =text L&lt;t1asm(1)&gt; -->
-
-<!-- ==item * -->
-<A HREF="http://lists.sourceforge.net/mailman/listinfo/ttf2pt1-announce">
-ttf2pt1-announce@lists.sourceforge.net
-</A><br>
- The mailing list with announcements about ttf2pt1. It is a moderated mailing
- with extremely low traffic. Everyone is encouraged to subscribe to keep in
- touch with the current status of project. To subscribe use the Web interface
- at <A HREF="http://lists.sourceforge.net/mailman/listinfo/ttf2pt1-announce">http://lists.sourceforge.net/mailman/listinfo/ttf2pt1-announce</A>.
- If you have only e-mail access to the Net then send a subscribe request to
- the development mailing list ttf2pt1-devel@lists.sourceforge.net and somebody
- will help you with subscription.
-<p>
-
-<!-- ==item * -->
-<A HREF="mailto:ttf2pt1-devel@lists.sourceforge.net">
-ttf2pt1-devel@lists.sourceforge.net
-</A><br>
-<A HREF="mailto:ttf2pt1-users@lists.sourceforge.net">
-ttf2pt1-users@lists.sourceforge.net
-</A><br>
- The ttf2pt1 mailing lists for development and users issues. They have not
- that much traffic either. To subscribe use the Web interface at
- <A HREF="http://lists.sourceforge.net/mailman/listinfo/ttf2pt1-devel">http://lists.sourceforge.net/mailman/listinfo/ttf2pt1-devel</A>
- and <A HREF="http://lists.sourceforge.net/mailman/listinfo/ttf2pt1-users">http://lists.sourceforge.net/mailman/listinfo/ttf2pt1-users</A>.
- If you have only e-mail access to the Net then send a subscribe request to
- the development mailing list ttf2pt1-devel@lists.sourceforge.net and somebody
- will help you with subscription.
-<p>
-
-<!-- =stop -->
-<A HREF="mailto:mheath@netspace.net.au">
-mheath@netspace.net.au
-</A><br>
- Mark Heath
-<p>
-
-<A HREF="mailto:A.Weeks@mcc.ac.uk">
-A.Weeks@mcc.ac.uk
-</A><br>
- Andrew Weeks
-<p>
-
-<A HREF="mailto:babkin@users.sourceforge.net">
-babkin@users.sourceforge.net</A> (preferred)<br>
-<A HREF="mailto:sab123@hotmail.com">
-sab123@hotmail.com
-</A><br>
-<A HREF="http://members.bellatlantic.net/~babkin">
-http://members.bellatlantic.net/~babkin
-</A><br>
- Sergey Babkin
-<p>
-
-<H4>
-SEE ALSO
-</H4>
-<!
---------
->
-
-<!-- =section t1 SEE ALSO -->
-<!-- ==item * -->
-<A HREF="http://ttf2pt1.sourceforge.net">
-http://ttf2pt1.sourceforge.net
-</A><br>
- The main page of the project.
-<p>
-
-<A HREF="http://www.netspace.net.au/~mheath/ttf2pt1/">
-http://www.netspace.net.au/~mheath/ttf2pt1/
-</A><br>
- The old main page of the project.
-<p>
-<!-- ==back -->
-<!-- =stop -->
-
-<A HREF="http://sourceforge.net/projects/gnuwin32">
-http://sourceforge.net/projects/gnuwin32
-</A><br>
- Precompiled binaries for Windows.
-<p>
-
-<A HREF="http://www.lcdf.org/~eddietwo/type/">
-http://www.lcdf.org/~eddietwo/type/
-</a><br>
- The home page of the Type 1 utilities package.
-<p>
-
-<A HREF="http://www.rightbrain.com/pages/books.html">
-http://www.rightbrain.com/pages/books.html
-</a><br>
- The first book about PostScript on the Web, "Thinking in PostScript".
-<p>
-
-<A HREF="http://fonts.apple.com/TTRefMan/index.html">
-http://fonts.apple.com/TTRefMan/index.html
-</a><br>
- The True Type reference manual.
-<p>
-
-<A HREF="http://partners.adobe.com/asn/developer/PDFS/TN/PLRM.pdf">
-http://partners.adobe.com/asn/developer/PDFS/TN/PLRM.pdf
-</a><br>
- Adobe PostScript reference manual.
-<p>
-
-<A HREF="http://partners.adobe.com/asn/developer/PDFS/TN/T1_SPEC.PDF">
-http://partners.adobe.com/asn/developer/PDFS/TN/T1_SPEC.PDF
-</a><br>
- Specification of the Type 1 font format.
-<p>
-
-<A HREF="http://partners.adobe.com/asn/developer/PDFS/TN/5015.Type1_Supp.pdf">
-http://partners.adobe.com/asn/developer/PDFS/TN/5015.Type1_Supp.pdf
-</a><br>
- The Type 1 font format supplement.
-<p>
-
-<A HREF="http://partners.adobe.com/asn/developer/PDFS/TN/5004.AFM_Spec.pdf">
-http://partners.adobe.com/asn/developer/PDFS/TN/5004.AFM_Spec.pdf
-</A><BR>
- Specification of the Adobe font metrics file format.
-<p>
-
-<A HREF="http://www.cs.wpi.edu/~matt/courses/cs563/talks/surface/bez_surf.html">
-http://www.cs.wpi.edu/~matt/courses/cs563/talks/surface/bez_surf.html
-</A><BR>
-<A HREF="http://www.cs.wpi.edu/~matt/courses/cs563/talks/curves.html">
-http://www.cs.wpi.edu/~matt/courses/cs563/talks/curves.html
-</A><BR>
- Information about the Bezier curves.
-<p>
-
-<A HREF="http://www.neuroinformatik.ruhr-uni-bochum.de/ini/PEOPLE/rmz/t1lib/t1lib.html">
-http://www.neuroinformatik.ruhr-uni-bochum.de/ini/PEOPLE/rmz/t1lib/t1lib.html
-</A><br>
- A stand-alone library supporting the Type1 fonts. Is neccessary
- to compile the programs <tt>other/cmpf</tt> and <tt>other/dmpf</tt>.
-<p>
-
-<A HREF="http://www.freetype.org">
-http://www.freetype.org
-</A><br>
- A library supporting the TTF fonts. Also many useful TTF programs
- are included with it.
-<p>
-
-<A HREF="http://heliotrope.homestead.com/files/printsoft.html">
-http://heliotrope.homestead.com/files/printsoft.html
-</A><br>
- Moses Gold's collection of links to printing software.
-<p>
-
-<A HREF="http://linuxartist.org/fonts/">
-http://linuxartist.org/fonts/
-</A><br>
- Collection of font-related links.
-<p>
-
-<HR>
-<HR>
-<!
-----------------------------------------------------------------------
-----------------------------------------------------------------------
->
-
-Following is the Readme of <tt>ttf2pfa</tt> (true type to type 3 font converter) It
-covers other issues regarding the use of this software. Please note that
-although <tt>ttf2pfa</tt> is a public domain software, <tt>ttf2pt1</tt>
-is instead covered by an Open Source license. See the <tt>COPYRIGHT</tt>
-file for details.
-<p>
-
-Please note also that <tt>ttf2pfa</tt> has not been maintained for a long time.
-All of its functionality has been integrated into <tt>ttf2pt1</tt> and all the
-development moved to <tt>ttf2pt1</tt>, including Andrew Weeks, the author of
-<tt>ttf2pfa</tt>. <tt>Ttf2pfa</tt> is provided for historical reasons only. Please use
-<tt>ttf2pt1</tt> instead.
-
-<HR>
-<!
-----------------------------------------------------------------------
->
-
-<H3>
-True Type to Postscript Font converter
-</H3>
-<!
---------------------------------------
->
-
-My mind is still reeling from the discovery that I was able to write
-this program. What it does is it reads a Microsoft TrueType font and
-creates a Postscript font. '<I>_A_</I> postscript font', that is, not necessarily
-the same font, you understand, but a fair imitation.
-<p>
-
-Run it like this:
-<p>
-
-<blockquote><tt>
- ttf2pfa fontfile.ttf fontname
-</tt></blockquote>
-<p>
-
-The first parameter is the truetype filename, the second is a stem for
-the output file names. The program will create a <tt>fontname.pfa</tt> containing
-the Postscript font and a <tt>fontname.afm</tt> containing the metrics.
-<p>
-
-The motivation behind this is that in Linux if you do not have a
-Postscript printer, but only some other printer, you can only print
-Postscript by using Ghostscript. But the fonts that come with
-Ghostscript are very poor (they are converted from bitmaps and look
-rather lumpy). This is rather frustrating as the PC running Linux
-probably has MS-Windows as well and will therefore have truetype fonts,
-but which are quite useless with Linux, X or Ghostscript.
-<p>
-
-The program has been tested on over a hundred different TrueType fonts
-from various sources, and seems to work fairly well. The converted
-characters look OK, and the program doesn't seem to crash any more. I'm
-not sure about the AFM files though, as I have no means to test them.
-<p>
-
-The fonts generated will not work with X, as the font rasterizer that
-comes with X only copes with Type 1 fonts. If I have the time I may
-modify ttf2pfa to generate Type 1s.
-<p>
-
-<H4>
-Copyright issues
-</H4>
-<!
-----------------
->
-
-I am putting this program into the public domain, so don't bother
-sending me any money, I'd only have to declare it for income tax.
-<p>
-
-Copyright on fonts, however, is a difficult legal question. Any
-copyright statements found in a font will be preserved in the output.
-Whether you are entitled to translate them at all I don't know.
-<p>
-
-If you have a license to run a software package, like say MS-Windows, on
-your PC, then you probably have a right to use any part of it, including
-fonts, on that PC, even if not using that package for its intended
-purpose.
-<p>
-
-I am not a lawyer, however, so this is not a legal opinion, and may be
-garbage.
-<p>
-
-There shouldn't be a any problem with public domain fonts.
-<p>
-
-<H4>
-About the Program
-</H4>
-<!
------------------
->
-
-It was written in C on a IBM PC running Linux.
-<p>
-
-The TrueType format was originally developed by Apple for the MAC, which
-has opposite endianness to the PC, so to ensure compatibility 16 and 32
-bit fields are the wrong way round from the PC's point of view. This is
-the reason for all the 'ntohs' and 'ntohl' calls. Doing it this way
-means the program will also work on big-endian machines like Suns.
-<p>
-
-I doubt whether it will work on a DOS-based PC though.
-<p>
-
-The program produces what technically are Type 3 rather than Type 1
-fonts. They are not compressed or encrypted and are plain text. This is
-so I (and you) can see what's going on, and (if you're a Postscript guru
-and really want to) can alter the outlines.
-<p>
-
-I only translate the outlines, not the 'instructions' that come with
-them. This latter task is probably virtually impossible anyway. TrueType
-outlines are B-splines rather than the Bezier curves that Postscript
-uses. I believe that my conversion algorithm is reasonably correct, if
-nothing else because the characters look right.
-<p>
-
-<H4>
-Problems that may occur
-</H4>
-<!
------------------------
->
-
-Most seriously, very complex characters (with lots of outline segments)
-can make Ghostscript releases 2.x.x fail with a 'limitcheck' error. It
-is possible that this may happen with some older Postscript printers as
-well. Such characters will be flagged by the program and there are
-basically two things you can do. First is to edit the <tt>.pfa</tt> file to
-simplify or remove the offending character. This is not really
-recommended. The second is to use Ghostscript release 3, if you can get
-it. This has much larger limits and does not seem to have any problems
-with complex characters.
-<p>
-
-Then there are buggy fonts (yes, a font can have bugs). I try to deal
-with these in as sane a manner as possible, but it's not always
-possible.
-<p>
-
-<H4>
-Encodings
-</H4>
-<!
----------
->
-
-A postscript font must have a 256 element array, called an encoding,
-each element of which is a name, which is also the name of a procedure
-contained within the font. The 'BuildChar' command takes a byte and uses
-it to index the encoding array to find a character name, and then looks
-that up in the font's procedure table find the commands to draw the
-glyph. However, not all characters need be in the encoding array. Those
-that are not cannot be drawn (at least not using 'show'), however it is
-possible to 're-encode' the font to enable these characters. There are
-several standard encodings: Adobe's original, ISO-Latin1 and Symbol
-being the most commonly encountered.
-<p>
-
-TrueType fonts are organised differently. As well as the glyph
-descriptions there are a number of tables. One of these is a mapping
-from a character set into the glyph array, and another is a mapping from
-the glyph array into a set of Postscript character names. The problems
-are:
-<p>
- 1) Microsoft uses Unicode, a 16-bit system, to encode the font.
-<br>
- 2) that more than one glyph is given the same Postscript name.
-<p>
-
-I deal with (1) by assuming a Latin1 encoding. The MS-Windows and
-Unicode character sets are both supersets of ISO-8859-1. This usually
-means that most characters will be properly encoded, but you should be
-warned that some software may assume that fonts have an Adobe encoding.
-Symbol, or Dingbat, fonts are in fact less of a problem, as they have
-private encodings starting at 0xF000. It is easy to just lose the top
-byte.
-<p>
-
-Postscript fonts can be re-encoded, either manually, or by software.
-Groff, for example, generates postscript that re-encodes fonts with the
-Adobe encoding. The problem here is that not all characters in the Adobe
-set are in the MS-Windows set. In particular there are no fi and fl
-ligatures. This means that conversions of the versions of
-Times-New-Roman and Arial that come with MS-Windows cannot be used
-blindly as replacements for Adobe Times-Roman and Helvetica. You can get
-expanded versions of MS fonts from Microsoft's web site which do contain
-these ligatures (and a lot else besides).
-<p>
-
-I deal with (2) by creating new character names. This can be error-prone
-because I do not know which of them is the correct glyph to give the
-name to. Some (buggy) fonts have large numbers of blank glyphs, all with
-the same name.
-<p>
-
-(almost every TrueType font has three glyphs called <tt>.notdef</tt>, one of them
-is usually an empty square shape, one has no outline and has zero width,
-and one has no outline and a positive width. This example is not really
-a problem with well formed fonts since the <tt>.notdef</tt> characters are only
-used for unprintable characters, which shouldn't occur in your documents
-anyway).
-<p>
-</BODY>
-</HTML>