Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 UW 5/3/83; site uw-beaver
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!houxz!vax135!cornell!uw-beaver!laser-lovers
From: laser-lovers@uw-beaver (laser-lovers)
Newsgroups: fa.laser-lovers
Subject: Re: [US.ALAN%CU20B: Getting around X9700 error OS6910]
Message-ID: <1454@uw-beaver>
Date: Sun, 12-Aug-84 16:45:46 EDT
Article-I.D.: uw-beave.1454
Posted: Sun Aug 12 16:45:46 1984
Date-Received: Mon, 13-Aug-84 01:03:06 EDT
Sender: daemon@uw-beave
Organization: U of Washington Computer Science
Lines: 47

From: "J. Spencer Love" 
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.