Apparatus for Producing Photographic Slides

The present invention concerns apparatus for automatically generating photographic pictures, such as 35 mm slides, containing text and/or graphics arranged in one of a number of standard formats. Such pictures (slides) are useful, for example, as visual aids in presentations at business conferences and the like.

The conventional technique for producing a 35 mm slide containing text and artwork is to create a "mechanical" or mockup of the slide on a board using typeset or rub-on characters for text and manually produced graphics such as organization charts, pie charts, line graphics and the like. Such mechanicals are made by artists who may work in an independent graphic arts company, or in an art department within a large corporation. After the first mechanical is produced in accordance with the instructions of the slide "customer"--the person requesting the slide who is normally one and the same as the person who will use the slide at a presentation - a proof copy of the slide is shown to the customer and normally modified in some way to more exactly meet his specific requirements and taste. When the mechanical, as modified, has been approved by the customer, it is photographed and one or more 35 mm slides are produced.

This conventional mode of producing a slide requires a considerable amount of the time of a skilled artist, even with the various tools of the trade at his disposal. For a typical slide made in this manner, an artist may take an average of 35 minutes to produce the mechanical. Thereafter, it is necessary to transport the proof copy to the slide customer one or more times for his revision and eventual approval so that the entire process, from the time a customer makes his initial request to the time the mechanical is approved, may take several days.

A number of systems have been devised to automate this process of producing business graphics which are then photographed to produce 35 mm slides. For example, software "modules" have been written for time-sharing systems to produce line drawings. In a typical time-sharing system, teletypewriters are used as remote input/output devices for a large central computer which calls up and executes a number of programs "on line" for several users on a time-sharing basis. The teletypewriters may also be used purely as input devices to supply data and instructions to the central computer.

One known service for producing graphical representations in a time-sharing system is marketed by National CSS, 542 Westport Avenue, Norwalk, Conn. 06851. This service, called "Graphics/CSS", is capable of producing black and white line-drawn plots ranging from bar charts, pie charts, line graphs and the like of the type used in business presentations to complex three-dimensional functions, such as are used in mathematics, product design and cartography. The graphs and charts for business presentations, which may include text, are produced using a software package called "Tel-A-Graph" which is designed for the non-programmer. Tel-A-Graph operates in the interactive mode, asking questions of the user at a remote teletypewriter. The answers to these questions, which are entered by the user, define the particular graphical representation with selected characteristics.

The Tel-A-Graph graphic producing facility does not permit the user to see the graphics until the final product is generated and imaged at the central computer. It produces a line drawing which is not in color. In addition, it requires an extended two-way transmission over telephone lines since the questions originate at the central computer.

Another system for automatically producing 35 mm slides, called "Genigraphics", has been developed by General Electric Company, Court Street Plant, Syracuse, N.Y. 13201. The Genigraphics system includes a dedicated minicomputer with a disk drive connected to a "console" comprising a low resolution color CRT and manual controls permitting a skilled operator to compose a picture. The console displays the exact picture (or any blown-up portion thereof) to be produced as a slide (i.e., with identical type size, fonts, and colors) but with reduced resolution. Once the picture is composed to the satisfaction of the operator, the raster data contained on the disk file is applied to a high-resolution CRT and photographic station where the picture is imaged and photographed to create the 35 mm slide. If desired, this raster data may be transmitted over telephone lines to a Genigraphics system at another location, so that the slide may be produced and picked up at that location.

So far as is known, the Genigraphics minicomputer is capable of supporting the operation of only one console at a time so that an entire machine is "tied up" by a single operator who is capable of producing an average of perhaps one picture every ten minutes. Since the console is relatively complex, and since the data defining the picture is generally entered directly by the operator using analog controls, rather than as answers to questions in an interactive mode, the Genigraphics operator must receive extensive training prior to using the machine. Furthermore, the machine is expensive to purchase so that its cost may only be justified in large graphic arts facilities which have sufficient volume to keep the machine in operation throughout the day.

It is an object of the present invention to provide a computer-based system for producing photographic pictures, such as 35 mm slides, (1) which is capable of generating an instant proof or mock-up of the picture (slide) without expensive specialized equipment (as in the Genigraphics system) and (2) which is capable of producing high resolution pictures (slides) in rapid succession without the requirement of extensive two-way dialog with a large-scale computer (as in the "Graphics/CSS" system).

This object, as well as further objects which will become apparent from the discussion that follows, are achieved, according to the present invention, by means of a system comprising a number of microcomputer terminals at scattered locations, a central computer at a location remote from these terminals and picture producing means for creating photographic pictures from computer generated data. The microcomputer terminals are each provided with a color display and input means for enabling the user to enter data. The terminals are programmed to generate and display in color a number of standard graphical representations having certain variable characteristics. A particular representation and its characteristics are entered by users through the terminal input as answers to questions presented by the terminal. The terminals are capable of modifying the display of a graphical representation in response to user entries which change the prior answers to the questions so as to create a set of final answers. When a graphical representation is complete, to the satisfaction of the user, data representing the user's final answers are transmitted from the terminals to the central computer. The central computer is programmed to generate data defining the raster from the information for a color CRT data representing the user's final answers. This raster data defines a graphical representation with enhanced resolution over that generated and displayed by the terminal. Finally, the picture producing means creates photographic pictures (slides) from the higher resolution raster point data generated by the central computer.

As used hereinafter, the term "slide" is intended to refer specifically to 35 mm photographic slides and, in general, to other types of photographic pictures, including prints, which may be photographically processed or developed from a latent image or negative.

The foregoing and other features of the present invention will be more readily apparent from the following detailed description and drawings of an illustrative embodiment of the invention in which:

FIG. 1 is a block diagram of the overall system;

FIG. 2 is a flow chart for the program used in the slide generating terminal;

FIG. 3 is a layout for a box chart;

FIG. 4 is a flow chart of the create section of the flow chart of FIG. 2 for a box chart program;

FIG. 5 is a flow chart of the display section of the flow chart of FIG. 2 for a box chart program;

FIGS. 6A, 6B, 6C and 6D are flow charts of the modify section of the flow chart of FIG. 2 for a box chart program;

FIG. 7 is a table showing the organization of the slide specification data generated by the slide terminal;

FIGS. 8A and 8B are box chart slides created according to the invention as displayed at the terminal and as a finished slide, respectively;

FIG. 9 is a text slide created according to the invention;

FIG. 10 is a vertical bar chart slide created according to the invention;

FIG. 11 is a horizontal bar chart slide created according to the invention;

FIG. 12 is a line graph slide created according to the invention;

FIG. 13 is a tabular text chart slide created according to the invention;

FIG.14 is a pie chart slide created according to the invention;

FIG. 15 is a diagram showing the card image input for a number of slides;

FIG. 16 is a diagram showing a portion of the card image input for a slide;

FIG. 17 is a flow chart showing the process used in creating a font library;

FIG. 18 illustrates the data format used to define a single symbol;

FIG. 19 is a diagram showing three typical symbols positioned in relation to a base line;

FIG. 20 is a diagram showing the character "C" arranged in a character space;

FIG. 21 shows a two-byte word used in the string-format data defining a symbol;

FIG. 22 shows the character "B" arranged in a character space which is scanned at line L;

FIG. 23 shows four words of string-format data defining the symbol segments on scan line L of FIG. 22;

FIG. 24 illustrates the manner in which two characters "L" and "T" are kerned;

FIG. 25 is a flow chart showing the program modules in the slide computation;

FIG. 26 is a flow chart for the program module "INITIALIZATION";

FIG. 27 is an illustration of an inset graphic pattern;

FIG. 28 is an illustration of triangular graphic patterns;

FIG. 29 is an illustration of grid line graphic patterns;

FIG. 30 is an illustration of bar graphic patterns;

FIG. 31 is an illustration of a circular pie graphic pattern;

FIG. 32 is an illustration of a slide containing straight line segments;

FIG. 33 is an illustration of a slide containing grid axes;

FIG. 34 is an illustration of a slide containing a symbol;

FIG. 35 is an illustration of a slide containing grid lines, bars and grid axes;

FIG. 36 is a flow chart for the program module "INPUT";

FIG. 37 is a flow chart of a representative subroutine of the program module "INPUT";

FIG. 38 is a flow chart for the program module "TYPE-SET";

FIGS. 39A and 39B are representative subroutines of the program module "TYPE-SET";

FIG. 40 is a flow chart for the program module "PROCESS";

FIG. 41 is a diagram showing how the program module PROCESS composes a scan line;

FIGS. 41A-41F are diagrams showing portions of the diagram of FIG. 41;

FIG. 42 shows the format of a two-byte word containing raster data in a scan line;

FIG. 43 is a flow chart for the program module "OUTPUT";

FIG. 44 shows a two-byte word containing ones and zeros in the bit positions indicated in the word of FIG. 42;

FIG. 45 shows three words containing the red, green and blue color intensity information for the raster points identified in the word of FIG. 44; and

FIG. 46 is a block diagram of a color film recorder.

The preferred embodiments of the photographic picture generating apparatus according to the present invention will now be described in connection with FIGS. 1-46 of the drawings. In order to simplify this description, and to facilitate access to any specific item of information, the subject matter has been organized into numbered titles and sub-titles; these are set forth in the "Table of Contents" below:

The slide producing apparatus according to the present invention may comprise components which are specifically "hard wired" or otherwise dedicated, for example by means of firmware, to the specific tasks assigned to them. Preferably, however, each of the components of the system is an "off the shelf" commercially available unit which may be leased or purchased, programmed to carry out the desired functions, and connected together in the manner hereinafter described. In this way, these individual units may be utilized for purposes other than as components of the system according to the present invention, when they are not needed for use in the system.

