|
|
1.1 root 1:
2: /*
3: *
4: * Some definitions and structure declarations used to manage the raster
5: * files (Imagen's format) and printer resident fonts.
6: *
7: * I've changed things a little from the way the raster tables were
8: * handled in di10. No RASTERLIST file is needed. If it doesn't exist the
9: * troff post-processor assumes every font can be printed in all the
10: * sizes listed in the DESC file. That wouldn't have been a realistic
11: * assumption for the old raster tables, but it's probably pretty
12: * good for the one's Imagen supplies. Anyway even if there are a
13: * few missing files we can always link them to ones we really want
14: * to use. While that may be a little less efficient, at least in terms
15: * of downloading glyphs and memory usage on the printer, I don't think
16: * it will be too bad as long as the raster files are fairly complete.
17: *
18: */
19:
20:
21: #include "impcodes.h" /* just for definition of ROT_COUNT */
22:
23:
24: /*
25: *
26: * Impress (version 1.9) restricts the families that we can define to
27: * the range 0 to 95. MAXFAMILY is the upper limit of the range and
28: * should not be changed unless this limit is removed. Family members are
29: * also restricted and must lie between 0 and 127. Don't ever change the
30: * value of MAXMEMBER as defined below.
31: *
32: */
33:
34:
35: #define MAXFAMILY 95 /* most families we can ever use */
36: #define MAXMEMBER 255 /* largest member in any family */
37:
38:
39: /*
40: *
41: * L_FNAME is the maximum length of the font name string stored in
42: * in field name[] below. It probably should agree with the size of
43: * array namefont[] as defined in troff'd dev.h structure.
44: *
45: */
46:
47:
48: #define L_FNAME 10 /* longest allowed font name + 1 */
49: #define MAX_SIZES 20 /* only used in Sizedata */
50:
51:
52: /*
53: *
54: * You can change any of the next three definitions to suit your own
55: * setup. They're only limits on array sizes used to keep track of
56: * font data.
57: *
58: */
59:
60:
61: #define MAXRESIDENT 20 /* most resident fonts we'll handle */
62: #define MAXFAMTAB 5 /* limit on family tables per font */
63: #define MAXFONTS 100 /* limit on total number of fonts */
64:
65:
66: /*
67: *
68: * We'll have to keep track of some extra stuff for printer resident
69: * fonts. Obviously we'll need its name but as it happens we'll also
70: * need to know the family table that should be used with each font.
71: * It's a shame that things have to be so complicated. If the characters
72: * in the resident fonts could all be accessed using codes 0 to 127
73: * then map 0 and the font tables would suffice. Anyway it doesn't
74: * turn out that way, at least not as far as I can figure, and so we'll
75: * need some rather complicated member maps and family tables. All this
76: * stuff is handled by the routines in file res.c.
77: *
78: */
79:
80:
81: typedef struct {
82:
83: char name[L_FNAME]; /* name of the resident font */
84: int count; /* number of table entries below */
85:
86: struct { /* family tables for each font */
87: int map; /* use this map */
88: char name[L_FNAME]; /* with this resident font */
89: } table[MAXFAMTAB];
90:
91: } Resdata;
92:
93:
94: /*
95: *
96: * As I mentioned earlier no RASTERLIST file is needed, but it can be
97: * used. We also may have to deal with printer resident fonts and may
98: * have to keep track of font size data for these guys. The following
99: * data structure is used to manage raster size data in dimpress.
100: *
101: */
102:
103:
104: typedef struct {
105:
106: char name[L_FNAME]; /* internal font name */
107: int sizes[MAX_SIZES]; /* available sizes */
108:
109: } Sizedata;
110:
111:
112: /*
113: *
114: * The rastdata structure is used to keep track of which raster files
115: * have already been read into memory. If rst isn't NULL then we assume
116: * it points to a block of memory containing the raster file *name.size.
117: * Note that *name probably won't be the name of the font troff is using,
118: * but rather it's the name of the raster file that we want to use.
119: * It's filled in from the namefont[] string stored in the appropriate
120: * binary font file - at least that's the way it will be done in the
121: * troff post-processor. That being the case we need to make sure that
122: * L_FNAME and the size of namefont[] as defined in dev.h agree.
123: *
124: * I've added glyph rotation information to Rastdata. We'll really only
125: * need to keep track of family numbers and chused bit maps for each
126: * allowed orientation. Actually we can probably expect that troff
127: * jobs will only use a single orientation for each job, but that's
128: * definitely not the case for any kind of graphics preprocessor.
129: *
130: */
131:
132:
133: typedef struct {
134:
135: int size; /* point size that's been read in */
136: int first; /* first character number */
137: int last; /* number of the last character */
138: int mag; /* font magnification times 1000 */
139: int glyphdir; /* glyph directory offset */
140: int *advance; /* downloaded this as the advance */
141: char name[L_FNAME]; /* name of font's raster file */
142: char *rst; /* pointer to font's RST file */
143: int fam[ROT_COUNT]; /* Impress family number */
144: unsigned char *chused[ROT_COUNT]; /* bit indexed; 1 if downloaded */
145:
146: } Rastdata;
147:
148:
149: /*
150: *
151: * Imagen's raster file format is described in the Imprint-10 Programmer's
152: * Manual that I got with our original printer (back in 1982). Although
153: * that described a Version 0 system it's the best info I've got right
154: * now so that's what I'll use.
155: *
156: * The raster files all contain 4 sections called the file mark, the
157: * preamble, the glyph directory, and the raster data section. We're
158: * really only concerned with the last 3. The preamble describes some
159: * general information about the font. One of the most important
160: * fields, at least the way I've written things, is the pointer to
161: * the glyph directory. It begins at offset 11 and is 3 bytes long.
162: * That's what we'll use to get to the glyph directory, which contains
163: * specific data about each of the characters represented in the
164: * raster file. Each entry in the glyph directory is 15 bytes long.
165: * Knowing the number of the character that we want to print and the
166: * pointer to the start of the glyph directory lets us locate that
167: * character's entry in the glyph directory. The raster data section
168: * starts at the end of the glyph directory and contains the bitmaps
169: * used to print the characters represented in the file. Each character's
170: * entry in the glyph directory has a pointer to the start of it's
171: * bitmap in the raster data section, along with enough other data
172: * so we can figure out where the bitmap ends.
173: *
174: * To use Imagen's raster files we need to be able locate a particular
175: * field and then decode it. That means we need to be able to get the
176: * field's offset from the beginning of the file and then determine how
177: * many bytes are used by the field. The main tool I'll be using is a
178: * structure called Rst (defined below). There will be one associated
179: * data structure for the preamble and the glyph directory. The declaration
180: * and initialization of these Rst arrays is handled in file rast.c
181: * using the definitions given here.
182: *
183: * I'll begin by giving the Rst structure and a few other associated
184: * definitions. The definitions are used to classify field types, while the
185: * the Rst structure is designed to enable us to pick fields out of a given
186: * raster file once it's been read into memory. size is the size in bytes
187: * of each field, offset is where it starts, usually relative to the
188: * beginning of the raster file. If glyphdir is TRUE then the field is
189: * in the glyph directory and we'll need to add in the directory's offset
190: * before we get to the right place. type describes the field and allows
191: * us to decode it properly. Most fields will be unsigned, although glyph
192: * reference points are signed integers. strings are a little tougher but
193: * we really don't need them, at least not right now, so I'll ignore them.
194: * They're all variable length and are only found in the preamble. They
195: * could be handled by letting offset field point to the first string and
196: * the size field be the number of strings that preceed the one we're
197: * looking for. Imagen encodes strings a little differently than we're
198: * used to. They're not terminated by '\0', but rather the first byte
199: * in each string gives the number of bytes in the rest of the string.
200: *
201: */
202:
203:
204: #define INTEGER 0
205: #define UNSIGNED 1
206: #define STRING 2
207:
208:
209: typedef struct {
210:
211: int size; /* bytes used by the field */
212: int offset; /* field's offset */
213: int type; /* STRING, INTEGER, or UNSIGNED */
214: int glyphdir; /* add in directory offset? */
215:
216: } Rst;
217:
218:
219: /*
220: *
221: * Next we'll need a few definitions that go with the preamble. The
222: * first set, ie. the ones beginning with the characters P_ are
223: * indices into the Rst array rst[] (defined in rast.c), where we can
224: * locate size and offset information about a particular field. There's
225: * really no need to ever change any of this stuff - all it has to do is
226: * agree with the way RST_INIT is defined. RST_INIT is used in rast.c
227: * to do the initialization of the Rst array that's used to define raster
228: * structures.
229: *
230: */
231:
232:
233: #define P_LENGTH 0 /* length of the preamble - bytes */
234: #define P_VERSION 1 /* format version number */
235: #define P_GLYDIR 2 /* pointer to glyph directory */
236: #define P_FIRSTGLY 3 /* number of first glyph in font */
237: #define P_LASTGLY 4 /* same but for last glyph */
238: #define P_MAG 5 /* font magnification */
239: #define P_SIZE 6 /* design size of the font */
240: #define P_LINESP 7 /* interline spacing */
241: #define P_WORDSP 8 /* interword spacing */
242: #define P_ROT 9 /* rotation of the font */
243: #define P_CHADV 10 /* character advance direction */
244: #define P_LINEADV 11 /* line advance direction */
245: #define P_CHECK 12 /* check identifier */
246: #define P_RES 13 /* font resolution */
247: #define P_IDENT 14 /* font identifier string */
248: #define P_FACE 15 /* font type face encoding - string */
249: #define P_DEVICE 16 /* intended output device - string */
250: #define P_CREATOR 17 /* creator of the file - string */
251:
252:
253: /*
254: *
255: * We'll need to do the same kind of thing for the glyph directory entries.
256: * The next set of definitions all begin with G_ and define the positions
257: * in the Rst array where we can find size, offset, type, and glyphdir
258: * information for each of the fields. Again remember these are just array
259: * indices that need to agree with the way RST_INIT is defined.
260: *
261: */
262:
263:
264: #define G_HEIGHT 18 /* pixel height of raster image */
265: #define G_WIDTH 19 /* pixel width of raster image */
266: #define G_YREF 20 /* y reference point */
267: #define G_XREF 21 /* x reference point */
268: #define G_CHWIDTH 22 /* character width in fix units */
269: #define G_BPTR 23 /* pointer to raster data */
270:
271:
272: /*
273: *
274: * I've already mentioned RST_INIT, which is used in rast.c to initialize
275: * the Rst array. It's definition is given next and it needs to agree with
276: * the P_ and G_ definitions just given. In otherwords the data describing
277: * field P_XXX really better be in position rst[P_XXX] or things will
278: * really get messed up.
279: *
280: */
281:
282:
283: #define RST_INIT \
284: \
285: { \
286: { 2, 8, UNSIGNED, FALSE }, /* P_LENGTH */ \
287: { 1, 10, UNSIGNED, FALSE }, /* P_VERSION */ \
288: { 3, 11, UNSIGNED, FALSE }, /* P_GLYDIR */ \
289: { 2, 14, UNSIGNED, FALSE }, /* P_FIRSTGLY */ \
290: { 2, 16, UNSIGNED, FALSE }, /* P_LASTGLY */ \
291: { 4, 18, UNSIGNED, FALSE }, /* P_MAG */ \
292: { 4, 22, UNSIGNED, FALSE }, /* P_SIZE */ \
293: { 4, 26, UNSIGNED, FALSE }, /* P_LINESP */ \
294: { 4, 30, UNSIGNED, FALSE }, /* P_WORDSP */ \
295: { 2, 34, UNSIGNED, FALSE }, /* P_ROT */ \
296: { 1, 36, UNSIGNED, FALSE }, /* P_CHADV */ \
297: { 1, 37, UNSIGNED, FALSE }, /* P_LINEADV */ \
298: { 4, 38, UNSIGNED, FALSE }, /* P_CHECK */ \
299: { 2, 42, UNSIGNED, FALSE }, /* P_RES */ \
300: { 0, 44, STRING, FALSE }, /* P_IDENT */ \
301: { 1, 44, STRING, FALSE }, /* P_FACE */ \
302: { 2, 44, STRING, FALSE }, /* P_DEVICE */ \
303: { 3, 44, STRING, FALSE }, /* P_CREATOR */ \
304: { 2, 0, UNSIGNED, TRUE }, /* G_HEIGHT */ \
305: { 2, 2, UNSIGNED, TRUE }, /* G_WIDTH */ \
306: { 2, 4, INTEGER, TRUE }, /* G_YREF */ \
307: { 2, 6, INTEGER, TRUE }, /* G_XREF */ \
308: { 4, 8, UNSIGNED, TRUE }, /* G_CHWIDTH */ \
309: { 3, 12, UNSIGNED, TRUE } /* G_BPTR */ \
310: }
311:
312:
313: /*
314: *
315: * It turns out to be convenient to be able to gather all the important
316: * glyph information together in a single place. The Glyph structure
317: * includes all the important data a glyph.
318: *
319: */
320:
321:
322: typedef struct {
323:
324: int xref; /* reference point */
325: int yref;
326: int width; /* bitmap dimensions */
327: int height;
328: int advance; /* move this far after printing */
329: char *bptr; /* character's bitmap */
330:
331: } Glyph;
332:
333:
334: /*
335: *
336: * In order to locate a particular glyph's entry in the glyph directory
337: * we'll need to know the pointer to the start of the directory and the
338: * size of each glyph entry in the directory. It's clear from the definition
339: * of RST_INIT that this size, at least right now, is 15 bytes. The size
340: * is simply size+offset of the last field, which in this case is G_BPTR.
341: * The pointer to glyph n's entry is given by,
342: *
343: * DirPtr + ((n - fg) * 15)
344: *
345: * where DirPtr is the pointer to the start of the directory and fg is the
346: * number of the first glyph in the directory (usually 0). The following
347: * macro is used in rast.c to get the entry pointer for each glyph.
348: *
349: */
350:
351:
352: #define GLYPH_PTR(A) \
353: \
354: (fam->glyphdir + ((A - fam->first) * 15))
355:
356:
357: /*
358: *
359: * A lot of the numbers in Imagen's raster tables are given in units called
360: * a fix, where 2**20 fixes are equal to a point. The next macro can be used
361: * to convert fix units to inches.
362: *
363: */
364:
365:
366: #define FIX(A) \
367: \
368: ((float) A / ((01 << 20) * 72.27))
369:
370:
371: /*
372: *
373: * The character width for glyphs in Imagen's raster tables are stored in
374: * fix units without font magnification figured in. The following macro
375: * takes a fix width and converts it to a pixel width.
376: *
377: */
378:
379:
380: #define PIXEL_WIDTH(A, B) \
381: \
382: (int) ((FIX(A) * fam->mag * B) / 1000.0 + 1.0)
383:
384:
385: /*
386: *
387: * The raster tables we're using are assumed to have been prepared for
388: * printing at resolution RAST_RES. The data is supposedly already in each
389: * of the raster files as field P_RES, but I'm not positive the value is
390: * right. Everything except that field seems to indicate that the raster
391: * tables are meant to be printed at 300 dots per inch.
392: *
393: */
394:
395:
396: #define RAST_RES 300
397:
398:
399: /*
400: *
401: * Finially a few external definitions that will be needed by programs
402: * that deal with Imagen's raster files. They're all declared in rast.c.
403: *
404: */
405:
406:
407: extern Rst rst[]; /* raster file structure info */
408:
409: extern Rastdata fam_data[]; /* data on raster files we've read */
410: extern Rastdata *fam; /* &fam_data[cur_fam] */
411: extern int next_fam; /* next available family number */
412: extern int cur_fam; /* family we're using right now */
413: extern int last_fam; /* last family we told printer about */
414: extern int rast_res; /* raster table resolution */
415:
416: extern unsigned getvalue();
417:
418:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.