1 | TTF2PT1 - A True Type to PostScript Type 1 Font Converter |
---|
2 | |
---|
3 | (Do not edit this file, it is generated from README.html!!!) |
---|
4 | [ |
---|
5 | Based on ttf2pfa by Andrew Weeks, and help from Frank Siegert. |
---|
6 | Modification by Mark Heath. |
---|
7 | Further modification by Sergey Babkin. |
---|
8 | The Type1 assembler by I. Lee Hetherington with modifications by |
---|
9 | Kai-Uwe Herbing. |
---|
10 | ] |
---|
11 | |
---|
12 | Ever wanted to install a particular font on your XServer but only could find |
---|
13 | the font you are after in True Type Format? |
---|
14 | |
---|
15 | Ever asked comp.fonts for a True Type to Type 1 converter and got a List |
---|
16 | of Commercial software that doesn't run on your Operating System? |
---|
17 | |
---|
18 | Well, this program should be the answer. This program is written in C (so it |
---|
19 | should be portable) and therefore should run on any OS. The only limitation |
---|
20 | is that the program requires some method of converting Big endian integers into |
---|
21 | local host integers so the network functions ntohs and ntohl are used. These |
---|
22 | can be replaced by macros if your platform doesn't have them. |
---|
23 | Of course the target platform requires a C compiler and command line ability. |
---|
24 | |
---|
25 | Ttf2pt1 is a font converter from the True Type format (and some other formats |
---|
26 | supported by the FreeType library as well) to the Adobe Type1 format. |
---|
27 | |
---|
28 | The versions 3.0 and later got rather extensive post-processing algorithm that |
---|
29 | brings the converted fonts to the requirements of the Type1 standard, tries to |
---|
30 | correct the rounding errors introduced during conversions and some simple |
---|
31 | kinds of bugs that are typical for the public domain TTF fonts. It |
---|
32 | also generates the hints that enable much better rendering of fonts in |
---|
33 | small sizes that are typical for the computer displays. But everything |
---|
34 | has its price, and some of the optimizations may not work well for certain |
---|
35 | fonts. That's why the options were added to the converter, to control |
---|
36 | the performed optimizations. |
---|
37 | |
---|
38 | The converter is simple to run, just: |
---|
39 | |
---|
40 | ttf2pt1 [-options] ttffont.ttf [Fontname] |
---|
41 | or |
---|
42 | ttf2pt1 [-options] ttffont.ttf - |
---|
43 | |
---|
44 | The first variant creates the file Fontname.pfa (or Fontname.pfb if the |
---|
45 | option '-b' was used) with the converted font and Fontname.afm with the |
---|
46 | font metrics, the second one prints the font or another file (if the option |
---|
47 | '-G' was used) on the standard output from where it can be immediately |
---|
48 | piped through some filter. If no Fontname is specified for the first |
---|
49 | variant, the name is generated from ttffont by replacing the .ttf |
---|
50 | filename suffix. |
---|
51 | |
---|
52 | Most of the time no options are neccessary (with a possible exception |
---|
53 | of '-e'). But if there are some troubles with the resulting font, they |
---|
54 | may be used to control the conversion. |
---|
55 | The options are: |
---|
56 | |
---|
57 | -a - Include all the glyphs from the source file into the converted |
---|
58 | file. If this option is not specified then only the glyphs that have |
---|
59 | been assigned some encoding are included, because the rest of glyphs |
---|
60 | would be inaccessible anyway and would only consume the disk space. |
---|
61 | But some applications are clever enough to change the encoding on |
---|
62 | the fly and thus use the other glyphs, in this case they could |
---|
63 | benefit from using this option. But there is a catch: the X11 library |
---|
64 | has rather low limit for the font size. Including more glyphs increases |
---|
65 | the file size and thus increases the chance of hitting this limit. |
---|
66 | See app/X11/README for the description of a |
---|
67 | patch to X11 which fixes this problem. |
---|
68 | |
---|
69 | -b - Encode the resulting font to produce a ready .pfb file. |
---|
70 | |
---|
71 | -d suboptions - Debugging options. The suboptions are: |
---|
72 | |
---|
73 | a - Print out the absolute coordinates of dots in outlines. Such |
---|
74 | a font can not be used by any program (that's why this option is |
---|
75 | incompatible with '-e') but it has proven to be a valuable debuging |
---|
76 | information. |
---|
77 | |
---|
78 | r - Do not reverse the direction of outlines. The TTF fonts have |
---|
79 | the standard direction of outlines opposite to the Type1 fonts. So |
---|
80 | they should be reversed during proper conversion. This option |
---|
81 | may be used for debugging or to handle a TTF font with wrong |
---|
82 | direction of outlines (possibly, converted in a broken way from |
---|
83 | a Type1 font). The first signs of the wrong direction are the |
---|
84 | letters like "P" or "B" without the unpainted "holes" inside. |
---|
85 | |
---|
86 | -e - Assemble the resulting font to produce a ready .pfa file. |
---|
87 | [ S.B.: Personally I don't think that this option is particularly useful. |
---|
88 | The same result may be achieved by piping the unassembled data |
---|
89 | through t1asm, the Type 1 assembler. And, anyways, it's good to |
---|
90 | have the t1utils package handy. But Mark and many users think that |
---|
91 | this functionality is good and it took not much time to add this option. ] |
---|
92 | |
---|
93 | -F - Force the Unicode encoding: any type of MS encoding specified |
---|
94 | in the font is ignored and the font is treated like it has Unicode |
---|
95 | encoding. WARNING: this option is intended for buggy fonts |
---|
96 | which actually are in Unicode but are marked as something else. The |
---|
97 | effect on the other fonts is unpredictable. |
---|
98 | |
---|
99 | -G suboptions - File generation options. The suboptions may be lowercase |
---|
100 | or uppercase, the lowercase ones disable the generation of particular |
---|
101 | files, the corresponding uppercase suboptions enable the generation of the |
---|
102 | same kind of files. If the result of ttf2pt1 is requested to be printed on |
---|
103 | the standard output, the last enabling suboption of -G determines |
---|
104 | which file will be written to the standard output and the rest of files |
---|
105 | will be discarded. For example, -G A will request the AFM file. |
---|
106 | The suboptions to disable/enable the generation of the files are: |
---|
107 | |
---|
108 | f/F - The font file. Depending on the other options this file |
---|
109 | will have one of the suffixes .t1a, .pfa or .pfb. If the conversion result |
---|
110 | is requested on the standard output ('-' is used as the output file name) |
---|
111 | then the font file will also be written there by default, if not overwritten |
---|
112 | by another suboption of -G. |
---|
113 | Default: enabled |
---|
114 | |
---|
115 | a/A - The Adobe font metrics file (.afm). |
---|
116 | Default: enabled |
---|
117 | |
---|
118 | e/E - The dvips encoding file (.enc). |
---|
119 | Default: disabled |
---|
120 | |
---|
121 | |
---|
122 | -l language[+argument] - Extract the fonts for the specified language from a |
---|
123 | multi-language Unicode font. If this option is not used the converter |
---|
124 | tries to guess the language by the values of the shell variable LANG. |
---|
125 | If it is not able to guess the language by LANG it tries all the |
---|
126 | languages in the order they are listed. |
---|
127 | |
---|
128 | After the plus sign an optional argument for the language extractor |
---|
129 | may be specified. The format of the argument is absolutely up to |
---|
130 | the particular language converter. The primary purpose of the |
---|
131 | argument is to support selection of planes for the multi-plane |
---|
132 | Eastern encodings but it can also be used in any other way. The |
---|
133 | language extractor may decide to add the plane name in some form |
---|
134 | to the name of the resulting font. None of the currently supported |
---|
135 | languages make any use of the argument yet. |
---|
136 | |
---|
137 | As of now the following languages are supported: |
---|
138 | latin1 - for all the languages using the Latin-1 encoding |
---|
139 | latin2 - for the Central European languages |
---|
140 | latin4 - for the Baltic languages |
---|
141 | latin5 - for the Turkish language |
---|
142 | cyrillic - for the languages with Cyrillic alphabet |
---|
143 | russian - historic synonym for cyrillic |
---|
144 | bulgarian - historic synonym for cyrillic |
---|
145 | adobestd - for the AdobeStandard encoding used by TeX |
---|
146 | plane+argument - to select one plane from a multi-byte encoding |
---|
147 | |
---|
148 | The argument of the "plane" language may be in one of three forms: |
---|
149 | plane+pid=<pid>,eid=<eid> |
---|
150 | plane+pid=<pid>,eid=<eid>,<plane_number> |
---|
151 | plane+<plane_number> |
---|
152 | |
---|
153 | Pid (TTF platform id) and eid (TTF encoding id) select a particular |
---|
154 | TTF encoding table in the original font. They are specified as decimal |
---|
155 | numbers. If this particular encoding table is not present in the font |
---|
156 | file then the conversion fails. The native ("ttf") front-end parser supports |
---|
157 | only pid=3 (Windows platform), the FreeType-based ("ft") front-end supports |
---|
158 | any platform. If pid/eid is not specified then the TTF encoding table is |
---|
159 | determined as usual: Unicode encoding if it's first or an 8-bit encoding |
---|
160 | if not (and for an 8-bit encoding the plane number is silently ignored). |
---|
161 | To prevent the converter from falling back to an 8-bit encoding, specify |
---|
162 | the Unicode pid/eid value explicitly. |
---|
163 | |
---|
164 | Plane_number is a hexadecimal (if starts with "0x") or decimal number. |
---|
165 | It gives the values of upper bytes for which 256 characters will be |
---|
166 | selected. If not specified, defaults to 0. It is also used as a font |
---|
167 | name suffix (the leading "0x" is not included into the suffix). |
---|
168 | |
---|
169 | NOTE: |
---|
170 | It seems that many Eastern fonts use features of the TTF format that are |
---|
171 | not supported by the ttf2pt1's built-in front-end parser. Because of |
---|
172 | this for now we recommend using the FreeType-based parser (option |
---|
173 | '-p ft') with the "plane" language. |
---|
174 | |
---|
175 | NOTE: |
---|
176 | You may notice that the language names are not uniform: some are the |
---|
177 | names of particular languages and some are names of encodings. This |
---|
178 | is because of the different approaches. The original idea was to |
---|
179 | implement a conversion from Unicode to the appropriate Windows |
---|
180 | encoding for a given language. And then use the translation tables |
---|
181 | to generate the fonts in whatever final encodings are needed. This |
---|
182 | would allow to pile together the Unicode fonts and the non-Unicode |
---|
183 | Windows fonts for that language and let the program to sort them out |
---|
184 | automatically. And then generate fonts in all the possible encodings |
---|
185 | for that language. An example of this approach is the Russian language |
---|
186 | support. But if there is no multiplicity of encodings used for some |
---|
187 | languages and if the non-Unicode fonts are not considered important |
---|
188 | by the users, another way would be simpler to implement: just provide |
---|
189 | only one table for extraction of the target encoding from Unicode |
---|
190 | and don't bother with the translation tables. The latin* "languages" |
---|
191 | are examples of this approach. If somebody feels that he needs the |
---|
192 | Type1 fonts both in Latin-* and Windows encodings he or she is absolutely |
---|
193 | welcome to submit the code to implement it. |
---|
194 | |
---|
195 | WARNING: |
---|
196 | Some of the glyphs included into the AdobeStandard encoding are not |
---|
197 | included into the Unicode standard. The most typical examples of such |
---|
198 | glyphs are ligatures like 'fi', 'fl' etc. Because of this the font |
---|
199 | designers may place them at various places. The converter tries to |
---|
200 | do its best, if the glyphs have honest Adobe names and/or are |
---|
201 | placed at the same codes as in the Microsoft fonts they will be |
---|
202 | picked up. Otherwise a possible solution is to use the option '-L' |
---|
203 | with an external map. |
---|
204 | |
---|
205 | -L file[+[pid=<pid>,eid=<eid>,][plane]] - Extract the fonts for the specified |
---|
206 | language from a multi-language font using the map from this file. This is |
---|
207 | rather like the option '-l' but the encoding map is not |
---|
208 | compiled into the program, it's taken from that file, so it's |
---|
209 | easy to edit. Examples of such files are provided in |
---|
210 | maps/adobe-standard-encoding.map, CP1250.map. (NOTE: |
---|
211 | the 'standard encoding' map does not include all the glyphs of the |
---|
212 | AdobeStandard encoding, it's provided only as an example.) The |
---|
213 | description of the supported map formats is in the file |
---|
214 | maps/unicode-sample.map. |
---|
215 | |
---|
216 | Likewise to '-l', an argument may be specified after the map file |
---|
217 | name. But in this case the argument has fixed meaning: it selects the |
---|
218 | original TTF encoding table (the syntax is the same as in '-l plane') |
---|
219 | and/or a plane of the map file. The plane name also gets added after dash |
---|
220 | to the font name. The plane is a concept used in the Eastern fonts with big |
---|
221 | number of glyphs: one TTF font gets divided into multiple Type1 fonts, |
---|
222 | each containing one plane of up to 256 glyphs. But with a little |
---|
223 | creativity this concept may be used for other purposes of combining |
---|
224 | multiple translation maps into one file. To extract multiple planes |
---|
225 | from a TTF font ttf2pt1 must be run multiple times, each time with |
---|
226 | a different plane name specified. |
---|
227 | |
---|
228 | The default original TTF encoding table used for the option '-L' is |
---|
229 | Unicode. The map files may include directives to specify different original |
---|
230 | TTF encodings. However if the pid/eid pair is specified with |
---|
231 | it overrides any original encoding specified in the map file. |
---|
232 | |
---|
233 | -m type=value - Set maximal or minimal limits of resources. |
---|
234 | These limits control the the font generation by limiting the resources |
---|
235 | that the font is permitted to require from the PostScript interpreter. |
---|
236 | The currently supported types of limits are: |
---|
237 | |
---|
238 | h - the maximal hint stack depth for the substituted hints. |
---|
239 | The default value is 128, according to the limitation in X11. This seems to |
---|
240 | be the lowest (and thus the safest) widespread value. To display the |
---|
241 | hint stack depth required by each glyph in a .t1a file use the script |
---|
242 | scripts/cntstems.pl. |
---|
243 | |
---|
244 | -O suboptions - Outline processing options. The suboptions |
---|
245 | may be lowercase or uppercase, the lowercase ones disable the features, |
---|
246 | the corresponding uppercase suboptions enable the same features. |
---|
247 | The suboptions to disable/enable features are: |
---|
248 | |
---|
249 | b/B - Guessing of the ForceBold parameter. This parameter helps |
---|
250 | the Type1 engine to rasterize the bold fonts properly at small sizes. |
---|
251 | But the algorithm used to guess the proper value of this flag makes |
---|
252 | that guess based solely on the font name. In rare cases that may cause |
---|
253 | errors, in these cases you may want to disable this guessing. |
---|
254 | Default: enabled |
---|
255 | |
---|
256 | h/H - Autogeneration of hints. The really complex outlines |
---|
257 | may confuse the algorithm, so theoretically it may be useful |
---|
258 | sometimes to disable them. Although up to now it seems that |
---|
259 | even bad hints are better than no hints at all. |
---|
260 | Default: enabled |
---|
261 | |
---|
262 | u/U - Hint substitution. Hint substitution is a technique |
---|
263 | permitting generation of more detailed hints for the rasterizer. It allows |
---|
264 | to use different sets of hints for different parts of a glyph and change |
---|
265 | these sets as neccessary during rasterization (that's why "substituted"). |
---|
266 | So it should improve the quality of the fonts rendered at small sizes. |
---|
267 | But there are two catches: First, the X11 library has rather low limit for |
---|
268 | the font size. More detailed hints increase the file size and thus increase |
---|
269 | the chance of hitting this limit (that does not mean that you shall hit it |
---|
270 | but you may if your fonts are particularly big). This is especially |
---|
271 | probable for Unicode fonts converted with option '-a', so you may want to |
---|
272 | use '-a' together with '-Ou'. See app/X11/README for the description of |
---|
273 | a patch to X11 which fixes this problem. Second, some rasterizers (again, |
---|
274 | X11 is the typical example) have a limitation for total number of hints |
---|
275 | used when drawing a glyph (also known as the hint stack depth). If that |
---|
276 | stack overflows the glyph is ignored. Starting from version 3.22 ttf2pt1 |
---|
277 | uses algorithms to minimizing this depth, with the trade-off of slightly |
---|
278 | bigger font files. The glyphs which still exceed the limit set by option |
---|
279 | '-mh' have all the substituted hints removed and only base hints left. |
---|
280 | The algorithms seem to have been refined far enough to make the fonts with |
---|
281 | substituted hints look better than the fonts without them or at least the |
---|
282 | same. Still if the original fonts are not well-designed the detailed |
---|
283 | hinting may emphasize the defects of the design, such as non-even thickness |
---|
284 | of lines. So provided that you are not afraid of the X11 bug the best idea |
---|
285 | would be to generate a font with this feature and without it, then compare |
---|
286 | the results using the program other/cmpf (see the description |
---|
287 | in other/README) and decide which one looks better. |
---|
288 | Default: enabled |
---|
289 | |
---|
290 | o/O - Space optimization of the outlines' code. This kind of optimization |
---|
291 | never hurts, and the only reason to disable this feature is for comparison |
---|
292 | of the generated fonts with the fonts generated by the previous versions of |
---|
293 | converter. Well, it _almost_ never hurts. As it turned out there exist |
---|
294 | some brain-damaged printers which don't understand it. Actually this |
---|
295 | feature does not change the outlines at all. The Type 1 font manual |
---|
296 | provides a set of redundant operators that make font description shorter, |
---|
297 | such as '10 hlineto' instead of '0 10 rlineto' to describe a horizontal |
---|
298 | line. This feature enables use of these operators. |
---|
299 | Default: enabled |
---|
300 | |
---|
301 | s/S - Smoothing of outlines. If the font is broken in some |
---|
302 | way (even the ones that are not easily noticeable), such smoothing |
---|
303 | may break it further. So disabling this feature is the first thing to be |
---|
304 | tried if some font looks odd. But with smoothing off the hint generation |
---|
305 | algorithms may not work properly too. |
---|
306 | Default: enabled |
---|
307 | |
---|
308 | t/T - Auto-scaling to the 1000x1000 Type1 standard matrix. The |
---|
309 | TTF fonts are described in terms of an arbitrary matrix up to |
---|
310 | 4000x4000. The converted fonts must be scaled to conform to |
---|
311 | the Type1 standard. But the scaling introduces additional rounding |
---|
312 | errors, so it may be curious sometimes to look at the font in its |
---|
313 | original scale. |
---|
314 | Default: enabled |
---|
315 | |
---|
316 | v/V - Do vectorization on the bitmap fonts. Functionally |
---|
317 | "vectorization" is the same thing as "autotracing", a different word is |
---|
318 | used purely to differentiate it from the Autotrace library. It tries to |
---|
319 | produce nice smooth outlines from bitmaps. This feature is still a work |
---|
320 | in progress though the results are already mostly decent. |
---|
321 | Default: disabled |
---|
322 | |
---|
323 | w/W - Glyphs' width corection. This option is designed to be |
---|
324 | used on broken fonts which specify too narrow widths for the |
---|
325 | letters. You can tell that a font can benefit from this option |
---|
326 | if you see that the characters are smashed together without |
---|
327 | any whitespace between them. This option causes the converter |
---|
328 | to set the character widths to the actual width of this character |
---|
329 | plus the width of a typical vertical stem. But on the other hand |
---|
330 | the well-designed fonts may have characters that look better if |
---|
331 | their widths are set slightly narrower. Such well-designed fonts |
---|
332 | will benefit from disabling this feature. You may want to convert |
---|
333 | a font with and without this feature, compare the results and |
---|
334 | select the better one. This feature may be used only on proportional |
---|
335 | fonts, it has no effect on the fixed-width fonts. |
---|
336 | Default: disabled |
---|
337 | |
---|
338 | z/Z - Use the Autotrace library on the bitmap fonts. The results |
---|
339 | are horrible and the use of this option is not recommended. This option is |
---|
340 | present for experimental purposes. It may change or be removed in the |
---|
341 | future. The working tracing can be achieved with option -OV. |
---|
342 | Default: disabled |
---|
343 | |
---|
344 | -p parser_name - Use the specified front-end parser to read the font file. |
---|
345 | If this option is not used, ttf2pt1 selects the parser automatically based |
---|
346 | on the suffix of the font file name, it uses the first parser in its |
---|
347 | list that supports this font type. Now two parsers are supported: |
---|
348 | |
---|
349 | ttf - built-in parser for the ttf files (suffix .ttf) |
---|
350 | bdf - built-in parser for the BDF files (suffix .bdf) |
---|
351 | ft - parser based on the FreeType-2 library (suffixes .ttf, |
---|
352 | .otf, .pfa, .pfb) |
---|
353 | |
---|
354 | The parser ft is NOT linked in by default. See Makefile |
---|
355 | for instructions how to enable it. We do no support this parser on |
---|
356 | Windows: probably it will work but nobody tried and nobody knows how |
---|
357 | to build it. |
---|
358 | |
---|
359 | The conversion of the bitmap fonts (such as BDF) is simplistic yet, |
---|
360 | producing jagged outlines. When converting such fonts, it might be |
---|
361 | a good idea to turn off the hint substitution (using option -Ou) |
---|
362 | because the hints produced will be huge but not adding much to the |
---|
363 | quality of the fonts. |
---|
364 | |
---|
365 | -u number - Mark the font with this value as its |
---|
366 | UniqueID. The UniqueID is used by the printers with the hard disks |
---|
367 | to cache the rasterized characters and thus significantly |
---|
368 | speed-up the printing. Some of those printers just can't |
---|
369 | store the fonts without UniqueID on their disk.The problem |
---|
370 | is that the ID is supposed to be unique, as it name says. And |
---|
371 | there is no easy way to create a guaranteed unique ID. Adobe specifies |
---|
372 | the range 4000000-4999999 for private IDs but still it's difficult |
---|
373 | to guarantee the uniqueness within it. So if you don't really need the |
---|
374 | UniqueID don't use it, it's optional. Luckily there are a few millions of |
---|
375 | possible IDs, so the chances of collision are rather low. |
---|
376 | If instead of the number a special value 'A' is given |
---|
377 | then the converter generates the value of UniqueID automatically, |
---|
378 | as a hash of the font name. (NOTE: in the version 3.22 the |
---|
379 | algorithm for autogeneration of UniqueID was changed to fit the values |
---|
380 | into the Adobe-spacified range. This means that if UniqueIDs were used |
---|
381 | then the printer's cache may need to be flushed before replacing the |
---|
382 | fonts converted by an old version with fonts converted by a newer version). |
---|
383 | A simple way to find if any of the fonts in a given directory have |
---|
384 | duplicated UniqueIDs is to use the command: |
---|
385 | |
---|
386 | cat *.pf[ab] | grep UniqueID | sort | uniq -c | grep -v ' 1 ' |
---|
387 | |
---|
388 | Or if you use scripts/convert it will do that for you automatically |
---|
389 | plus it will also give the exact list of files with duplicate UIDs. |
---|
390 | |
---|
391 | -v size - Re-scale the font to get the size of a typical uppercase |
---|
392 | letter somewhere around the specified size. Actually, it re-scales |
---|
393 | the whole font to get the size of one language-dependent letter to be |
---|
394 | at least of the specified size. Now this letter is "A" in all the |
---|
395 | supported languages. The size is specified in the points of the |
---|
396 | Type 1 coordinate grids, the maximal value is 1000. This is an |
---|
397 | experimental option and should be used with caution. It tries to |
---|
398 | increase the visible font size for a given point size and thus make |
---|
399 | the font more readable. But if overused it may cause the fonts to |
---|
400 | look out of scale. As of now the interesting values of size for |
---|
401 | this option seem to be located mostly between 600 and 850. This |
---|
402 | re-scaling may be quite useful but needs more experience to |
---|
403 | understand the balance of its effects. |
---|
404 | |
---|
405 | -W level - Select the verbosity level of the warnings. |
---|
406 | Currently the levels from 0 to 4 are supported. Level 0 means no warnings |
---|
407 | at all, level 4 means all the possible warnings. The default level is 3. |
---|
408 | Other levels may be added in the future, so using the level number 99 is |
---|
409 | recommended to get all the possible warnings. Going below level 2 is |
---|
410 | not generally recommended because you may miss valuable information about |
---|
411 | the problems with the fonts being converted. |
---|
412 | |
---|
413 | Obsolete option: |
---|
414 | -A - Print the font metrics (.afm file) instead of the font on STDOUT. |
---|
415 | Use -GA instead. |
---|
416 | |
---|
417 | Very obsolete option: |
---|
418 | The algorithm that implemented the forced fixed width had major |
---|
419 | flaws, so it was disabled. The code is still in the program and |
---|
420 | some day it will be refined and returned back. Meanwhile the |
---|
421 | option name '-f' was reused for another option. The old version was: |
---|
422 | -f - Don't try to force the fixed width of font. Normally the converter |
---|
423 | considers the fonts in which the glyph width deviates by not more |
---|
424 | than 5% as buggy fixed width fonts and forces them to have really |
---|
425 | fixed width. If this is undesirable, it can be disabled by this option. |
---|
426 | |
---|
427 | The .pfa font format supposes that the description of the characters |
---|
428 | is binary encoded and encrypted. This converter does not encode or |
---|
429 | encrypt the data by default, you have to specify the option '-e' |
---|
430 | or use the t1asm program to assemble (that means, encode and |
---|
431 | encrypt) the font program. The t1asm program that is included with |
---|
432 | the converter is actually a part of the t1utils package, rather old |
---|
433 | version of which may be obtained from |
---|
434 | |
---|
435 | http://ttf2pt1.sourceforge.net/t1utils.tar.gz |
---|
436 | |
---|
437 | Note that t1asm from the old version of that package won't work properly |
---|
438 | with the files generated by ttf2pt1 version 3.20 and later. Please use |
---|
439 | t1asm packaged with ttf2pt1 or from the new version t1utils |
---|
440 | instead. For a newer version of t1utils please look at |
---|
441 | |
---|
442 | http://www.lcdf.org/~eddietwo/type/ |
---|
443 | |
---|
444 | So, the following command lines: |
---|
445 | |
---|
446 | ttf2pt1 -e ttffont.ttf t1font |
---|
447 | ttf2pt1 ttffont.ttf - | t1asm >t1font.pfa |
---|
448 | |
---|
449 | represent two ways to get a working font. The benefit of the second form |
---|
450 | is that other filters may be applied to the font between the converter |
---|
451 | and assembler. |
---|
452 | |
---|
453 | Installation and deinstallation of the converter |
---|
454 | ------------------------------------------------ |
---|
455 | |
---|
456 | The converter may be easily installed systemwide with |
---|
457 | |
---|
458 | make install |
---|
459 | |
---|
460 | and uninstalled with |
---|
461 | |
---|
462 | make uninstall |
---|
463 | |
---|
464 | By default the Makefile is configured to install in the hierarchy |
---|
465 | of directory /usr/local. This destination directory as well as |
---|
466 | the structure of the hierarchy may be changed by editing the Makefile. |
---|
467 | |
---|
468 | Installation of the fonts |
---|
469 | ------------------------- |
---|
470 | |
---|
471 | Running the converter manually becomes somewhat boring if it has to |
---|
472 | be applied to a few hundreds of fonts and then you have to generate the |
---|
473 | fonts.scale and/or Fontmap files. The FONTS file describes how to use |
---|
474 | the supplied scripts to handle such cases easily. It also discusses |
---|
475 | the installation of the fonts for a few widespread programs. |
---|
476 | |
---|
477 | Other utilities |
---|
478 | --------------- |
---|
479 | |
---|
480 | A few other small interesting programs that allow a cloase look at |
---|
481 | the fonts are located in the subdirectory 'other'. They |
---|
482 | are described shortly in others/README. |
---|
483 | |
---|
484 | Optional packages |
---|
485 | ----------------- |
---|
486 | |
---|
487 | Some auxiliary files are not needed by everyone and are big enough that |
---|
488 | moving them to a separate package speeds up the downloads of the main |
---|
489 | package significantly. As of now we have one such optional package: |
---|
490 | |
---|
491 | ttf2pt1-chinese - contains the Chinese conversion maps |
---|
492 | |
---|
493 | The general versioning policy for the optional packages is the following: |
---|
494 | These packages may have no direct dependency on the ttf2pt1 version. |
---|
495 | But they may be updated in future, as well as some versions of optional |
---|
496 | packages may have dependencies on certain versions of ttf2pt1. |
---|
497 | To avoid unneccessary extra releases on one hand and keep the updates in |
---|
498 | sync with the ttf2pt1 itself on the other hand, a new version of an optional |
---|
499 | package will be released only if there are any changes to it and it will be |
---|
500 | given the same version number as ttf2pt1 released at the same time. So not |
---|
501 | every release of ttf2pt1 would have a corresponding release of all optional |
---|
502 | packages. For example, to get the correct version of optional packages for an |
---|
503 | imaginary release 8.3.4 of ttf2pt1 you would need to look for optional |
---|
504 | packages of the highest version not higher than (but possibly equal to) 8.3.4. |
---|
505 | |
---|
506 | TO DO: |
---|
507 | ------ |
---|
508 | |
---|
509 | - Improve hinting. |
---|
510 | - Improve the auto-tracing of bitmaps. |
---|
511 | - Implement the family-level hints. |
---|
512 | - Add generation of CID-fonts. |
---|
513 | - Handle the composite glyphs with relative base points. |
---|
514 | - Preserve the relative width of stems during scaling to 1000x1000 matrix. |
---|
515 | - Add support for bitmap TTF fonts. |
---|
516 | - Implement better support of Asian encodings. |
---|
517 | - Implement automatic creation of ligatures. |
---|
518 | |
---|
519 | TROUBLESHOOTING AND BUG REPORTS |
---|
520 | ------------------------------- |
---|
521 | |
---|
522 | Have problems with conversion of some font ? The converter dumps core ? Or your |
---|
523 | printer refuses to understand the converted fonts ? Or some characters are |
---|
524 | missing ? Or some characters look strange ? |
---|
525 | |
---|
526 | Send the bug reports to the ttf2pt1 development mailing list at |
---|
527 | ttf2pt1-devel@lists.sourceforge.net. |
---|
528 | |
---|
529 | Try to collect more information about the problem and include it into |
---|
530 | the bug report. (Of course, even better if you would provide a ready |
---|
531 | fix, but just a detailed bug report is also good). Provide detailed |
---|
532 | information about your problem, this will speed up the response greatly. |
---|
533 | Don't just write "this font looks strange after conversion" but describe |
---|
534 | what's exactly wrong with it: for example, what characters look wrong |
---|
535 | and what exactly is wrong about their look. Providing a link to the |
---|
536 | original font file would be also a good idea. Try to do a little |
---|
537 | troublehooting and report its result. This not only would help with |
---|
538 | the fix but may also give you a temporary work-around for the bug. |
---|
539 | |
---|
540 | First, enable full warnings with option '-W99', save them to |
---|
541 | a file and read carefully. Sometimes the prolem is with a not implemented |
---|
542 | feature which is reported in the warnings. Still, reporting about such |
---|
543 | problems may be a good idea: some features were missed to cut corners, |
---|
544 | in hope that no real font is using them. So a report about a font using |
---|
545 | such a feature may motivate someone to implement it. Of course, you |
---|
546 | may be the most motivated person: after all, you are the one wishing |
---|
547 | to convert that font. ;-) Seriously, the philosophy "scrath your own itch" |
---|
548 | seems to be the strongest moving force behind the Open Source software. |
---|
549 | |
---|
550 | The next step is playing with the options. This serves a dual purpose: |
---|
551 | on one hand, it helps to localize the bug, on the other hand you may be |
---|
552 | able to get a working version of the font for the meantime while the |
---|
553 | bug is being fixed. The typical options to try out are: first '-Ou', if |
---|
554 | it does not help then '-Os', then '-Oh', then '-Oo'. |
---|
555 | They are described in a bit more detail above. Try them one by one |
---|
556 | and in combinations. See if with them the resulting fonts look better. |
---|
557 | |
---|
558 | On some fonts ttf2pt1 just crashes. Commonly that happens because the |
---|
559 | font being converted is highly defective (although sometimes the bug |
---|
560 | is in ttf2pt1 itself). In any case it should not crash, so the reports |
---|
561 | about such cases will help to handle these defects properly in future. |
---|
562 | |
---|
563 | We try to respond to the bug reports in a timely fashion but alas, this |
---|
564 | may not always be possible, especially if the problem is complex. |
---|
565 | This is a volunteer project and its resources are limited. Because |
---|
566 | of this we would appreciate bug reports as detailed as possible, |
---|
567 | and we would appreciate the ready fixes and contributions even more. |
---|
568 | |
---|
569 | CONTACTS |
---|
570 | -------- |
---|
571 | |
---|
572 | ttf2pt1-announce@lists.sourceforge.net |
---|
573 | The mailing list with announcements about ttf2pt1. It is a moderated mailing |
---|
574 | with extremely low traffic. Everyone is encouraged to subscribe to keep in |
---|
575 | touch with the current status of project. To subscribe use the Web interface |
---|
576 | at http://lists.sourceforge.net/mailman/listinfo/ttf2pt1-announce. |
---|
577 | If you have only e-mail access to the Net then send a subscribe request to |
---|
578 | the development mailing list ttf2pt1-devel@lists.sourceforge.net and somebody |
---|
579 | will help you with subscription. |
---|
580 | |
---|
581 | ttf2pt1-devel@lists.sourceforge.net |
---|
582 | ttf2pt1-users@lists.sourceforge.net |
---|
583 | The ttf2pt1 mailing lists for development and users issues. They have not |
---|
584 | that much traffic either. To subscribe use the Web interface at |
---|
585 | http://lists.sourceforge.net/mailman/listinfo/ttf2pt1-devel |
---|
586 | and http://lists.sourceforge.net/mailman/listinfo/ttf2pt1-users. |
---|
587 | If you have only e-mail access to the Net then send a subscribe request to |
---|
588 | the development mailing list ttf2pt1-devel@lists.sourceforge.net and somebody |
---|
589 | will help you with subscription. |
---|
590 | |
---|
591 | mheath@netspace.net.au |
---|
592 | Mark Heath |
---|
593 | |
---|
594 | A.Weeks@mcc.ac.uk |
---|
595 | Andrew Weeks |
---|
596 | |
---|
597 | babkin@users.sourceforge.net (preferred) |
---|
598 | sab123@hotmail.com |
---|
599 | http://members.bellatlantic.net/~babkin |
---|
600 | Sergey Babkin |
---|
601 | |
---|
602 | SEE ALSO |
---|
603 | -------- |
---|
604 | |
---|
605 | http://ttf2pt1.sourceforge.net |
---|
606 | The main page of the project. |
---|
607 | |
---|
608 | http://www.netspace.net.au/~mheath/ttf2pt1/ |
---|
609 | The old main page of the project. |
---|
610 | |
---|
611 | http://sourceforge.net/projects/gnuwin32 |
---|
612 | Precompiled binaries for Windows. |
---|
613 | |
---|
614 | http://www.lcdf.org/~eddietwo/type/ |
---|
615 | The home page of the Type 1 utilities package. |
---|
616 | |
---|
617 | http://www.rightbrain.com/pages/books.html |
---|
618 | The first book about PostScript on the Web, "Thinking in PostScript". |
---|
619 | |
---|
620 | http://fonts.apple.com/TTRefMan/index.html |
---|
621 | The True Type reference manual. |
---|
622 | |
---|
623 | http://partners.adobe.com/asn/developer/PDFS/TN/PLRM.pdf |
---|
624 | Adobe PostScript reference manual. |
---|
625 | |
---|
626 | http://partners.adobe.com/asn/developer/PDFS/TN/T1_SPEC.PDF |
---|
627 | Specification of the Type 1 font format. |
---|
628 | |
---|
629 | http://partners.adobe.com/asn/developer/PDFS/TN/5015.Type1_Supp.pdf |
---|
630 | The Type 1 font format supplement. |
---|
631 | |
---|
632 | http://partners.adobe.com/asn/developer/PDFS/TN/5004.AFM_Spec.pdf |
---|
633 | Specification of the Adobe font metrics file format. |
---|
634 | |
---|
635 | http://www.cs.wpi.edu/~matt/courses/cs563/talks/surface/bez_surf.html |
---|
636 | http://www.cs.wpi.edu/~matt/courses/cs563/talks/curves.html |
---|
637 | Information about the Bezier curves. |
---|
638 | |
---|
639 | http://www.neuroinformatik.ruhr-uni-bochum.de/ini/PEOPLE/rmz/t1lib/t1lib.html |
---|
640 | A stand-alone library supporting the Type1 fonts. Is neccessary |
---|
641 | to compile the programs other/cmpf and other/dmpf. |
---|
642 | |
---|
643 | http://www.freetype.org |
---|
644 | A library supporting the TTF fonts. Also many useful TTF programs |
---|
645 | are included with it. |
---|
646 | |
---|
647 | http://heliotrope.homestead.com/files/printsoft.html |
---|
648 | Moses Gold's collection of links to printing software. |
---|
649 | |
---|
650 | http://linuxartist.org/fonts/ |
---|
651 | Collection of font-related links. |
---|
652 | |
---|
653 | ---------------------------------------------------------------------- |
---|
654 | ---------------------------------------------------------------------- |
---|
655 | |
---|
656 | Following is the Readme of ttf2pfa (true type to type 3 font converter) It |
---|
657 | covers other issues regarding the use of this software. Please note that |
---|
658 | although ttf2pfa is a public domain software, ttf2pt1 |
---|
659 | is instead covered by an Open Source license. See the COPYRIGHT |
---|
660 | file for details. |
---|
661 | |
---|
662 | Please note also that ttf2pfa has not been maintained for a long time. |
---|
663 | All of its functionality has been integrated into ttf2pt1 and all the |
---|
664 | development moved to ttf2pt1, including Andrew Weeks, the author of |
---|
665 | ttf2pfa. Ttf2pfa is provided for historical reasons only. Please use |
---|
666 | ttf2pt1 instead. |
---|
667 | |
---|
668 | ---------------------------------------------------------------------- |
---|
669 | |
---|
670 | True Type to Postscript Font converter |
---|
671 | -------------------------------------- |
---|
672 | |
---|
673 | My mind is still reeling from the discovery that I was able to write |
---|
674 | this program. What it does is it reads a Microsoft TrueType font and |
---|
675 | creates a Postscript font. '_A_ postscript font', that is, not necessarily |
---|
676 | the same font, you understand, but a fair imitation. |
---|
677 | |
---|
678 | Run it like this: |
---|
679 | |
---|
680 | ttf2pfa fontfile.ttf fontname |
---|
681 | |
---|
682 | The first parameter is the truetype filename, the second is a stem for |
---|
683 | the output file names. The program will create a fontname.pfa containing |
---|
684 | the Postscript font and a fontname.afm containing the metrics. |
---|
685 | |
---|
686 | The motivation behind this is that in Linux if you do not have a |
---|
687 | Postscript printer, but only some other printer, you can only print |
---|
688 | Postscript by using Ghostscript. But the fonts that come with |
---|
689 | Ghostscript are very poor (they are converted from bitmaps and look |
---|
690 | rather lumpy). This is rather frustrating as the PC running Linux |
---|
691 | probably has MS-Windows as well and will therefore have truetype fonts, |
---|
692 | but which are quite useless with Linux, X or Ghostscript. |
---|
693 | |
---|
694 | The program has been tested on over a hundred different TrueType fonts |
---|
695 | from various sources, and seems to work fairly well. The converted |
---|
696 | characters look OK, and the program doesn't seem to crash any more. I'm |
---|
697 | not sure about the AFM files though, as I have no means to test them. |
---|
698 | |
---|
699 | The fonts generated will not work with X, as the font rasterizer that |
---|
700 | comes with X only copes with Type 1 fonts. If I have the time I may |
---|
701 | modify ttf2pfa to generate Type 1s. |
---|
702 | |
---|
703 | Copyright issues |
---|
704 | ---------------- |
---|
705 | |
---|
706 | I am putting this program into the public domain, so don't bother |
---|
707 | sending me any money, I'd only have to declare it for income tax. |
---|
708 | |
---|
709 | Copyright on fonts, however, is a difficult legal question. Any |
---|
710 | copyright statements found in a font will be preserved in the output. |
---|
711 | Whether you are entitled to translate them at all I don't know. |
---|
712 | |
---|
713 | If you have a license to run a software package, like say MS-Windows, on |
---|
714 | your PC, then you probably have a right to use any part of it, including |
---|
715 | fonts, on that PC, even if not using that package for its intended |
---|
716 | purpose. |
---|
717 | |
---|
718 | I am not a lawyer, however, so this is not a legal opinion, and may be |
---|
719 | garbage. |
---|
720 | |
---|
721 | There shouldn't be a any problem with public domain fonts. |
---|
722 | |
---|
723 | About the Program |
---|
724 | ----------------- |
---|
725 | |
---|
726 | It was written in C on a IBM PC running Linux. |
---|
727 | |
---|
728 | The TrueType format was originally developed by Apple for the MAC, which |
---|
729 | has opposite endianness to the PC, so to ensure compatibility 16 and 32 |
---|
730 | bit fields are the wrong way round from the PC's point of view. This is |
---|
731 | the reason for all the 'ntohs' and 'ntohl' calls. Doing it this way |
---|
732 | means the program will also work on big-endian machines like Suns. |
---|
733 | |
---|
734 | I doubt whether it will work on a DOS-based PC though. |
---|
735 | |
---|
736 | The program produces what technically are Type 3 rather than Type 1 |
---|
737 | fonts. They are not compressed or encrypted and are plain text. This is |
---|
738 | so I (and you) can see what's going on, and (if you're a Postscript guru |
---|
739 | and really want to) can alter the outlines. |
---|
740 | |
---|
741 | I only translate the outlines, not the 'instructions' that come with |
---|
742 | them. This latter task is probably virtually impossible anyway. TrueType |
---|
743 | outlines are B-splines rather than the Bezier curves that Postscript |
---|
744 | uses. I believe that my conversion algorithm is reasonably correct, if |
---|
745 | nothing else because the characters look right. |
---|
746 | |
---|
747 | Problems that may occur |
---|
748 | ----------------------- |
---|
749 | |
---|
750 | Most seriously, very complex characters (with lots of outline segments) |
---|
751 | can make Ghostscript releases 2.x.x fail with a 'limitcheck' error. It |
---|
752 | is possible that this may happen with some older Postscript printers as |
---|
753 | well. Such characters will be flagged by the program and there are |
---|
754 | basically two things you can do. First is to edit the .pfa file to |
---|
755 | simplify or remove the offending character. This is not really |
---|
756 | recommended. The second is to use Ghostscript release 3, if you can get |
---|
757 | it. This has much larger limits and does not seem to have any problems |
---|
758 | with complex characters. |
---|
759 | |
---|
760 | Then there are buggy fonts (yes, a font can have bugs). I try to deal |
---|
761 | with these in as sane a manner as possible, but it's not always |
---|
762 | possible. |
---|
763 | |
---|
764 | Encodings |
---|
765 | --------- |
---|
766 | |
---|
767 | A postscript font must have a 256 element array, called an encoding, |
---|
768 | each element of which is a name, which is also the name of a procedure |
---|
769 | contained within the font. The 'BuildChar' command takes a byte and uses |
---|
770 | it to index the encoding array to find a character name, and then looks |
---|
771 | that up in the font's procedure table find the commands to draw the |
---|
772 | glyph. However, not all characters need be in the encoding array. Those |
---|
773 | that are not cannot be drawn (at least not using 'show'), however it is |
---|
774 | possible to 're-encode' the font to enable these characters. There are |
---|
775 | several standard encodings: Adobe's original, ISO-Latin1 and Symbol |
---|
776 | being the most commonly encountered. |
---|
777 | |
---|
778 | TrueType fonts are organised differently. As well as the glyph |
---|
779 | descriptions there are a number of tables. One of these is a mapping |
---|
780 | from a character set into the glyph array, and another is a mapping from |
---|
781 | the glyph array into a set of Postscript character names. The problems |
---|
782 | are: |
---|
783 | 1) Microsoft uses Unicode, a 16-bit system, to encode the font. |
---|
784 | 2) that more than one glyph is given the same Postscript name. |
---|
785 | |
---|
786 | I deal with (1) by assuming a Latin1 encoding. The MS-Windows and |
---|
787 | Unicode character sets are both supersets of ISO-8859-1. This usually |
---|
788 | means that most characters will be properly encoded, but you should be |
---|
789 | warned that some software may assume that fonts have an Adobe encoding. |
---|
790 | Symbol, or Dingbat, fonts are in fact less of a problem, as they have |
---|
791 | private encodings starting at 0xF000. It is easy to just lose the top |
---|
792 | byte. |
---|
793 | |
---|
794 | Postscript fonts can be re-encoded, either manually, or by software. |
---|
795 | Groff, for example, generates postscript that re-encodes fonts with the |
---|
796 | Adobe encoding. The problem here is that not all characters in the Adobe |
---|
797 | set are in the MS-Windows set. In particular there are no fi and fl |
---|
798 | ligatures. This means that conversions of the versions of |
---|
799 | Times-New-Roman and Arial that come with MS-Windows cannot be used |
---|
800 | blindly as replacements for Adobe Times-Roman and Helvetica. You can get |
---|
801 | expanded versions of MS fonts from Microsoft's web site which do contain |
---|
802 | these ligatures (and a lot else besides). |
---|
803 | |
---|
804 | I deal with (2) by creating new character names. This can be error-prone |
---|
805 | because I do not know which of them is the correct glyph to give the |
---|
806 | name to. Some (buggy) fonts have large numbers of blank glyphs, all with |
---|
807 | the same name. |
---|
808 | |
---|
809 | (almost every TrueType font has three glyphs called .notdef, one of them |
---|
810 | is usually an empty square shape, one has no outline and has zero width, |
---|
811 | and one has no outline and a positive width. This example is not really |
---|
812 | a problem with well formed fonts since the .notdef characters are only |
---|
813 | used for unprintable characters, which shouldn't occur in your documents |
---|
814 | anyway). |
---|