diff options
| author | Reinhard Tartler <siretart@tauware.de> | 2011-10-10 17:43:39 +0200 |
|---|---|---|
| committer | Reinhard Tartler <siretart@tauware.de> | 2011-10-10 17:43:39 +0200 |
| commit | f4092abdf94af6a99aff944d6264bc1284e8bdd4 (patch) | |
| tree | 2ac1c9cc16ceb93edb2c4382c088dac5aeafdf0f /nx-X11/extras/ttf2pt1/README.html | |
| parent | a840692edc9c6d19cd7c057f68e39c7d95eb767d (diff) | |
| download | nx-libs-f4092abdf94af6a99aff944d6264bc1284e8bdd4.tar.gz nx-libs-f4092abdf94af6a99aff944d6264bc1284e8bdd4.tar.bz2 nx-libs-f4092abdf94af6a99aff944d6264bc1284e8bdd4.zip | |
Imported nx-X11-3.1.0-1.tar.gznx-X11/3.1.0-1
Summary: Imported nx-X11-3.1.0-1.tar.gz
Keywords:
Imported nx-X11-3.1.0-1.tar.gz
into Git repository
Diffstat (limited to 'nx-X11/extras/ttf2pt1/README.html')
| -rw-r--r-- | nx-X11/extras/ttf2pt1/README.html | 1182 |
1 files changed, 1182 insertions, 0 deletions
diff --git a/nx-X11/extras/ttf2pt1/README.html b/nx-X11/extras/ttf2pt1/README.html new file mode 100644 index 000000000..b1d6c9c22 --- /dev/null +++ b/nx-X11/extras/ttf2pt1/README.html @@ -0,0 +1,1182 @@ +<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> + <TT>latin1</TT> - for all the languages using the Latin-1 encoding +<br> + <TT>latin2</TT> - for the Central European languages +<br> + <TT>latin4</TT> - for the Baltic languages +<br> + <TT>latin5</TT> - for the Turkish language +<br> + <TT>cyrillic</TT> - for the languages with Cyrillic alphabet +<br> + <TT>russian</TT> - historic synonym for cyrillic +<br> + <TT>bulgarian</TT> - historic synonym for cyrillic +<br> + <TT>adobestd</TT> - for the AdobeStandard encoding used by TeX +<br> + <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> + <tt>plane+<b>pid=</b><i><pid></i><b>,eid=</b><i><eid></i></tt> +<br> + <tt>plane+<b>pid=</b><i><pid></i><b>,eid=</b><i><eid></i><b>,</b><i><plane_number></i></tt> +<br> + <tt>plane+<i><plane_number></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><pid></I>,eid=<I><eid></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> + + <TT>ttf</TT> - built-in parser for the ttf files (suffix <tt>.ttf</tt>) +<br> + <TT>bdf</TT> - built-in parser for the BDF files (suffix <tt>.bdf</tt>) +<br> + <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> 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 >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> + + <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<ttf2pt1_convert(1)> --> +<!-- ==item * --> +<!-- =text L<ttf2pt1_x2gs(1)> --> +<!-- ==item * --> +<!-- =text L<t1asm(1)> --> + +<!-- ==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> |