laser-lovers@uw-beaver (laser-lovers) (08/08/84)
From Furuta@washington.arpa Tue Aug 7 15:54:22 1984 I get "OS6910 too much data on page" when trying to use a very small font. Anybody know exactly how much data is too much? By data, do they mean number of input characters, records, bits, output bits? The small font is actually an attempt at doing bitmap graphics by defining a font of all permutations of the pixels in a rectangle. The font I got the error with had one character equivalent to a 1 by 4 column where each pixel is represented by 2 by 2 dots. This yields a font of 16 characters, each one being 8 dots high and two dots wide (that comes out to 150 chars/inch horizontal by 37.5 lines/inch vertical). I can increase the size of a character by going to higher powers of 2 (I can always split the characters over several fonts up to the font memory limit). I can also live with making the pixels 3 by 3 or 4 by 4 dots. Will this approach solve my problem or do I have to go out and buy the Graphics option? Anybody have the graphics option? Lots of questions! A few answers would be greatly appreciated. [The 9700 -- good harware, poor software, c'mon "TEAM XEROX"!] Alan Crosswell Columbia University cc.alan@columbia-20.arpa -------
laser-lovers@uw-beaver (laser-lovers) (08/12/84)
From: "J. Spencer Love" <JSLove@MIT-MULTICS.ARPA> The complexity limits for a page in the x9700 can be outlined as follows: The entire page must fit in the CD buffer allocated for the purpose. The memory allocation scheme is such that you can only depend on using 22000 characters although there are a few more and you may get lucky depending on your record length. (For comparison purposes, consider the x9700 "4up" mode: 2 132x66 line printer pages on each side of the paper. That's 17424 characters per image assuming no overstrikes.) Each record uses the number of data characters in the record plus some overhead. However, there is another limit: the laser scans along the long axis of the page, and there can be only a certain (I'm afraid that specifying this exactly might be construed as violating the nondisclosure agreement I signed) number of hits against the font memory in a given scan line. Consequently, I recommend that you make characters which are 7 dots by one dot, and orient the 7 dot axis with the long axis of the paper. Then if your dots are at least 2x2 pixels in size you can at least cover the whole 11 inches of the page. With 2x2 pixels you can cover about 7 square inches, with 3x3 pixels you can cover about 15 square inches, and with 4x4 pixels you can cover 27 square inches. For this calculation I have ignored the per line overhead. Since there are 93.5 square inches on the page, judicious placement of the image is required. In addition, for sparse graphics, some elementary data compression techniques can be used. In your font, in addition to the 128 graphic characters, you should have solid black and solid white characters in a large number of width multiples (e.g., 2x7, 3x7, 4x7, 5x7, 6x7, 7x7, 8x7, 16x7, 24x7, 32x7, 64x7 at a minimum). In order to use the data compression scheme outlined above, and to minimize the effect of the per line overhead, I recommend that portrait mode characters be used. For dots that are at least 2x2, you shouldn't run into the various other limitations than record size and page buffer size. For dots that are at least 3x3, the record size limit (150) won't affect you in landscape mode. I realize that using characters which are 7 dots tall and one dot wide (in portrait mode) makes the programming a little wierd. I think that you'll find that you get the best results that way. If you want to experiment more with data compression, I suggest that you consider edges: In addition to solid white and black, there are 12 possible characters that consist of 2 regions, one white and one black. Throw in a few of these in width multiples as well. After all, the font can contain 112 data compression characters.