FIG. 1 shows the preferred embodiment of the system according to the present invention, in which each of the components or elements of the system are currently commercially available. The system comprises a number of microcomputer display terminals 50 each having a color display 52 and an input means such as a keyboard 54 and a floppy mini-diskette read/write unit 56.

A microcomputer display terminal suitable for use in this system is manufactured by Intelligent Systems Corp., 5965 Peachtree Corners E., Norcross, Georgia 30071. This machine is called the "Intecolor 8051 Desk Top Computer" and comes with a variety of options. In the configuration used in the system, it has a "dual floppy mini-diskette", two additional 8K RAM boards and a special keyboard with individual color keys. The machine comes equipped with operating system software provided by ISC and is capable of being programmed, in accordance with the present invention, to generate and display in color a plurality of standard graphical representations or "types" of slides which may be produced by the system. Because of the limited memory space in the terminal, there is a separate program for every type of slide. Some of the preferred types of slides frequently used in business presentations are as follows:

(1) Organizational charts and flow charts;

(2) Various kinds of text formats;

(3) Vertical bar charts;

(4) Horizontal bar charts;

(5) X-Y graphs showing line functions or areas;

(6) Tabular text charts;

(7) Pie charts.

As numerous other types of slides will occur to persons skilled in the art, the invention is not limited to any specific type or set of types.

Each separate program for a specific type of slide is stored on a floppy mini-diskette. When a user wishes to create a slide, he selects the diskette containing the program for the type of slide he desires, inserts it into one slot of the read/write unit 56, and reads the entire program into the microcomputer memory. Before commencing, the user also places a blank mini-diskette into the other slot of the read/write unit. However, it is also possible to use a single mini-diskette if the program is small enough to permit the output to be written on the same mini-diskette.

The microcomputer display terminal is now programmed to generate and display in color the selected standard graphical representation or "type" of slide.

The user then proceeds to interactively create a "slide specification" which will become the input data for the actual picture computation at a later time. When complete, the slide specification is written onto the blank mini-diskette to form a compact data file. The microcomputer terminal uses the slide specification to generate a coarse raster display which corresponds closely in appearance to a finished slide.

Each of the programs used to produce the various standard graphical representations initiates a question and answer exchange with the user which produces initial slide specification data such as the position of lines in a chart; the identity, font and size of text; colors, etc. Thereafter, the terminal generates a display from the current slide specification and permits the user to change individual attributes thereof. For example, after seeing the initial display, the user may wish to change the type size or color of certain text to improve the appearance of the picture. This modification effectively changes the answers to the questions presented by the terminal to create a final slide specification. Some of the features of the slide are invariable during its initial creation, but can be changed during the modification procedure, e.g., drop shadows, insets, etc.

Once the slide specification data representing the user's final answers has been written onto a mini-diskette, this data must be transmitted in some way to a central computer for generation of the fine picture raster data required to produce the slide. A number of communication techniques may be used for this purpose:

(1) The mini-diskette may be mailed or delivered by messenger to the location of the central computer.

(2) The data may be transmitted over regular telephone lines directly to the location of the central computer.

(3) The data may be transmitted over telephone lines in a time-sharing network and stored in a time-sharing computer. At periodic intervals the time-sharing computer may be polled and all the accumulated data sent over telephone lines to the location of the central computer.

The last type of system is illustrated in FIG. 1. In this configuration, the microcomputer terminals 50 supply data to standard telephones 58 at relatively slow speed (300 Baud). This data is transmitted over telephone lines 60 of a time-sharing network to the large scale computer 62 of the time-sharing system. This computer simply serves as a temporary storage facility so that data from various terminals may be collected and subsequently retransmitted in batches to the slide producing facility. The time-sharing computer may contain a formating program to convert data to a different format, if desired, and a clerical program to keep track of the time-sharing system activity and maintain a record or file of the slide specifications received. Upon request, or at specified times during the day, the time-sharing computer sends the accumulated data at high speed (4,800 Baud) over regular telephone lines 64 to the slide producing facility.

Existing well-known time-sharing systems, suitable for use with the system of the present invention, are Boeing Computer Services, Inc. (BSC), National CSS and University Computing (UCC).

Whether the data is transmitted by the time-sharing system, or transmitted directly over regular telephone lines, this data is received by a sender/receiver modem 66 and passed to a minicomputer 68. A modem suitable for use in the system is available from General Data Communications, Kennedy Avenue, Danbury, Connecticut 06810. A suitable minicomputer is available from Minicomputer Systems, 525 Executive Boulevard, Elmsford, N.Y. 10523 under the tradename "Micos-Mini". The modem and minicomputer are plug compatible and may be connected directly together. It is also possible, however, to go directly to a large scale computer that receives the data, makes the necessary calculations and drives a color slide recorder.

The purposes of the minicomputer are (1) to collect and store the slide specification data on a disk file, (2) to convert the data to a format acceptable to the particular computer which is used for generating the high resolution picture raster data, and (3) to write this converted data onto a magnetic tape. The minicomputer may also contain a clerical program which creates and maintains a file for accounting purposes.

The magnetic tape, which may contain the slide specifications for hundreds of slides, is read by a large scale computer 70 such as an IBM 360/75. This computer performs the detailed computation necessary to generate the data defining the picture raster points for each slide. Alphanumeric characters and other useful symbols such as logos and the like are accessed by the computer, as needed, from a symbol library 72 maintained on a disk file. The computer composes the picture by placing the selected characters, boxes, bars and the like in their respective proper positions; computes the raster data for each successive horizontal scan line and writes this data, in run-length encoded format, onto a magnetic tape. In the preferred embodiment, the picture raster is 1344 elements high by 2016 elements wide. This raster has a height to width ratio of 2/3 which is the same as that for a slide.

Finally, the magnetic tape generated by the computer 70 is supplied to a digital color recorder 74 to produce the slide. This device comprises a high resolution CRT, a color wheel containing red, green and blue filters, and a photographic camera arranged to view the CRT screen through the filters. The raster data contained on the magnetic tape is used to control the CRT and color wheel for each color picture taken by the camera. After a sequence of pictures are taken by the camera the exposed film is removed and processed photographically to produce the color slides.

A picture imaging and photography unit suitable for use in the system according to the present invention is available from Constantine Electronics Company, 70 Constantine Drive, Mahwah, N.J. 07430 under the model designation "Celco CFR 2000".

The microcomputer display terminals 50 may be any type of microcomputer with a color display, but the preferred terminal is the Intecolor 8051 Desk Top Computer with a dual floppy mini-diskette drive 56, two additional 8K random access memory (RAM) boards and a special keyboard 54 with individual color keys. The Intecolor computer has several internal PLOT programs that allow for the display of graphic information on the CRT display 52 with a resolution of 160.times.192 elements. These PLOT programs are firmware programs in the sense that they are stored in read only memories (ROM's) and are used with the programs that create and display a rough approximation of a slide on the CRT.

For each basic type of slide there is a separate program. Examples of these basic slides and programs are as follows:

The programs themselves all have the form shown in FIG. 2. A program arrangement of this sort operates in an interactive manner; i.e., the program will ask for a command or the answer to a question and will complete some operation in response to the answer. It will then ask for the next command or ask the next question. Because of the interaction, the system is easy to use and the results are easily modified.

In operation the first part of the terminal programs is an initialization section 100, which initializes the system by setting the values of certain constant parameters. This data will depend on the basic slide program chosen. After initialization the program moves to a command interpreter section 102. In this section the computer will ask the user what he wants to do. This is done by the computer printing a question on the CRT display in one color and waiting for the user to type in the answer on the keyboard. The user's answer is displayed on the CRT in a different color. The colors chosen for this are set up during the initialization steps.

At this point the user can type in the code "CRE" for a create section 104 of the program that allows for the creation of a new slide. Alternatively, the user could call up the slide specification data of a previously generated slide that is stored on one of the disks. This is done with the command "GET" which accesses a "get slide data" portion 116 of the program. The create section of the program asks the user a series of questions about the slide he wants. Once this has been completed the program returns to the command interpreter section 102 and asks for the next command. In order to get a rough idea of what the finished slide will look like, whether it is newly created or retrieved from a disk file, the user can type in the command "DIS" and the program will branch to a display section 106. The routine in section 106 uses the internal PLOT functions in the Intecolor computer and the answers to the questions in the create section or the retrieved slide data to plot an approximation of the slide on the CRT display. Once the display is completed the program again returns to the interpreter section for a new command.

It is likely that the user would not be satisfied with the first arrangement selected for the slide. To make the desired changes he would type in "MOD" which directs the computer to a modify section 108 of the program. This section is like the create section 104 in that it asks the user a series of questions concerning the modifications he would like. Also, like the create section, this section returns to the command interpreter section once it has been completed. By again typing in the display code, i.e., DIS, a modified approximation to the finished slide is displayed.

A system of identifying the user and the slide makes use of an identify section 110 of the program that is addressed with the command "IDE". This section is interactive and questions the user about his identity and the designation of the slide. A color tabulate section 112 of the program allows the user to assign any one of the 64 colors available in the high resolution slide making device 74 of FIG. 1 to any one of the 8 colors available at the terminal. The 64 colors have a code number associated with them and program section 112 requests that the user supply a code number for each of the 8 basic colors used at the terminal.

If the last version of the slide is acceptable the user can enter a save code, "SAV", which will send the program to a "save slide data" section 114 of the program. This program section stores the data specifying the slide on one of the disk files. The slide specification data is in compressed form and appears in the arrangement shown in FIG. 7. This data is all that is needed to control the creation of a high resolution slide. Typically the data file of FIG. 7 has 400-500 characters with each character transmitted as an 8 bit binary word, i.e., a typical complete slide specification has 4,000 bits of data. However, the final high resolution slide machine creates a picture with 1344.times.2016 picture elements having any one of 64 colors (6 binary bits) thus representing 16,257,024 binary data bits. Hence it can be seen that the data of FIG. 7 represents a significant compaction of the slide data. As a result there is very little time used in transmitting this data over a time-sharing system and, consequently, there is a cost savings to the user. Also it should be noted that no time-sharing facilities are used during the creation of the slide data.

Any of the various basic slides shown in FIGS. 8-14 and others, can be generated by using programs of the type shown in FIG. 2. Creation of such programs is well within the ability of a programmer skilled in the art if the manual supplied with the Intecolor computer is used and the flow chart of FIG. 2 is studied. Nevertheless, by way of example a typical program for generating an organization chart will be explained with reference to the flow charts of FIGS. 2 and 4-6 along with the variable and array identification of Appendix 6.1, and the program listing of Appendix 6.2.

FIG. 3 shows a layout for a box chart that can be used to plan organization or flow charts. A space 120 at the top is provided for the title, while space 122 below it is provided for the subtitle. Below the subtitle there is an arry (I,J) of boxes 124. In this example there are six rows (I) and five columns (J) making a total of 30 available boxes. Each box is assigned an identifying number and points intermediate the boxes are also given numbers. At the very bottom there is a space 126 for remarks. The grid on which this arrangement is laid out corresponds to a portion of the 160.times.192 element grid of the terminal CRT.

The program for this basic type of slide would ask the user for the title, its color, its font, its size and its justification (i.e., left, center or right). The same questions would be asked about the subtitle and the remarks. The boxes for the flow chart would be designated by entering their number. The program then changes the box number into a row and column code (I, J). The color of the box, the text in the box, the color of the text in the box and the justification of this text are then entered. Connecting lines, showing lines of authority or flow paths in a process, are next specified by naming box numbers or intermediate points at the beginning and end of the connecting lines.

The program has equations in it that specify where the title space is to go depending on its size and justification. The same applies to the subtitle and remarks. The box locations and dimensions are also set by equations in the program depending on the (I, J) code. From this it can be seen that any basic slide can be established by using a layout such as FIG. 3 and by using equations in the program to create a display according to the layout. For example, a vertical bar chart program could have an arrangement similar to FIG. 3. A particular number and arrangement of bars could be given along with identifying numbers. The program would have equations that would define the bars in terms of their position and height. Text could also be positioned as a title and subtitle. In addition text could be arranged to identify the bars. This shows that modifications within the skill of an ordinary programmer would allow the basic concept of the box chart program to be changed to represent vertical bar charts, horizontal bar charts, etc. However, it should be understood that the present invention resides in a unique combination of programmed data processing equipment and not in any particular program used to operate part of that combination.

The specific box chart program of Appendix 6.2 corresponds to the flow chart of FIG. 2 and is capable of generating the slide of FIG. 8. The main initialization section 100 of this program begins on line [5] of the program listing as indicated in square bracket in FIG. 2. During this portion of the program standard values for the program, e.g., title and subtitle size, are loaded. Also the colors are set in which the questions and answers are displayed. Some of this data is later used by utility subroutines in the program, i.e., lines [2000] to [65009]. Once the initialization has been completed the program drops into the command interpreter section 102 that begins at line [200]. The user may then type in a command and its first three letters are checked to see if they represent a valid command. If not, the display prints "TRY AGAIN" and lists the allowable commands. Near the end of this routine there are safety steps to make sure that a command to cancel or finish was really intended.

If the procedure set forth in section 2.2 of this application (i.e., "General Program For The Terminal") is followed, the user would type in "CRE" and the program would branch to the create section 104 which begins on line [1300] of the program. A flow chart of the create section is shown in FIG. 4. As can be seen from the flow chart, this section is generally straight-forward, although it utilizes a number of subroutines. Lines [1300] to [1312] of the program initialize variables used in this section and inform a user trying to create a chart if he has already done so. Once this has been completed line [1315] calls up a Title Input subroutine located at line [10,000]. This routine asks the user to type in the title. The questions are asked in one color and the response is displayed in another color because the Two-Color Text Inputter subroutine at line [20,000] is called in this routine [See line 10020]. Also the text is checked to see if there is an illegal character by the Illegal Character routine located at line [20600]. If there is an illegal character this subroutine prints "ILLEGAL CHARACTER. TRY AGAIN". After a valid title has been entered the Title Input routine skips from line [10040] to line [10250]. The intervening steps are used in the modify section 108 of the program. The remainder of this subroutine requests the font number or style and checks to see if it is available. The program then increments the variable TV (I) to request the same information for the subtitle (space 122 of FIG. 3) and then the remarks (space 126). it should be noted that the font size, justification and color of this textural information was set during initialization. However, during a modification procedure these sections of the title input routine are reached and these values can be changed. Once the title, subtitle and remarks have been specified the subroutine directs the computer to line [1400] of the create section of the program.

Beginning at line [1400] as shown in FIG. 4 the program interacts with the user to specify the boxes required from those available in FIG. 3. At line [1420] the program displays "BOXES USED (INPUT O WHEN DONE)". At this point the program calls the Box Input subroutine located at line [11,000]. The user then begins to type in the number of boxes he wishes to use in respone to a "BOX NO." question from the computer. For example to create the chart of FIG. 8 the user would begin by typing in 13 to designate the box at (I, J) coordinates (0, 1). Lines [11215] to [11260] of the Box Input subroutine check the box number typed in by the user to see if it is a legal number and then convert it into (I, J) coordinates. Next the computer asks "BOX COLOR (TO DELETE A BOX, TYPE /D/ INSTEAD". The user enters the color and then lines [11345] to [11410] of the program check to make sure it is a legal color. If not, the program states "TRY AGAIN". These steps also keep track of the number of boxes designated. The remainder of the Box Input subroutine asks the user for the text of the first and second lines in the box and informs the user that he can enter only 11 characters. In the example of FIG. 8 the user would type in "model" for the 1 and "definition" for line 2. This process repeats until the user has specified the location, color and text of all the boxes he wishes to use. In the example of FIG. 8 this would be boxes 13, 17, 35, 75 and 115 of FIG. 3. By typing in an "0" the computer is directed to line [1780] of the create section 104 of the program. From this step the computer branches to the Connecting Line Input subroutine at line [12,000] of the program. In another interactive process the computer asks the user to enter "CONNECTING LINES (ENTER O WHEN DONE)", "FROM" and "TO". By typing in the beginning and ending points for the connecting lines, they are specified. Referring to FIG. 3 the points of the connecting lines for FIG. 8 are (13, 33), (33, 37), (17, 37), (35, 75), (74, 76), (74, 114), (76, 116) and (114, 116). Even though the connecting lines are drawn into and through some boxes this will not appear in the final version because the background color for the box will cover any connecting line within a box, thus making it appear to end at the edge of the box. Lines [12140] to [1220] of the program check to see if the point pairs are legal; diagonal lines are not permitted. This subroutine repeats until "0" is typed or fifty lines are specified. Then control returns to the create section of the program at line [1784]. From this step the end of the create section the computer asks for the color of the titles, box text, connecting lines and background. Once these have been specified by the hitting of the color keys on keyboard 54 the program control returns to the command interpreter section 102 of the program (FIG. 2) at step [200].

All of the steps required to create the slide at this point have been performed with the microcomputer and there has been no use of the time-sharing system. As a result there is a considerable savings in the cost of creating the slide. Normally at this point the user wants to see a rough approximation such as FIG. 8A, to the final slide he has specified. This is done by entering the command "DIS".

As can be seen at line [224] of the program listing in Appendix 6.2 the "DIS" command causes a branch to line [1945] which is the display section 106 of the program. A flow chart of this section is shown in FIG. 5. The program first initializes the computer by setting the terminal in page mode, setting the background color, and erasing the display screen. Also, a decision is made (line [1952]) about whether to paint a white outline showing the area of the slide. This is done only if the background is black. If the background is some color the extent of the background color will show the limits of the slide. The horizontal lines for the boxes are drawn by program steps [2000] to [2105]. The vertical sides of each box are drawn by the program steps [2120] to [2220]. Next the program adds the connecting lines in step [2290] to [2440]. Program steps [2490] to [2600] fill in the middle of the boxes with the colors specified by the user. Lines [2990] to [3410] of the program, through the use of a Title Display subroutine beginning at line [13,000], act to position and display the text in the box, the title, subtitle and remarks, all in the appropriate colors.

The remainder of the display section of the program checks to see if a color table has been specified [line 3499], adds a color table to the top of the slide and displays the color numbers selected for each color displayed, if the color table exists. This part of the program also checks to see if the user's identification number has been specified line [3810] and, if it has, it prints the user's identification number. These functions will be discussed in more detail in connection with sections 110 and 112 of the program.

At the end of the display section of the program, control is returned to step [200] of the command interpreter section 102.

Since up to this point there had been no input under the identify section 110 and the tabulate colors section 112 of the program, the resulting display on the CRT screen will not show this information. If it had been added the identification code 130 would appear at the upper right corner of the display and the color table 132 would be at the upper left corner as shown in FIG. 8A. In any case the user will see the boxes he selected in the appropriate locations and connected with the correct connecting lines. The titles, subtitles and remarks will be in a standard size and font, not the final form as shown in FIG. 8B, as will the text in the boxes. Rectangular areas 134 and 135 will be outlined to show the space that will be taken up in the finished slide by the actual title and subtitle (compare FIG. 8B). If there were remarks in the slide of FIG. 8 a rectangular area further would be displayed also. All of the colors selected will be used in their correct location.

It may be that the user is not satisfied with the slide and wishes to modify it. This is done by typing in the command "MOD" which causes the program to branch at line [228] to the modify section 108 of the program located at line [4000]. An overall flow chart of the modify section is shown in FIG. 6A.

In the modify section of the program the user is requested to "ENTER MODIFICATION" in one color and his response is displayed in another color because of the utility subroutine at line [20,000]. Depending on the command entered the program branches in several directions. If the command is "BOX" the program control goes to line [5200] which is the start of the Box Input subroutine located at step [11,000] as discussed in the create section. With this subroutine the user can add or delete boxes that were specified in the create section. Once this has been completed control is returned to step [4,000] for the next command.

A command "CON" causes the modify section of the program to branch to step [5600] which begins an interactive subroutine shown in FIG. 6B that permits the deletion or addition of connecting lines. Steps [5600] to [5690] add new connecting lines and steps [5700] to [5994] delete lines. The decision so to what is to be done is made by the user by typing in an "A" or a "D" so as to branch the program to either the add or delete section of the program. The adding of lines is under the control of the Connecting Line Input subroutine at line [12,000], which subroutine was discussed in the create section. When all the lines have been added or deleted the user types in an "0" and the program returns to step [4000]. The delete section first requests the "LINES TO BE DELETED, FROM, TO". If either the "from point" or the "to point" is zero the program returns to line [4000], i.e., the beginning of the modify section 108. If neither point is zero the program checks at line [5750] to see if there is any such pair. If there is no such pair the program notifies the user and lists the lines that have been selected so that a proper choice can be made. Then the program asks for a new selection. In the situation where the choice of points does represent an existing line the program deletes that line in a series of steps beginning on line [5910]. After the line is deleted the program returns to line [5700] and asks for the next pair of points defining a line to be deleted. When all of the lines have been deleted the user can return to the command interpreter section of the program by typing in a "0".

A command "DON" (FIG. 6A) indicates there are no further modifications and the program returns to the command interpreter section. Alternatively, the user can type the command "DIS" which will send the program to display section 106 without going through the command interpreter section.

Besides the special commands (i.e., BOX, CON, DON, and DIS) the modify section can also operate on general commands of the form: XY=Z. The X is a single character prefix that specifies the characteristics to be changed, i.e., "C" for color, "T" for text, "F" for font, "J" for justification and "S" for size. The Y represents several characters indicating the object and item to be changed, such as BX15L2 for line 2, box 15. The other objects are "T" for title, "L" for line, "CL" for connecting line and "BG" for background. In the command, Z represents the new value of the object and item. Therefore, the general command "TBX13L1=SAMPLE" would change the first text line of box 13 from "Model Definition" to "Sample Definition". (See FIG. 8A).

When a general command is typed in, the modify section of the program calls Change Command Parser utility routine that begins at line [20,700] and ends at line [20790]. This subroutine, which is shown in FIGS. 6C and 6D first initializes certain variables and then checks for the existance of the "=" sign at line [20715]. If it does not exist the routine ends; if it does exist the prefix and the new value are stored. In essence this subroutine disassembles the command into its component parts through the use of a variable J and branch instructions on lines [20734], [20736] and [20742]. The variable J successively represents each character of the command before the "=" sign. This J is checked to see if it is an alphabetic symbol or a number and whether it is the end of the code. As a result, the prefix, the object and the item are identified. Then in the part of the routine shown in FIG. 6D the parts of the command are separated at lines [20754] to [20760]. The validity of the prefix and object name are tested by the part of the routine at lines [20766-20775] and [20782-20785], respectively. However, the validity of the item number is not checked at this point. From this routine the program goes to step [4050] (FIG. 6A) which checks to see if the command has been found to be valid. If it has not, the program branches to line [4060] and then to line [4995] which prints the error message "NO SUCH OBJECT!TRY AGAIN" and returns to the beginning of the modify section. If the command is valid the program proceeds to line [4070] where a branch instruction controlled by the prefix is located.

In FIG. 6A the routine after a branch instruction for a "C" prefix is illustrated. The others are similar and return the program control to step [4000] when they are complete. In particular a "T" (i.e., text) branches the routine as the text modification section at line [4200], "F" (font) goes to the font section of line [4300], "J" (justification) to line [4400] and "S" (size) to the size modification section at line [4500]. The "C" prefix branches the program to line [4100] where a decision is made as to whether the new color is legal. If it is not, the error message at line [4108] is printed and the program returns to step [4000]. When the color is legal the program moves to line [4109] which is a branch command on the object, i.e., depending on the object the program control branches to different parts of the program. As an example the program branches to step [4120] if the object is a box, i.e., a command containing BX. This part of the program checks to see if the item number is legal and then assigns the new color to the box at step [4125]. Then the program cycles back to the input modify command line [4000].

The other branches from line [4109] work in a similar manner and return the program to line [4000] once a command has been completed. If the user types in "DON" or "O" the program returns to the command interpreter section 102 (FIG. 2) and awaits a new command.

Since the slide has been modified the user will probably want to see the results and will type in the command DIS which will cause the modified slide to be displayed on the CRT screen as described previously. If the user is now satisfied he can make the final preparations for sending the data to a remote slide making facility.

To insure proper identification at the slide making facility, the user can enter an identifying code. This code will appear on the slide, but will normally be in such a position that it will not appear on the screen when the slide is viewed with a standard slide projector. In order to enter this information the user types in the code "IDE" which causes the program to branch to the identify section 110 (FIG. 2) which begins at line [6000]. This is a straightforward interactive routine that requests the "CUSTOMER ID", the "CUSTOMER SEQ. NO.", the "SLIDE TYPE NO." and the "FILE NAME". Conventions can be established by the slide making facility for the type of response needed in answer to each of these questions. However, the important thing is that this identifying information becomes part of the data format shown in FIG. 7 which specifies the entire slide.

Since the microcomputer is capable of displaying only 8 colors and the high resolution CRT of the slide facility 74 (FIG. 1) can display 64 colors, the user may choose to have any one or all of the colors displayed on CRT 52, appear as a different color in the final slide. In order to accomplish this the user enters the command "TAB" which sends the computer to the tabulate colors section 112 of the program at line [7000]. The program at line [7005] then asks the user if he wants the standard color set, i.e., the colors available on the minicomputer and identified as colors 1-8. If he types in anything other than "Y" or "N" the program repeats the question. If the user indicates that he wants the standard colors the colors 1 to 8 are assigned at line [7015]. In the situation where the standard colors are not desired, the program branches to line [7021] and requests that the user "TYPE IN COLOR NUMBER FOR EACH COLOR KEY". For each color in the standard set on the terminal keyboard the user then types in a number from 1 to 64 and that standard color will appear in the final slide with the color specified. To remind the user of the selection he has made there will appear a color table with small swatches of the standard colors followed by the number the user has selected whenever the slide is displayed on the CRT. It should be noted that the user is not limited to changing one of the standard colors to a different shade of that color. He can change it to a completely different color. Thus, the system has some added flexibility in that a color change can be made without going into the modify section of the program.

Once all the values for the slide are entered the data, such as that in FIG. 7, can be saved, i.e., stored on a floppy diskette with a command "SAV". This command branches the program to the save section 114 at line [8000]. Initially this section of the program checks the data to make sure a complete slide has been specified. Next it calculates the length of the data string specifying the slide and prints the result. The program that converts the data into "ASCII numeric" code and stores it in a portion of memory used as a data buffer. This is accomplished with an instruction of the microcomputer called "POKE", which is a store command. These POKE commands are in the form (address, value to be stored). The address is specified in this program section as the variable J [line 8105] which points to the next available storage location. Once the data is stored it is transferred from the buffer to the diskette at line [8460] and control returns to the program interpreter section at line [200]. If the information is to be transmitted from the microcomputer to the time sharing system and then to the remote slide making facility, two other programs, i.e., PREP and SENDER, are used. These are programs of the microcomputer and are not shown. The PREP program asks the user questions about his location and what slide specifications are to be sent. The SENDER program reads the data from the disk, translates it and sends it over the network.

The slide created and saved according to the foregoing discussion is available to the user thereafter. He may obtain the slide data by entering the command "GET" which branches the program to line [9000], the beginning of the "get slide data" section 116 of the program. At the beginning of this routine the user is asked for the FILE NAME and VERSION NO. of the data file he wants. The program then checks the disk to see if it is available. If it is, the microcomputer uses an instruction of the form: A=PEEK (address). This is a read instruction that loads the incformation from the disk into the active memory of the microcomputer. Once it has been loaded, it can be displayed and/or modified and then restored on the disk.

The compact data of FIG. 7 gives the user identification number in the first 17 characters. Each of these characters is in a six bit binary code. Characters 18-33 are used to specify the colors selected in the color tabulate section of the program. The background color of the slide follows this color table information. In the next three sections the justification, font, size, color, character count and text for the title, subtitle and remarks are given. The color of the connecting lines and the point pairs defining them are specified in the following section. The box parameters, i.e., the box test justification, font and size along with the border color and the number of boxes, are then set forth. The specifications for each box then follow, these specifications include the node number for the box, the box color, the box size, the character count for the text and the text itself. The end of the transmission is indicated by a final delimiter.

At this point it should be noted that the slide displayed on the terminal CRT (FIG. 8A) will differ from the final slide in a number of respects. In particular, the picture element resolution of the final slide is much greater than that at the terminal. Also, it will have a greater variety of colors, fonts and sizes. In addition, aids such as rectangles 134 and 135 of FIG. 8A, which show the approximate size of the finished title and subtitle, do not appear on the final slide. Thus, when it is stated in this application that the final slide has a "higher" or "enhanced" resolution over the terminal display it is intended to imply that not only are more picture elements (raster points) present, but that more character styles and sizes, and more colors are present in the final slide.

As described above in connection with FIG. 1, slide specification data may be conveyed from the microcomputer display terminals 50 to the large scale central computer 70 by a variety of ways and means. In the preferred embodiment an IBM "batch" computer system is used for the slide computation, so that the data must also be translated from the format generated at the microcomputer display terminals into a format acceptable to this computer. In particular, all records supplied to the IBM computer must be reformated into IBM "card images"; i.e., they must be fixed length records with 80 characters (bytes) per record in EBCDIC code.

Consequently, in ether the time-sharing computer 62 or the minicomputer 68 (FIG. 1) the data must be translated into the format described hereinbelow. Since this translation requires merely a reorganization of the bits defining each character, and the characters defining the data, the creation of a computer program to carry out this translation is well within the skill of the average programmer.

Each input file to the IBM computer, be it a card deck, paper tape or a magnetic tape file, consists of one or more "slide inputs". In the case of multiple slide inputs, they are simply ordered one after another as shown in FIG. 15.

Each slide input has four parts, namely:

(1) a slide identification (ID);

(2) a slide specification (SS);

(3) a printer picture specification (optional); and

(4) an END card.

These four parts are described in detail in the following sections using a box chart as an example.

This part has only one card. It contains the slide type number, the background color, number of copies, the picture window limits and accounting information. This card appears first in the slide input.

More particularly, the format of the slide ID card is:

This input part specifies the details of this current slide: positions, colors, texts, etc. Since different types of slides have different input data, the nature of the slide specification will depend upon the ITYPE number. Table 2 shows all slide types with their corresponding ITYPE number.

For a box chart (i.e., with the ITYPE on the slide ID card between 1 and 9), the following input cards comprise the slide specification:

Each card can have 4 connection lines (2 numbers for each connection line). This card is repeated as many times as necessary. The data is terminated by a blank connection line (i.e., leaving 2 consecutive entries blank).

This card is repeated as many times as necessary. A blank card terminates the slide specification.

This input part provides the user the option of getting line-printer "pictures" of this slide. The user specifies the viewing area of this printer picture on a given slide. He can get as many printer pictures as he likes from different areas of that slide.

The data format for each printer picture is:

IX1, IX2, IY1, IY2 (4I10)

IX1, IX2--Specifies the left and right boundary of the viewing area.

IY1, IY2--Specifies the lower and upper boundary.

The units for all boundaries are raster point units. For example, the following card:

shows the entire slide on the printer. However, since one printer picture only has 96.times.64 points, the printer prints only every 2016/96=21 points.

Another example--this card:

shows the upper right quarter of this slide, for this printer picture. It prints every 1008/96=10 points.

The user can specify any viewing area as many times as he likes (by repeating this card). This input part is terminated by a blank card.

A typical example is shown in FIG. 16. The first card specifies a printer picture covering the viewing area from 1 to 2016 (left to right) and from 1 to 1344 (from bottom to top). The second card (blank card) terminates this input part.

Notice that if the user doesn't want any printer picture, he still needs one black card to terminate this input part.

This input part indicates the end of the slide input for the current slide. It has only one card with "END" written in columns 1 to 3. The data format for this card is

Immediately following this card should be the slide ID card of the next slide.

An IBM 360/75 computer is used to compute the color of each raster point of the picture to form the slide. As stated above, this picture has a resolution of 1344 raster units in height and 2016 raster units in width. The computer produces an output tape on which is stored the intensity of each raster point for three primary colors; red, green and blue, respectively. The computer receives the slide input, in the format described above, and accesses, as needed, digitally encoded data defining each character or symbol to be included in the slide. This encoded data is maintained in a "symbol library" on a disk file, for ready access by the computer. While any known scheme may be used for generating and encoding the symbol data (some known encoding schemes are disclosed in the U.S. Pat. Nos. 3,305,841; 3,471,848 and 4,029,947) the preferred technique for producing the symbol library is set forth below.

FIG. 17 shows the steps required to digitally encode each character or symbol. The data for all characters or symbols is stored on the disk file 214 so that file is referred to as a "symbol library".

In order to generate a symbol library, an actual picture of each symbol on hard copy, i.e., "symbol graphics" 202, is scanned by an optical scanner 204 to produce "raw" data on a magnetic tape 206. This magnetic tape is read by the IBM computer and processed by a software routine 208 called "TAPE" to convert the scanner data into a standard raster point format. Each point in the image is represented by one data item; i.e., present or absent (1 or 0). The standard raster point data is written onto magnetic tape 210 and then reprocessed by a software routine 212 called "LIBR". LIBR compresses the data by grouping adjacent points on a line which have the same characteristics (i.e. either present or absent). This is a common technique known as "run-length encoding". The precis format of this data is described hereinafter. The run-length encoded "RLE" data is then written onto a disk file 214.

Subsequently, each symbol on the disk file is printed out by means of a software routine 216 called "PRNT" on a line printer 218 to permit clerical analysis of the data. If correction is required, correction cards 220 are prepared and supplied to the machine. A software routine 222 called "CORR" accepts the correction cards and modifies the RLE data for the specified symbol. The output is to a temporary magnetic tape 224. In actual practice, the user now reruns PRNT and repeats the correction cycle until the symbol is correctly coded.

A software routine 226 called "RDBK" now reads the magnetic tape 224 and updates the disk file to produce a "corrected" disk file 228. Another routine "ADHC" 230 reads the disk file and permits arbitrary adjustment of character width and position. These width and position parameters are designated "IX" and "IYD" in the RLE data to be described below. This adjusted RLE data is restored on a disk to form an adjusted disk file 232.

Finally, a software routine 234 called "GAPE" adds kerning data to the RLE encoded symbol data and returns the symbol, now kerned, to the disk file 236, which has the final "symbol library".

Once the RLE data format is known, all of the software routines used in font data processing are straight-forward and well within the skill of the average programmer.

The symbol library is a disk file on an IBM 2314 disk and is called "RANDDS". This file contains the run-length encoded (RLE) data of all symbols (a symbol can be a letter, a number, a special sumbol, company logo, . . . etc.).

In order to allow the slide program to have quick access to the disk file, the symbol library is constructed as a direct-access file; i.e., it occupies contiguous blocks in the RANDDS disk. As an example, three fonts may be stored in 350 records with 2240 bytes per record.

The symbol library is referred to by the slide program as "unit 2". Using IBM JCL, it can be specified as:

//GO.FT.phi.2F.phi..phi.1 DD UNIT=DISK,VOL=(PRIVATE,RETAIN,SER=RANDDS),

//DISP=OLD,DCB=BLKSIZE=224.phi.

In a FORTRAN program, the font library is referred to by using:

DEFINE FILE 2(35.phi.,224.phi.,L,LOC)

READ(2'LOC) IBUF

WRITE(2'LOC) IBUF where IBUF is an array of 224.phi. bytes.

Three typical fonts which may be stored in the symbol library are Helvetica medium, Helvetica slim and Helvetica bold. Each font has 86 symbols: 26 upper case letters, 26 lower case letters, 10 numbers and 24 special symbols.

The RLE data of each symbol occupies one or more records, but each record cannot be shared by more than one symbol. Every sumbol is assigned a unique ID number and a decimal value. It may be called by looking up its location in the disk file (disk record number) from a table.

The structure of each symbol is illustrated in FIG. 18. Everything described in this section has a 2-byte word format (therefore, each record has 1120 words).

There are eight pieces of data for each symbol. They are described individually in the following sub-sections.

TITLE is a literal description of the symbol. It occupies the first two words (4 bytes). For example, the TITLE for Helvetica medium upper case A is "UA01" (upper-case A, font type 1).

LENTH is the number of bytes used for RLE data to describe this symbol. LENTH occupies the third word of the symbol.

1X is the width of this symbol in raster point units. It occupies the fourth word of the symbol.

Normally, IX is measured from the left-most border of this symbol to the right-most border. For example, the slash sign "/" has IX measured from the lower-left tip to the upper-right tip. However, there are exceptions; for example, the width of 1 is narrower than the width of 9, but since all numbers preferably have the same width (so that they can be aligned in columns) the width of 1 is artificially expanded to match the widest width of all numbers (which happens to be the width of "0"). In fact, the widths of all numbers from 0 to 9 are expanded to match the widest width.

IY is the height of this symbol in raster point units. It occupies the fifth word of the symbol.

IY is measured between the top and bottom of this symbol; for example, IY of "j" is measured from the top of the dot to the bottom of the tail.

IYD is the vertical displacement of this symbol in raster point units. It occupies the sixth word of the symbol.

Normally, IYD is zero; that is, no vertical displacement. When IYD is positive, it means move upward. When IYD is negative, it means move downward. For example, the IYD of "A" is zero (no vertical movement). The IYD of "g" is a negative number, since the bottom of g should lie below the base line (see FIG. 19). The IYD of "*" is a positive number because it lies above the base line.

IAREA1, IAREA2 are the left and right blank areas of this symbol, respectively (See FIG. 20). They are intended to be used for kerning to evaluate the "white space" between symbols, but the program does not need to use them if the spacing between letters is made constant.

IAREA1, IAREA2 occupy the seventh and eighth words, respectively, of the symbol.

IXD is the horizontal displacement in raster point units. It occupies the ninth word of the symbol.

In section 4.3.3. we noted that the actual width of some symbols is expanded to a pseudo-width. In this case, we also apply a horizontal displacement in order to keep this symbol in the middle. Suppose IX.sub.0 is the actual width and IX.sub.1 is the expanded width. The IXD is calculated as (IX.sub.1 -IX.sub.0)/2.

String-format data starts at the eleventh word of this symbol and ends at the (10+LENTH/2)-th word. It consists of many pairs of words. Each pair (ISTART, IEND) represents the starting location and the ending location of a visible line segment.

As shown in FIG. 21, the first 11 bits of each word contains the location (for either ISTART or IEND). For IEND, if the twelfth bit is set, it means end-of-line. If the thirteenth bit is set, it means end-of-symbol.

For example, in FIG. 22 there are two pairs of words at line L to represent two visible line segments. These four words are illustrated in FIG. 23. Note that the twelfth bit (bit -11) in word 4 is set to represent the end-of-line.

In case of a blank line within the symbol, as is found just below the "dot" in the lower-case "i", ISTART is assigned to be 1 and IEND is assigned to be 2048 (which means locations 0 and end-of-line).

Kerning data is used by the slide program to overlap two letters. It starts at the (10+LENTH/2+1)-th word and ends at the (10+LENTH/2+52)-th word.

The definition of the kerning data is the adjustment required to cause the adjacent letters to touch. For example, in FIG. 24, we can see the adjustment causing contact between L and T, denoted as d.sub.3. After kerning (if any) another adjustment is made to establish a constant minimum distance for the given symbol size. This is denoted as d in FIG. 24.

In general, for a given letter i there are 52 numbers corresponding to the kerning data between this letter and the other 52 letters. Thus, the kerning data D.sub.ij between the letters i and j is given by: ##EQU1##

where K covers the heights of letter i and letter j. This distance D.sub.ij for the pair of letters i and j is stored for each of the other 52 letters.

The program structure for the slide computation is shown in FIG. 25. The slide computation is performed by five program "modules" which are stored on the disk file and successively "swapped" in and out of the computer core memory as they are needed. A control program called "MAIN" permanently resident in core memory calls in the appropriate program module at the appropriate time. To compute the raster data for each slide, all five program modules must be run in the computer in proper sequence.

The first program module, called "INITIALIZATION", initializes the common block in the computer core memory which will contain the data for the next slide specification. All the counters used in the slide computation are cleared and an "error code" is reset to zero. The error code will be set to a non-zero number if an error condition is found when running any of the subsequent modules. Upon detection of an error, computation of the current slide is terminated and the program returns to INITIALIZATION to process the next slide.

The next program module, called "INPUT", inputs the slide type from the first card image and then calls an appropriate subroutine to input the rest of the data for the slide. For example, if the slide type is a box chart, a subroutine is called to receive and store in the common block the particular slide specification for this type of slide. The data is also checked for validity and if an error is found, the error code is set to a non-zero number. The first module, INITIALIZATION, is then called to immediately commence processing the next slide.

The third program module, called "TYPE-SET", composes the slide using a special-purpose subroutine for each slide type. This composition entails placing all specified graphic patterns into specified locations in the common block for subsequent processing. As needed and called for by the slide specification, symbol data is accessed from the symbol library and placed in the common block. If an error occurs when TYPE-SET is run, the error code is set to a non-zero number and INITIALIZATION is called to commence processing the next slide.

The fourth program module, called "PROCESS", converts the graphic patterns stored in the common block into raster line data in run-length encoded"RLE" format. This RLE data is temporarily stored on the computer disk file. Again, if an error is detected when this module is run, the error code is set to a non-zero number and INITIALIZATION is called to commence processing the next slide.

The fifth program module, called "OUTPUT", reads the temporary disk file three times to generate output data defining a red image, a green image, and a blue image in RLE format. The final color file, so generated, is written on magnetic tape.

When the module OUTPUT has been run, the control program MAIN calls INITIALIZATION to commence processing the next slide.

With the IBM 360/75 computer, a single slide computation takes approximately 30 seconds. The INITIALIZATION and INPUT modules together take a second or less to run; TYPE-SET requires approximately 45% of the total slide computation time or 13 seconds. PROCESS takes approximately 20% of the time (6 seconds) and OUTPUT the remaining 35% of the time (10 seconds).

Set forth below is a detailed description of each of the five program modules used in the slide computation.

The purpose of INITIALIZATION is to reset all the counters, the color table and the error code in the computer memory common block. There are thus essentially three steps which are illustrated in FIG. 26.

The slide computation program is capable of generating eight distinct graphic patterns for a slide. The particular graphic patterns in a given slide will be superimposed, one on top of another in a prescribed heirarchy by the program module PROCESS when a raster line is processed. These graphic patterns or shapes are as follows:

(1) Inset: Inset is a rectangular shape of a prescribed size which may have one of ten different colors specified by the user. FIG. 27 shows a typical inset 300 of one color arranged on a backbound 302 of another color.

(2) Triangular Area: This graphic pattern is a triangular shape having a horizontal base which is used for processing the area under a sawtooth-type function on a graph. FIG. 28 illustrates how several triangles 304-310 are used together with bar shapes 312-318 to define the area under a function 320.

(3) Grid Lines: Grid lines are rectangular shapes of specified thickness and color which may be called to provide horizontal or vertical reference lines on a graph, or to create connecting lines in a box chart. FIG. 29 shows a number of horizontal grid lines 322.

(4) Bars: Bars are a rectangular shape of a specified thickness and color which may be used in a bar chart, or in any other situation where an arbitrary rectangular shape is required. FIG. 30 illustrates three typical bars 324 of different height in a bar chart; FIG. 28 shows bars 312-318.

(5) Circular Pie: Pie is a circular graphic pattern which is used for a pie chart. FIG. 31 shows a typical pie shape 326 divided into three colored sections 330, 332, and 334. The borders 328 between sections may be defined by straight line segments.

(6) Straight Line Segment: A straight line segment is a line of a specified thickness and color which may extend in any direction on a graph. FIG. 32 shows how line segments 336-342 are used in a line chart to represent one graphic function.

(7) Grid Axis: A grid axis, also called a "box", is a rectangular shape of a prescribed thickness and color which is arranged vertically or horizontally on a graph to form an axis. FIG. 33 shows vertical and horizontal axes 344 and 346.

(8) Symbol: A symbol is a specific pattern which is always used in its entirety, although its size and position on the slide may vary. Data defining the symbols are stored in the symbol library. FIG. 34 shows a typical symbol "A" 348 arranged in a slide.

As mentioned above, the eight graphic patterns are called by PROCESS in a fixed priority: namely, the priority (1)-(8) given above. Thus, for example, when a bar chart is processed the grid lines are laid down first, the bars are superimposed thereon and finally the grid axes are superimposed on the bars and grid lines as is indicated in FIG. 35. Prior to considering any of the graphic patterns, PROCESS sets the background of the slide to the background color. Therefore, the background may be viewed as having the first priority although it is not considered a graphic pattern.

PROCESS operates by checking counters in the computer memory common block to determine whether a first type of graphic pattern (inset) intersects the current raster line. If so, the color of the respective raster points are set. If not, or after the raster points are set, PROCESS checks and counters in the common block to determine whether any second types of graphic patterns (triangles) intersect the current raster line, etc. This procedure continues until all eight types of shapes are processed for the line. Consequently, PROCESS needs to know if any graphic patterns of a specific type are required for a given slide and, if so, how many there are. For the purpose of this determination, one counter is provided in the common block for each of the eight graphic patterns. It is these counters which INITIALIZATION sets to zero during the first step 350 shown in FIG. 26.

The second step 352 of INITIALIZATION is to reset the "color table" to zero. Although there are 64 different colors to choose from, only eight of these colors may be used for a given slide. This permits the color information for a slide to be defined in three bits, once a color table is set up establishing the correspondence between the original eight (or less) choices of color and this three-bit code. Thus, for example, if a user specified only five colors for a given slide, these colors would be set up in the color table in the computer memory common block as follows:

The third step 354 of INITIALIZATION is to reset the error code to zero. When this step is completed, control is returned to the control program MAIN, which calls the second program module INPUT.

The steps executed by the program module INPUT are set forth in FIG. 36. In the first step 356 the first slide input card image--namely, the ID card image--is read and the slide type number, the background color, the number of copies and the accounting information are stored in the computer memory common block. As indicated in step 358, since different types of slides have different input information, the program branches into one of eight subroutines, depending upon the type number ITYPE of this slide. As may be seen from Table 2, if ITYPE is a number from 1 to 9, the slide will be a box chart requiring subroutine 360. If ITYPE falls in the ranges 10 to 19 and 30 to 39, the slide is a vertical bar chart requiring the subroutine 362. The subroutines 364, 366, 368, 370 and 372 are similarly called if ITYPE falls within the ranges indicated. When the respective subroutine has ended, control is returned to the program MAIN which calls TYPE-SET.

The subroutine 360 for a box chart is shown as an example in FIG. 37. In the first step 374 this subroutine reads the card image with the title information; namely, the font type, size, color and justification mode (left, center or right justified) as well as the character string of the title. Thereafter, in step 376, the next two card images containing the subtitle and remark information, respectively, are read. This information is similar to that on the title card. For the specific information read by this subroutine, reference is made to the slide specification format set forth in section 3.1.2, above.

Thereafter, in step 378, the subroutine reads the fourth card image containing the type of font, size of the characters used in the boxes, as well as the color of the connection lines and box border lines. In step 380, the subroutine reads the fifth card image containing the information about the connection lines; that is, the starting and ending node points for each line. For example, these node points may be 15, 55; 52, 58; 52, 82; etc. Following this, in step 382, the subroutine reads the card images for each box (one card image per box). Included in this data are the box node number, the box color, the box text and the color of this text. When a blank card image is read, the subroutine knows it has come to the end of the data.

Finally, in step 384, the subroutine stores all the data read in by the program module INPUT .phi. in the computer memory common block, i.e., /INPUT/. The next program module "type-set", i.e., TYPESET, will use this data.

The steps executed by the program module "type-set" are set forth in FIG. 38. The word "type-set.revreaction. is used in the general sense, meaning to convert the input data stored in the common block /INPUT/ into graphic patterns which, in turn, are properly positioned in the picture raster. Again, since different slides have different layouts, TYPESET branches into one of eight subroutines depending upon the type of slide. Consequently, in the first step 386 TYPESET checks the number ITYPE and calls the appropriate one of the subroutines 388-402.

As an example, FIGS. 39A and 39B show the steps of the subroutine for a box chart. The first step 404 in this routine is to retrieve from the disk file symbol library the data defining each of the symbols that constitute the title of the slide. If two or more symbols appear two or more times, as in "bookkeeping" for example, the data for each symbol is retrieved only once. Thus, in this example, the letters b,o,k,e,p,i,n,g would be retrieved from the disk.

The symbol data is stored in the common block in the following fashion: First of all, an area called /TEMP/ is established for storage of the identity, font and size of each of the characters retrieved from the disk. This section of the common block is used to determine whether the next text symbol has been previously retrieved from the font library and placed in memory. The parameters stored in /TEMP/, therefore, are:

ID()--An array listing the identity of each symbol stored in the common block.

IFONT()--An array defining the font of each symbol identified in ID().

ISIZE()--An array defining the size of each symbol identified in ID().

The notation () means that the given parameter has an array of data (in this case a different number for each of the different symbols).

In addition to /TEMP/, further data about the symbols retrieved from the symbol library are stored in the common block in an area called /TEXT/. The information stored in this area includes the following parameters:

NTLINES--The number of text lines in the box chart. For example, a chart having a title, subtitle, four boxes and a remark may have seven text lines.

LOCMEM()--An array containing the location in the common block of the RLE data for each symbol. This array is thus a "pointer" for each symbol.

NCHAR()--An array containing the number of symbols in each text line. For example, if there are seven text lines, this array will include seven different numbers, one for each text line.

XCHAR()--An array containing the "X" or horizontal location of each symbol, in raster point units.

YCHAR()--An array containing the "Y" or vertical location of each symbol, in raster point units.

COLOR()--An array containing the color (using the three-bit color code) of every text line.

The RLE data for all the symbols used in the slide are stored elsewhere in the common block. The starting location for this data defining each symbol is stored in LOCMEM().

At this point, it is useful to introduce the manner in which the symbol size is handled in the slide computation.

For convenience, the picture raster is divided into "reference units", each of which equals 28 raster point units. Thus, with a slide having 1344.times.2016 raster point units, the slide will be 48 reference units high and 72 reference units wide.

Consequently, each slide may be viewed as a grid of 48.times.72 reference units. Some space is always left on each side and on the top and bottom so that the graphic patterns on the slide do not reach the edge of the picture.

There are eight different sizes of symbols available to the user for composition. These may be numbered from 1 to 8 (smallest to largest) with the smallest size being one reference unit high and the largest size eight reference units high. Thus, the size of the smallest symbol is 1/48th of the height of the slide. Sizes 2, 3, 4 . . . 7 are not linearly distributed between the smallest and largest sizes. The following table sets forth the size relationships:

The data format permits a different number of scan lines to be stored for each symbol. Thus, a tall character will result in more data than a short character. For example, the data defining a symbol may be set to assume that the largest letters (e.g., "B" and "W") will fill a square roughly 225 scan lines high and no more than 2048 raster points wide. A relatively short symbol "i" may be only 58 scan lines high, which results in less RLE data than for a larger symbol. By counting the end-of-line flags in bit 11 of the RLE data, it is possible to determine the number of scan lines in a symbol. This information is also contained in the symbol height number "IY".

For symbols to be displayed in the largest size (size 8) the data defining each and every scan line for the symbol is retrieved from the symbol library and stored in the computer common block. Thus, for a "B", for example, 225 lines of data are retrieved and stored. If we assume an average of two segments of symbol for each scan line, each segment requiring the definition of one starting point and one ending point, each point of which is set forth in a two-byte word, the symbol "B" will require approximately 225 (lines) X 2 (segments) X 2 (points per segment) X 2 (bytes per point) or approximately 2K bytes which must be retrieved and stored in the common block.

For sizes smaller than size 8, less than the full amount of RLE data must be retrieved. For size 6 (which is half as large as size 8) every other line is retrieved. For size 7, three lines out of four are retrieved and for size 1 (which is 1/8th as large as size 8) only one line out of eight is retrieved.

While a field of 140K bytes is reserved in the computer memory common block to store the symbol data, less than half of this total space in memory is required for the average slide.

After retrieving each of the symbols that constitute the title, storing the string format data for each different symbol in the space assigned in the common block, and storing the required data in /TEMP/ and /TEXT/, the subroutine determines and stores the exact X,Y location of each symbol. For left justified sumbols, the left edge of the first symbol in the title is positioned two reference units (56 raster point units) from the left-hand side of the slide. For right justified symbols, the right edge of the last symbol in the title is positioned 56 raster point units from the right-hand side of the slide. In this case, since there are 2016 raster point units in a horizontal scan line, the left edge of the first symbol of the title wall be positioned at 2016-56-TW (in raster point units), where TW is the total width of the text line (title). The total width TW of the text line equals the sum of the individual widths of the symbols minus the sum of the kerning distances between the symbols. For example, if the text line is "VAN", the total width is given by:

For centered text, the left edge of the first symbol is positioned at (2016-TW)/2. The positions of symbols after the first symbol may be determined by simply adding the width of the previous symbols to the starting position and subtracting the kerning distances between the previous symbols. Thus, in the example given above, the position of "N" is given by:

where X is the position of the symbol indicated.

After completing the title text, the subroutine repeats the process for the symbols in the subtitle and the remark. This operation is indicated as step 406 in FIG. 39A.

Proceeding to step 408, the subroutine now considers and stores data defining the connection lines in a location in the computer memory common block called /GRID/. /GRID/ contains the following parameters:

NGLINE--The total number of grid lines in a slide. This counter is set to zero by INITIALIZATION.

X,Y.sub.11 ()--This is the coordinate of the lower left corner of each grid line in raster point units.

X,Y.sub.ur ()--This is the coordinate of the upper right corner of each grid line in raster point units.

COLOR()--This is the color of each grid line. While there are eight different colors which may be used for the connection lines, it is assumed that all connection lines are the same color.

The parameters in /GRID/ are determined as follows: Each time a new connection line is processed, NGLINE is increased by "1.". The color of the connection lines are specified in the data in /INPUT/, as are the end points of each line which are designated I1, I2. The subroutine converts the end points I into horizontal and vertical raster point units and calculates the coordinates (X, Y) of the lower left and upper right corners of the grid line.

For example, if I1=15 and I2=55, the subroutine converts these numbers into vertical and horizontal raster point units, respectively, so that I1 becomes 500,1008 and I2 becomes 900,1008. Since I1 and I2 define the end centerpoint of the line, two raster point units must be added to the horizontal address of the upper end point and two raster point units subtracted from the horizontal address of the lower end point. The values X,Y for I1 and I2 are therefore:

As indicated in step 410 in FIG. 39B, each box of the box chart is formed by a "bar" or rectangle serving as the box outer boundary and a "box", also a rectangle, serving as the box inner boundary. The difference between the bar and the box is therefore the thickness of the box outline. The subroutine calculates and stores the lower left and upper right corners of each bar and box in computer memory common block areas called /BLOCK/ and /BOX/, respectively. The parameters in these two storage locations are nearly identical and, in fact, are similar to the parameters in /GRID/. They are:

NBLOCK--The number of box chart boxes, which is determined by the number of box card images excluding the last blank card.

NBAR--Ditto NBLOCK; that is, the number will be the same.

X,Y.sub.ur ()--The X and Y coordinates of the upper right corner of each block in the case of /BLOCK/ and each bar in the case of /BOX/.

X,Y.sub.11 ()--The X and Y coordinates of the lower left corner of each block in the case of /BLOCK/ and each bar in the case of /BOX/.

COLOR()--The color of the line defining the organization chart box in the case of /BLOCK/ and the color of the area inside the organization chart box in the case of /BOX/.

These parameters are determined and computed in the same way as the parameters for /GRID/. NBLOCK and NBAR are counters, cleared by INITIALIZATION, which are indexed each time a box chart box is processed. The color data is found in /INPUT/ as are the center points of each block and bar. Thus, since the center point of a box is given as numbers I,J where I is the vertical position and J the horizontal position, the vertical and horizontal positions of the box in the raster point units of the center point are given as:

Vertical position=1344-(9.5+3I).times.28; and

Horizontal position=(1.5+7J).times.28.

Since the outer boundary of an organization chart box is three reference units high and eleven reference units wide, the vertical position of the top boundary is determined by adding 1.5.times.28 to the vertical position of the center point. Similarly, the horizontal position of the right boundary is given by adding 5.5.times.28 to the horizontal position of the center point. Proceeding in this manner, it is possible to calculate X,Y for the upper right and lower left corners of each block and bar.

Finally, in step 412, the text strings for each organization chart box are retrieved from the disk and stored into appropriate areas in the computer memory common block using the same procedure as that for the title, subtitle and the remark. Upon completion of this step, the program module TYPE-SET is finished and control is returned to the program MAIN.

The steps executed by the program module PROCESS are set forth in FIG. 40.

As noted in step 414, PROCESS determines the color of the 2016 raster points in each of the 1344 horizontal lines in a slide. The process used for each scan line is indicated for steps 416-446 that follow. These steps 416-446 are executed 1344 times before the slide is complete.

Before proceeding to scan each line, all the raster points in the slide are set to the background color. Thereafter, if the "inset" counter was indexed (step 416), after being cleared to zero by INITIALIZATION, the program enters step 418 and, the color of the raster points within the inset field are changed to one overlayed by the inset color. If the inset center was not indexed, the program continues directly to step 420.

Next, the counter for triangular areas is checked at step 420 to determine whether any such areas exist in the slide. If so, the color of the raster points in the current line which fall within the triangular area or areas is changed as required. If not, the program immediately proceeds to step 424 and continues in this manner.

It should be emphasized that no calculation is necessary to carry out this process because all the data required to determine the color of each raster point on a line is stored in the computer memory common block. In essence, PROCESS merely retrieves data from the common block in a prescribed order, updating the color of each of the 2016 raster points in the current scan line, and after proceeding through step 416-446, writes the color data for that line in a prescribed format onto a temporary disk file.

In carrying out the overlay procedure, PROCESS repeatedly updates three parameters:

An example of the procedure carried out by PROCESS will now be described with reference to FIG. 41 and FIGS. 41A-41F. Assume that PROCESS, in working on a slide 448, has already scanned half the picture and is now at the raster line 450. This slide is an organization chart comprising a background 452, an inset 454, a number of boxes 456, one box 458 of which is intersected by the scan line. The slide also has a horizontal connecting line 460 and three vertical connecting lines 462. The boxes 456 contain text 464; in particular, the box 458 contains the letters "C" and "D" 466 which are intersected by the scan line 450.

In step 414 of PROCESS, the entire scan line 450 is set to the background color. There is thus one segment of background color having 2016 raster points. Therefore:

The scan line 450, with the single segment, is shown in FIG. 41A.

In step 416 PROCESS determines that an inset is present and proceeds to update the description of the scan line in step 418. As shown in FIG. 41B, there are now three line segments of background, inset and background colors, respectively. The parameters are therefore changed to the following:

The information for updating these parameters is found in an area called /INSET/ in the common block which was generated from the data in /INPUT/ by TYPSET. The parameters stored in /INSET/ are:

Because the slide does not have a triangular area, PROCESS moves directly to step 424 and on to step 426. In step 426, PROCESS checks the common block area /GRID/ and determines that there are no horizontal grid lines intersecting the scan line. This test is performed by comparing the upper and lower Y coordinates of the horizontal line 460 with the Y coordinate of the current raster line 450. Since the raster line lies below the range of Y values of the horizontal line 460, this horizontal line is ignored.

PROCESS then determines in a similar manner that the three vertical lines 462 do intersect the scan line 450. From the information contained in /GRID/ the parameters NSEG, KOLOR and KOUNT are updated as follows:

The nine segments determined at this point are shown in FIG. 41C.

PROCESS next proceeds to step 428 and determines that "bars" are present in the slide. The program therefore turns to step 430 which updates the parameters NSEG, KOLOR and KOUNT from the information contained in the common block area /BAR/. As shown in FIG. 41D, there is only one bar 457 which intersects the scan line. Although there are still only nine segments in the scan line, the PROCESS parameters are changed to the following:

Upon completion of bars, PROCESS determines that there are no circular pies (step 432) or straight lines (step 436) in the slide. However, in step 440 it finds that the slide contains at least one block. Consequently, PROCESS executes step 442 and determines that only block 459 intersects the scan line as shown in FIG. 41E. From the information in the common block area /BLOCK/ (also called /BOX/), the PROCESS parameters are updated as follows:

When step 442 is finished, PROCESS determines, in step 444, that symbols are present in the slide. PROCESS therefore proceeds to the final step 446 for this scan line, where it finds that two symbols "C" and "D" intersect the line. As shown in FIG. 41F, which illustrates an enlarged portion of the slide, there are now 17 segments in the scan line with the addition of the symbols 466.

As explained above, the RLE data (FIG. 18) defining the "C" and "D" are stored in a special, unnamed area of the common block. For every "C" and "D" that are used in the slide, there is a separate pointer LOCMEM which is updated as PROCESS proceeds through the 1344 scan lines. Thus, the LOCMEM for each letter "C" and "D" point to the respective locations in the common block containing the words "ISTART" for the current scan line. These words, and the following words for the same scan line are used to determine the positions of the segments defining the letters "C" and "D" on that line.

For example, for the letter "C" the position of the segment 7 is given by:

Starting position: IXCHAR.sub.C +ISTART.sub.C, where LOCMEM(C) points to ISTART.sub.C

Ending position: IXCHAR.sub.C +IEND.sub.C.

After the segment or segments of a character on the current scan line are determined, LOCMEM for that character is updated for the next scan line.

With this procedure for obtaining information, PROCESS updates the process parameters to the following:

When step 446 is finished PROCESS converts the parameters NSEG, KOLOR and KOUNT into output data, and returns to process the next scan line.

The format of the data written onto the disk file is shown in FIG. 42. Each raster line is made up of one or more "segments" of raster points having the same color. For example, points 1-16 may be blue, points 17-2000 red, and points 2001-2016 blue. This line then has three color segments of 16, 1984, and 16 raster points, respectively. If all the raster points in a scan line are the same (background) color, the line consists of one color segment. Note that while it is possible to have up to 500 color segments in a scan line, only eight different colors are permissible.

One sixteen bit word is used to describe each color segment as shown in FIG. 42. The bits in this word are assigned as follows:

Bit 0 to Bit 10--This string of eleven bits define the number of raster points in this color segment; i.e., the length of this color segment.

Bit 11 to Bit 13--These three bits define the color (one of eight colors) of this color segment.

Bit 14--When set, this bit indicates that this color segment is the last segment on this line (end-of-line signal).

Bit 15--When set, this bit indicates that this color segment is the last segment of this picture raster (end-of-slide signal).

OUTPUT, shown in FIG. 43 merely converts the data in the format shown in FIG. 42 on the temporary disk file into a format more suitable for color photography and writes this new data onto a magnetic tape. The final output format is shown in FIG. 45.

Every color can be represented by the addition of three primary colors, each with a specific intensity. Therefore, each of the eight colors represented in the data on the temporary disk file can be translated into respective intensities of red, green and blue. Because there are a limited number of color possibilities (64 different colors), a table look-up procedure is used to derive the intensities of red, green and blue for each of the colors (up to 8) on a slide.

Therefore, for each 16 bit word on the temporary disk file, OUTPUT creates and writes on magnetic tape three sixteen bit words in step 468 of FIG. 43. This conversion can best be described by an example:

Assume that a word in the format shown in FIG. 42 defines a purple color segment of eleven raster points, and assume also that the purple color is the third color used in this slide. Therefore, the 16-bit word representation of this color segment in the temporary disk file will contain the bits shown in FIG. 44. Bits 0-10 will contain the binary representation of the number eleven, and bits 11-13 will contain the binary representation of two, which is the third number when counting from zero. From the color table, it is known that a purple color has intensities of 24, 7 and 30 of red, green and blue, respectively. Therefore, the word illustrated in FIG. 44 will be translated into the three words shown in FIG. 45.

The final stage of the picture-making procedure according to the present invention is the production of 35 mm slides from the digitized picture information recorded on magnetic tape. The magnetic tape containing the picture information is played back through a picture imaging and photography device which decodes the information, and displays the picture on a high-resolution cathode ray tube screen. A camera, mounted in front of the screen, then records the picture on film. Color pictures are taken by exposing a single frame of the camera film to three separate black and white images--each representing the intensity of one of the primary colors--through red, green and blue filters, respectively.

The device used for displaying and photographing the computer generated pictures is shown in FIG. 46.

The device includes a keyboard input unit 470 for supplying control information typed in by an operator and a magnetic tape drive 472 for reading the RLE encoded data for each slide. The control information and slide data are received by a minicomputer 474, such as PDP 11, having a memory of suitable size to store the RLE data for one entire slide.

The computer 474 receives the RLE data from magnetic tape, one slide at a time, converts these data into raster point grey level intensities and outputs these grey levels, one raster point at a time, to a controller 476. Interspersed between the grey levels, the computer also issues commands to the controller for operating a photographic system indicated generally at 478.

The controller 476 accepts the digital intensity grey level data from the computer and converts it into analog line scan and intensity modulation signals to drive a high-resolution cathode ray tube 480. The controller also generates signals to activate a camera 482 and a color wheel 484 in the photographic system 478.

The cathode ray tube 480 has a resolution of 4080.times.4080 raster points. This CRT has a 5" diameter flat face to provide a clear image for the photographic system 478.

The photographic system 478 views the CRT screen and records the images displayed. The camera 482 is capable of exposing a single frame at a time with the shutter and film advance under control of the controller 476. The color wheel 484 has disposed thereon red, green, blue and clear photographic filters. This color wheel is used to produce color pictures by primary color addition. Three black and white images are displayed by a CRT, each giving the intensity of one of the primary colors. Each image is passed through an appropriate filter and recorded on color film, the color picture being produced by superimposing the three primary color images on the same film frame. The clear filter is used for black and white photography. The position of the color wheel is changed at the appropriate times by the controller 476. Both the color wheel and the camera are surrounded by a light-tight enclosure 486.

As explained above, picture imaging and photography devices suitable for the use of the system according to the present invention are available commercially. A preferred device is the Celco CFR 2000.

As may be appreciated from the foregoing description, the automatic picture producing system according to the present invention is susceptible to various modifications, changes and adaptations as will occur to those skilled in the art. Although the apparatus has been described with reference to certain preferred embodiments thereof, it is intended that the scope of the present invention is limited only by the following claims.

This appendix contains full statements of the computer programs described above for use in the apparatus according to the present invention.

Section 6.1 sets forth the microcomputer variables and arrays which are used in the microcomputer program to create a box chart. Section 6.2 sets forth a microcomputer program, written in BASIC, for creating the box chart. Section 6.3 sets forth a slide computation program, written in FORTRAN, for producing a slide containing an organization chart. In both sections, 6.2 and 6.3 the subroutines are separately listed following the main, control program.