A METHOD OF PRINTING FONTS

Abstract: A programming language is disclosed which is optimized for the specification of inks for a printing system using two color, black plus a highlight color. The first group of statements name the primary colors, such as black, and red or magenta. Next specified are the catalog name and the palettes which make up the catalog. A palette is a collection of inks, each ink being defined as a tile composed of two bit maps which together are referred to as a screen, each bit map identifying the pixels in the tile to be printed in the associated primary color. Each bit pattern line is specified in the language by an equivalent binary number.

Description: The present invention relates to a method of printing fonts using any combination of two colorants on an output medium as set out in the appended claims. To add highlight color to a typical black and white print, a xerographic printer can be designed with a tri-level development process. The photoconductor is charged in the form of an image, where some areas are charged positively and some areas are charged negatively relative to non-image areas. Then, by using black toner with a positive potential and a primary color toner with a negative potential, both black text and colored highlight areas can be printed on the same print in one pass. These highlight areas can be regular shapes, such as a colored borders or highlighted areas of the page, or more complex shapes such as a rough approximations of figures such as flowers. For the remainder of this document, it will be assumed that one of the colors is black, but this is not necessary. The process is equally workable for a combination of two other colors. Colored inks are typically produced in the primary colors red, green and blue. Then, the printer, at any given moment, will have black toner and one toner of one of these three primaries. It is left to the user to load any primary color, and to change to another primary color at any time by removing the original toner cartridge and inserting another. Most printers typically print characters in a solid color, usually black. In a tri-level printer it would be equally typical to print text in either solid black or solid color. To print variations of color that can be produced from two primaries is difficult. Starting with black and red ink, for instance, the operator can specify a number of matrices, each containing any number of pixels and then assign the colors red and black to the pixels to create a range of colors from light pink to dark red. However, the specification of each pixel in a matrix for each color is a time consuming process. In addition, for each color, the resultant matrix must be printed out to check its color, texture and density, and redone if the print is not as desired. Also several palettes, each having as many as 100 colors, is typical. A fast and systematic method of generating colors is required. US-A-4 905 091 discloses a recording data processor comprising a first bit map memory for storing recording data, a second bit map memory for storing color data representing a reproduction color of the recording data stored in the first bit map memory, for each recording data, and a generation circuit for generating recording data for each color based on the recording data fetched from the first bit map memory and the color data fetched from the second bit map memory. The present invention relates to a language for producing colors in an organized way. The first group of statements names the primary colors available to the printer. These colors may be used individually, or in sets. Common sets of colored inks for printers are red, green and blue, and magenta, yellow and cyan. Any of these, or any other colorant, can be specified in this first statement. The next statement is the naming of color catalogs. Different departments, or different people using one printer, may have different requirements in terms of textures, densities and preferred primary inks. It is therefore necessary that there be more than one catalog available to the users. Next, within each catalog, several palettes will be identified. One user may want, for example to, create palettes that can be described as "pastels", "bold", "winter", etc. Next, the user will create and identify bit maps which will be used to create the colors. Bit maps can range from 2x2 to 8x8 pixels, and can also be rectangular, such as 2x4 or 8x2. The bit "patterns" themselves are completely variable. For example, the eight bits on one line can be spread out evenly (10101010) or grouped together (11110000). If the grouping is large enough, it will be visible to the eye, and therefore, any texture from smooth color to a checkerboard or herringbone pattern can also be produced using this system. Of course, the resultant printed colors will differ from one another in color and texture, depending on the printing characteristics of the printer and the colorant. For the user's convenience, a large bit map can be created by repeating a smaller bit map the required number of times. For example, if an 8x8 pixel bit map having a 10101010 pattern is required, it can more easily be created by accessing a previously generated 2x2 pixel bit map having "10" in the first line and "01" in the second line, and repeating it 16 times to form the 8x8 pixel bit map. Next, the user will create and identify screens, a screen being a pair of equally sized and shaped bit maps. One of the bit maps will identify the pixels which are to be printed in black, and the other is used to identify the pixels to be printed in the other color. In the alternative, the user may create a screen directly, without any reference to previously defined patterns. The next step is to create and identify actual palette colors by combining screens and primary colors. These can be experimentally printed out and, if the result is not as expected, new bit maps, screens and colors can be created to improve and broaden the palette color selection. For the user's convenience, patterns which are bit maps can be referenced from other palettes and catalogs. The final result is a complete collection of bit maps, screens and colors arranged in palettes and catalogs, which can be loaded into a two color printer for printing, typically, black text with colored highlight areas. The present invention will now be described by way of example with reference to the accompanying drawings, in which: Fig 1 is a table showing ink catalog header; Fig 2 is a font list; Fig 3 is a list of entries relating to the primary colours; Fig 4 is a palette directory; Fig 5 is a palette header. Fig 6 is a screen set directory; Fig 7 is a pattern directory; Fig 8 is a color directory; Fig 9 is a texture directory; Fig 10 is a directory of screen definitions; Fig 11 is a screen definition; Fig 12 is is a pattern definition; Fig 13 is a color definition; Fig 14 is a texture definition; Fig 15 is a large fill character; Fig 16 is a 7X32 leading dots character; Fig 17 is a 3X2 leading dots character; Fig 18 is a 7X7 left corner character; Fig 19 is a 32X7 leading scans character; Fig 20 is a 7X32 trailing dots character; Fig 21 is a 7X7 right corner character; Fig 22 is a 32X32 mask; Fig 23 is a 32X32 mask per Interpress standard (a byte stream); Fig 24 is a 32X32 mask in DEC memory; Fig 25 shows the difference between a color which has uniform appearance and a texture which has visible structure; Fig 26 is a pictorial view of the relationship between screens, colors, patterns and textures; Fig 27 is an overall data flow diagram of the compiler; Fig 28 is a more detailed diagram of the ink compiler; Fig 29 is a more detailed diagram of the parse command section; Fig 30 is a more detailed diagram of the build command structure section; Fig 31 is a more detailed diagram of the execute command section; Fig 32 shows a new entry being added to the new symbol table; Fig 33 shows the symbol table; Fig 35 shows the composition if ICATALOG structure D; Fig 36 shows the composition of PRIMARY structure D; Fig 37 shows the composition of PALLETTE structure D; Fig 38 shows the composition of COLOR Sub-Option.D; Fig 39 shows the composition of Model Sub-Option.D; Fig 40 shows the composition of Scnset Sub-Option structure.D; Fig 41 shows the composition of Primary Sub-Option structure.D; Fig 42 shows the composition fo Values Sub-Option structure.D; Fig 43 shows the composition of Copts structure.D; Fig 44 shows the composition of Scanset structure.D; Fig 45 shows the composition of Screen structure.D; Fig 46 shows the composition of Data Sub-Option structure.D; Fig 47 shows the composition of Size Sub-Option structure.D; Fig 48 shows the composition of Dtype Sub-Option structure.D; Fig 49 shows the composition of Plib Sub-Option structure.D; Fig 50 shows the composition of Pindex Sub-Option structure.D; Fig 51 shows the composition of SOPTS structure.D; Fig 52 shows the composition of TEXTURE structure.D; Fig 53 shows the composition of Pattern Sub-Option structure.D; Fig 54 shows the composition of Ink Sub-Option structure.D; Fig 55 shows the composition of PATTERN structure.D; Fig 56 shows the composition of POPTS structure.D; Fig 57 shows the composition fo END structure.D; The preferred embodiment will now be described in detail. Fig 1 shows the arrangement of 13 words of data in the header of the catalog. The first three words in the header block contain the ink catalog name and file type in RAD50. The version of this ink catalog is the version number, for example, 1. The ink catalog type is: 1 - Monochrome, 2 - Highlight, and 3 - Full Color. For this embodiment, the type will be 2. The two time/unique words are a unique field within the header block. For example, this will contain the date and time of compilation. The following six words contain the block and word offsets which point to the start of the list of fonts, the list of primaries, and the start of the palette directory. The header portion of the ink catalog was designed to include key pieces of information. Such information includes three words which contain the name of the ink catalog plus the file type in Radix 50 format so that any referencing task could verify that this is indeed the correct ink catalog file that it needs. Next, a version word was added so that if the structure of an ink catalog changed, it could be easily checked by this version word. Next, an ink catalog type word was added to show which target machine this ink catalog was built for. Next, two words in the header contain unique words for each ink catalog. The time/unique words were added so that the task could specify the exact ink catalog it used during compilation to create a form. Input could then verify that the current ink catalog that resides on the disk is indeed the correct one. The next six words which are the block and word offsets pointing to the list of fonts, the list of primaries, and the palette directory were added so that the header may expand should there be a need to include additional information. The word offsets for the primary list and the palette directory are zero since these begin on a block boundary. All block and word offsets in this ink catalog structure are relative to the beginning of the ink catalog. Also, all reserved words will be zero. Immediately following the header is the list of fonts used in this ink catalog Fig 2 is a font list. The number of fonts is the number the ink compiler has built within this ink catalog. The font block and word offsets are two words that point to an area within this ink catalog that has the user defined screens and inks in a font file format. The end of the font list is padded with zeros until a block boundary is reached. The font list follows immediately after the ink catalog header and is variable in length. First, the number of fonts is specified, followed by the block and word offsets that point to the area within this ink catalog that contains the user defined screens, colors, and textures for this ink catalog in a font file format. The font word offset is zero since the font data always begin on a block boundary. These fonts are accessed by the character reference word specified in a screen, color, or texture definition structure. If the list of fonts does not end exactly on a block boundary, there will be padding with zeroes until the next block boundary. Fig 3 is a list of primary colors. The primary List begins with the number of primary entries. The primary entries are twenty words each. Sixteen words contain the primary name in ASCII, one word contains the primary's ID number, and three words contain the color coordinates. The three RGB value words are the color coordinates (RGB model) for this primary. Each is scaled by a factor of 10000 and expressed as an integer. The end of the primary List is padded with zeroes until a block boundary. The primary list begins on a block boundary for fewer disk accesses. The list of primaries starts with a word containing the number of primary entries. Each primary entry is a fixed length of twenty words. The first sixteen words contain a primary name which can be up to thirty-two ASCII characters. Should the primary name length utilize less then thirty-two characters, then the rest of the space will be filled with zeroes. Following the name will be the primary's ID number and the three color coordinates. The color coordinates are scaled by ten thousand and expressed here as integers. If the list of primaries does not end exactly on a block boundary, there will be padding with zeroes until the next block boundary. The list of primaries is not expected to be large. All entries in the primary list are in alphabetical order using the primary name. By having a fixed length entry and all entries in alphabetical order, a binary search may be done to find a particular primary quickly. Fig 4 is the pallette directory. The first line is a list of all the palettes in the ink catalog. First is the number of palette entries. Then the palette entries follow. The palette entries are eighteen words long. Sixteen words contain the palette name in ASCII and the following two words contain the block and word offsets to the palette definition. At the end of the first pallette entry, other palette entries may follow. The end is padded with zeroes until a block boundary The palette directory begins on a block boundary. This is for fewer disk accesses. The palette directory starts with a word containing the number of palette entries. Each palette entry is a fixed length of eighteen words. The first sixteen words hold the palette name that could be up to thirty-two ASCII characters. Should the palette name length utilize less than thirty-two characters, then the rest of the space will be filled with zeroes. The block and word offsets point to the exact location for this palette definition. The word offset is zero since a palette definition always begins on a block boundary. If the palette directory does not end exactly on a block boundary, there will be padding with zeroes until the next block boundary. Using the palette name, all entries in the palette directory are in alphabetical order. By having a fixed length entry and all entries in alphabetical order, a binary search may be done to find a particular palette quickly. The following structures define a palette structure. There may be multiple palette structures within an ink catalog. There may exist a default palette which is created by the ink compiler. The contents of it are all the global screens and patterns that the user may have defined prior to the first palette command. The default palette is not to be confused with a user specified palette defined using the palette command. Fig 5 is the palette structure. The first six words are reserved in case there is a need for the palette header to hold additional information. The next eight words are the block and word offsets to the SCNSET, pattern, color, and texture directories. The end is padded with zeros until a block boundary. The palette structure header begins on a block boundary. This is for fewer disk accesses. It is a fixed length of fourteen words. Within the palette header, there are six reserved words in case there is a need for the palette header to hold additional information. The next two words are the block and word offsets which point to the beginning of the linked and sorted color definitions. The next eight words are the block and word offsets to the screen set, pattern, color, and texture directories. Because the directories always begin on a block boundary, the word offsets are zero. After a palette header there will be padding with zeroes until the next block boundary so that the SCNSET directory that follows will begin on a block boundary. Fig 6 is the SCNSET directory. First is a list of all the SCNSETs within this palette. First is the number of SCNSET entries. Then the SCNSET entries follow. Each SCNSET entry is eighteen words which consists of the SCNSET name in ASCII and then two words that contain the block and word offsets to the SCNSET definition. All SCNSET entries are in alphabetical order. Other SCNSET entries may follow. The end is padded with zeros until a block boundary. The screen set (SCNSET) directory begins on a block boundary. This is for fewer disk accesses. Each entry is a fixed length of eighteen words. The first sixteen words hold the screen set name that can be up to thirty-two ASCII characters. Should the screen set name utilize less then thirty-two characters, then the rest of the space will be filled with zeroes. The block and word offsets point to the exact location of the screen set definition. If the screen set directory does not end exactly on a block boundary, there will be padding with zeroes until the next block boundary. Using the screen set name, all entries in the screen set directory are in alphabetical order. By having a fixed length entry and all entries in alphabetical order, a binary search may be done to find a particular screen set quickly. Fig 7 is the pattern directory. The number of pattern entries is a list of all the patterns within this palette. First is the number of pattern entries, which are as discussed above. The pattern directory begins on a block boundary. This is for fewer disk accesses. Each entry is a fixed length of eighteen words. The first sixteen words hold the pattern name that can be up to thirty-two ASCII characters. Should the pattern name utilize less then thirty-two characters, then the rest of the space will be filled with zeroes. The block and word offsets point to the exact location of the pattern definition. If the pattern directory does not end exactly on a block boundary, there will be padding with zeroes until the next block boundary. Using the pattern name, all entries in the pattern directory are in alphabetical order. By having a fixed length entry and all entries in alphabetical order, a binary search may be done to find a particular pattern quickly. Fig 8 is the color directory. The number of color entries is a list of all the colors within this palette. First is the number of colors entries. Then the color entries follow. Each color entry is eighteen words which consists of the color name in ASCII and then two words that contain the block and word offsets to the color definition. All color entries are in alphabetical order. Other color entries may follow. The end is padded with zeroes until a block boundary. The color directory begins on a block boundary. This is for fewer disk accesses. Each entry is a fixed length of eighteen words. The first sixteen words hold the color name that can be up to thirty-two ASCII characters. Should the color name utilize less then thirty-two characters, then the rest of the space will be filled with zeroes. The block and word offsets point to the exact location of the color definition. If the color directory does not end exactly on a block boundary, there will be padding with zeroes until the next block boundary. Using the color name, all entries in the color directory are in alphabetical order. By having a fixed length entry and all entries in alphabetical order, a binary search may be done to find a particular color quickly. Fig 9 is a texture directory. The number of texture Entries is a list of all the textures within this palette. First is the number of texture entries. Then the texture entries follow. Each texture entry is eighteen words which consists of the texture name in ASCII and then two words that contain the block and word offsets to the texture definition. All texture entries are in alphabetical order. Other texture entries may follow. The end is padded with zeroes until a block boundary. The texture directory begins on a block boundary. This is for fewer disk accesses. Each entry is a fixed length of eighteen words. The first sixteen words hold the texture name that can be up to thirty-two ASCII characters. Should the texture name utilize less then thirty-two characters, then the rest of the space will be filled with zeroes. The block and word offsets point to the exact location of the texture definition. If the texture directory does not end exactly on a block boundary, there will be padding with zeroes until the next block boundary. Using the texture name, all entries in the texture directory are in alphabetical order. By having a fixed length entry and all entries in alphabetical order, a binary search may be done to find a particular texture quickly. Next are the SCNSET, pattern, color, and texture definitions. To allow for fewer disk accesses, all SCNSET definitions will begin on a block boundary. All pattern, color, and texture definitions less then 512 bytes will be stored in a block (none will span over two blocks). If there is insufficient amount of space available in a block to fit a pattern, color, or texture definition, then zeroes will pad to the block boundary and the definition will begin at the next block. All pattern, color, and texture definitions greater than 512 bytes will begin on a block boundary and may span multiple blocks. Fig 10 is the SCREEN definition. The number of SCREEN definitions is the number of SCREEN Definitions that are in this SCNSET definition. The maximum distance is calculated using value b and value h of each screen. Value b is the percentage of black and value h is the percentage of highlight color for this screen. The block offset points to the screen definition. Other SCREEN directory entries may follow. Fig 11 is a SCREEN definition. There are two character reference words used to locate the black and the highlight bitmaps for this screen. Each character reference word holds the font index which is the index into the list of fonts at the beginning of the ink catalog. The character codes for the black bitmaps begin at 16 and the character codes for the highlight bitmaps begin at 136. The size N and size M values are the N columns by M rows for the bitmaps that follow. Although the bitmaps for this screen are defined in a font as specified by the character references, they are also defined here in the screen definition. The length of the bitmap is given in words and is the same for all the following bitmaps. Other screen definitions may follow. This is the end of the SCNSET definition. Other SCNSET definitions may follow. A screen set (SCNSET) definition will always begin on a block boundary to allow for fewer disk accesses. It is not necessary for screen set definitions to be stored in any specific order since they can be searched using the SCNSET directory. The first word of a screen set definition contains the number of screen definitions that are included in this screen set definition. The next word contains the maximum distance calculated for the screens in this screen set. The maximum distance is the largest minimum distance where a minimum distance is calculated by taking a screen in the screen set and finding all the distances to every other screen in the screen set. After all the distances are calculated for a single screen, the smallest of these distances is considered a minimum distance. Distance is (value b1 -value b0 ) 2 + (value h1 - value h0 ) 2 . A screen set definition contains a screen directory which is made up of screen directory entries. There is a screen directory entry for every screen definition within the screen set. This directory will facilitate searching for a particular screen in a screen set. A screen directory entry is a fixed length of ten words. It begins with two words that are the percentages of black (value b ) and highlight color (value h ). Two reserved words were added for the full color implementation of the ink catalog so that a total of four values may be specified. Next, there are the block and word offsets which point to the actual screen definition. Thus, all the screens in a screen set have a screen directory entry that points to the actual screen definition. Screen directory entries are sorted by values beginning from lowest to highest value b 's. Should there be identical value b 's, then those entries will be from lowest to highest value h 's. The screen directory entries are sorted to aid in searching for a particular screen definition. Searching will be done by values. If a certain screen does not exist within a screen set, the closest screen can be found using the maximum distance. A screen definition is variable length. It begins with two words that contain character reference b and character reference h . Character reference words are used to locate the black and the highlight bitmaps defined for this screen. Each character reference word represents the font index which is the index into the list of fonts at the beginning of the ink catalog. The character codes for the black bitmaps begin at 16, and the character codes for the highlight bitmaps begin at 136. A zero character reference indicates that there is no font for this screen. The two reserved words that follow will be used in the full color ink catalog for additional character references. Next, there are the size N and size M values which show the number of columns (bits) and rows (words), respectively, for the bitmaps that will follow. The range of size N is 1 to 2 10 and the range of size M is 1 to 2 10 . Next, there are two variable length bitmaps. The length of the bitmap specified is the length of a single bitmap and all the bitmaps that may follow are the same size. The number of bitmaps signifies the number of bitmaps that will follow. Bitmap b is for black and bitmap h is for highlight color. For future ink catalogs for full color, more bitmaps may follow bitmap h . Although the bitmaps are defined in a font as specified by the character references for use in line/meta mode, they are also defined here for use in Interpress mode. Fig 12 is the pattern definition. It was decided that fonts would not be built for patterns thus the use of a character reference word was unnecessary. In its place, there is provided a reserved word which is equal to zero. The size N and size M values are the N columns by M rows of the bitmap that follows. Although the pattern is defined in the above specified font, it is also defined here in the pattern definition. The length of the bitmap is given in words. This is the end of pattern definition. Other pattern definitions may follow. A pattern definition may begin on a block boundary to allow for fewer disk accesses. Included in a pattern definition are a reserved word (0), size N , size M , and a bitmap. See the screen definition for the details regarding these terms. It is not necessary for pattern definitions to be stored in any specific order. They can be searched using the pattern directory. Fig 13 is the color definition. This embodiment can use only black plus one other color. Thus, we have indices for two colors. The low order byte contains index 1 and the high order contains index 2 . Index 1 contains the dominant primary used in this color. Index 2 may be zero if there is only one primary used in this color. There are two character reference words used to locate the black and the highlight bitmaps for this color. Each character reference word holds the font index which is the index into the list of fonts at the beginning of the ink catalog. The character codes for the black bitmaps begin at 16, and the character codes for the highlight bitmaps begin at 136. The block offset to screen points to the screen that is to be used to implement this color. This is the end of the color definition, other color definitions may follow. A color definition may begin on a block boundary to allow for fewer disk accesses. A color definition is a fixed length of eight words. It begins with the primary index word. The lower bytes contains index 1 and the higher order byte contains index 2 . Index 1 contains the dominant primary color used. Index 2 may be zero if there is only one primary color is used. A reserved word was added to hold two more primary indices for a multiple highlight color implementation. Then, there are two words that contain character reference b and character reference h that are copied from the screen definition used to implement this color. The character reference words are repeated here for speed of access in line mode. The character reference words are used to locate the black and the highlight bitmaps for this color. Each character reference word holds the font index which is the index into the list of fonts at the beginning of the ink catalog. The character codes for the black bitmaps begin at 16, and the character codes for the highlight bitmaps begin at 136. A zero character reference indicates that there is no font for this color. The two reserved words that follow will be used in the full color ink catalog for additional character references. The next two words contain the block and word offset to the screen that is used to implement this color. This will be used by the Interpress decomposer (IPD) to obtain the bitmaps for inks referenced by name. It is not necessary for color definitions to be stored in any specific order. They can be searched using the color directory. Fig 14 is the texture definition. This embodiment can use only black plus one other color. Thus, we have indices for two primary colors. The low order byte contains index 1 and the high order byte contains index 2 . Index 1 contains the dominant primary color used in this texture. Index 2 may be zero if there is only one primary color used in this texture. There are two character reference words used to locate the black and the highlight bitmaps for this texture. Each character reference word holds the font index which is the index into the list of fonts at the beginning of the ink catalog. The character codes for the black bitmaps begin at 16, and the character codes for the highlight bitmaps begin at 136. The size N and size M values are the N columns by M rows of the bitmaps that follow. Although the bitmaps for this texture are defined in a font as specified by the character references, they are also defined here in the texture definition. The length of the bitmap is given in words and is the same for all the following bitmaps. This is the end of texture definition. Other texture definitions may follow. This is the end of palette structure. Other palette structures may follow. The end is padded with zeroes until a block boundary. This is the end of the ink catalog. A texture definition may begin on a block boundary to allow for fewer disk accesses. A texture definition is of variable length. It begins with the primary index word. A reserved word was added to hold two more primary indices for a multiple highlight color implementation. Then, there are two words that contain character reference b and character reference h . Character reference words are used to locate the black and the highlight bitmaps for this texture. Each character reference word holds the font index which is the index into the list of fonts at the beginning of the ink catalog. The character codes for the black bitmaps begin at 16, and the character codes for the highlight bitmaps begin at 136. A zero character reference indicates that there is no font for this texture. The two reserved words that follow will be used in the full color ink catalog for additional character references. Next, there are the size N and size M values which show the number of columns (bits) and rows (words), respectively, for the bitmaps that will follow. The range of size N is 1 to 2 10 and the range of size M is 1 to 2 10 . Next, there are two variable length bitmaps. The length of the bitmap specified is for all bitmaps that follow. The number of bitmaps signifies the number of bitmaps that will follow. Bitmap b is for black and bitmap h is for highlight color. For future ink catalogs for full color, more bitmaps may follow bitmap h . Although the bitmaps are defined in a font as specified by the character references for use in line/meta mode, they are also defined here for use in Interpress mode. It is not necessary for texture definitions to be stored in any specific order. They can be searched using the texture directory. After the last palette structure is where the font file data resides. Each font that resides within the ink catalog begins on a block boundary. Fonts that do not end on a block boundary will be padded with zeroes until the next block boundary. The following discusses issues related to the creation and use of inks. A primary color is a dry ink toner that is applied through a stencil called a mask in order to image a color. The mask determines the portion of the page to be altered by the primary color. Masks are implemented within an ink in two ways: as fill characters and as bit maps. Colors are inks with no visible structure and are implemented using a mask for each primary (one for black, one for highlight). Textures are inks with visible structure and are also implemented using a mask for each primary (one for black, one for highlight); the only difference between a color and a texture is in the makeup of the mask. Whereas a color is page-aligned and limited to an 8 bit X 8 bit ink, textures are object-aligned. The predominant primary color of an ink is the primary color which contributes the highest percentage to the specified color. This is always the first primary in the list of primaries provided by the ink catalog searching task. For inks, the FST entry for character code O'14' should initially contain a negative character alignment value and the HighlightColorStart or HighlightColorEnd CD-code depending on the predominant primary color of the ink (HighlightColorStart if the predominant primary is any highlight color; HighlightColorEnd if the predominant primary is black). The FST entry for character code O'15' should initially contain a negative character alignment value and the HighlightColorEnd CD-code. In addition, the FST entries for character codes O'12' and O,13' should initially contain a negative character alignment value and the HighlightColorStart and HighlightColorEnd CD-codes respectively for use by applications which fill rectangles using color. This scheme allows text (preceded in the DL by character code O'14') to be imaged in the predominant primary color of the same ink used to fill rectangles (when the fill characters are preceded in the DL by character codes O'12' or O'13' to select the appropriate primary). These CD-codes will be updated at print-time, thereby enabling colorized resources to be printed on monochrome black-only printers. The following discusses an implementation for filling boxes with colors or textures using a combination of large fill characters, leading dots characters, trailing dots characters, leading scans characters, left corner characters and right corner characters. Table 2.4 documents the character code groupings for colors and textures. Table 2.5 documents the character code assignments for colors. This section discusses the implementation of fill characters in an ink's font. Large Fill Character A 32 bit X 32 bit character (derived from an 8 bit X 8 bit ink) with CDF horizontal repeat used to expand its width to 1024 bits. The large fill character is illustrated in Figure 15. The right columns are replicated three times to give a width of 32 bits, and the bottom rows are replicated three times to give a height of 32 bits. The FST values are: AL = 020000 (CDF = 010 = horizontal repeat). FMA = @row 0. X = width = 128 bytes (1024 dots). Y = height = 32 scans. FSS = spacing = 1024 dots. In all cases where a primary does not contribute to a color, the corresponding black or color fill characters are represented in the ink font as space meta-codes with the appropriate FSS spacing, thereby saving font memory and disk space. Leading Dots Characters 7 characters [from 1..7 bits wide and 32 bits high, derived from an 8 bit X 8 bit ink] representing the rightmost bits of the ink pattern, padded with zeroes to 16 bits such that their bitmaps will be addressable as left corner characters. The 7 bit X 32 bit leading dots character is illustrated in Figure 16. The FST values are: AL = 0. FMA = @row 0. X = width = 2 bytes (16 dots). Y = height = 32 scans. FSS = spacing = 7 dots. The 3 bit X 32 bit leading dots character is illustrated in Figure 17. The FST values are:AL = 0. FMA = @row 0 X = width = 2 bytes (16 dots). Y = height = 32 scans. FSS = spacing = 3 dots. Left Corner Characters 49 characters [from 1..7 bits wide and from 1..7 bits high, derived from an 8 bit X 8 bit ink] representing the lower-rightmost bits of the ink pattern, padded with zeroes to 16 bits such that they may share bitmap space with leading dots characters. The 7 bit X 7 bit left corner character is illustrated in Figure 18. The FST values are: AL = 0FMA = @row 1 of leading dots character (7 X 32)X = width = 2 bytes (16 dots)Y = height = 7 scans. FSS = spacing = 7 dots Leading Scans Characters 7 characters (32 bits wide and from 1..7 bits high, derived from an 8 bit X 8 bit ink) with CDF horizontal repeat used to expand their widths to 1024 bits and representing the lowermost bits of the ink pattern. These characters share bitmap space with the large fill character. The 32 bit X 7 bit leading scans character is illustrated in Figure 19. The FST values are: AL = 020000 (CDF = 010 = horizontal repeat). FMA = @row 25 of large fill character. X = width = 128 bytes (1024 dots). Y = height = 7 scans. FSS = spacing = 1024 dots. Trailing Dots Characters 7 characters [from 1..7 bits wide and 32 bits high, derived from an 8 bit X 8 bit ink] representing the leftmost bits of the ink pattern, padded with zeroes to 16 bits such that their bitmaps will be addressable as right corner characters. The 7 bit X 32 bit trailing dots character is illustrated in Figure 20. The FST values are: AL = 0. FMA = @row 0. X = width = 2 bytes (16 dots). Y = height = 32 scans. FSS = spacing = 7 dots. Right Corner Characters 49 characters [from 1..7 bits wide and from 1..7 bits high, derived from an 8 bit X 8 bit ink] and representing the lower-leftmost bits of the ink pattern, padded with zeroes to 16 bits such that they may share bitmap space with trailing dots characters. The 7 bit X 7 bit right corner character is illustrated in Figure 21. The FST values are: AL = 0. FMA = @row 1 of trailing dots character (7 X 32). X = width = 2 bytes (16 dots). Y = height = 32 scans. FSS = spacing = 7 dots. Bitmaps are used to implement masks and therefore observe the Interpress conventions for bit- and byte-ordering. For instance, a 32-pixel X 32-pixel mask consists of 1024 pixels and can be visualized as illustrated in Figure 22. It would be implemented as a one-sample-per-pixel pixel array and would be packed as illustrated in Figure 23 (note that this illustrates memory as specified by the Interpress standard and does not reflect the DEC/Intel memory addressing scheme) These pixels would be transferred as a byte stream to the printing system's disk and eventually to memory as illustrated in Figure 24 (note that this illustrates memory according to the DEC/Intel memory addressing scheme): Ink Compiler The ink compiler is a non-print time, stand-alone utility that allows the user to define and create specific inks that can be used on the printer system. With this utility, the user can define palettes, colors, textures, patterns, and screens using commands similar to job source language (JSL). A standard ink catalog is provided in the system software. The following terms are defined as follows: Primary. This is a dry ink (toner). Ink. Imaging operators for the printer are described as applying a primary color to the page through a stencil called a "mask". The mask determines the portion of the page to be altered by the primary color. The ink and possibly the previous content of the altered portion of the page determine the appearance of the portion of the page. An ink can be transparent or opaque. Opaque inks alter the page by replacing the previous contents. Transparent inks allow the previous content of the page to show through the non-colored pixels of the ink. Color. This is an ink without gross structure. Colors are implemented using a halftone screen for each primary, black and color, which specifies the arrangement of the black and color pixels to be printed. This is also known as a "tint". Screen or Halftone Screen. This is used to implement a color. It specifies the arrangement of the black and color pixels to be printed. Texture. This is an ink with visible structure. A texture is the result of combining one or more color and pattern pairs. A pattern is a bitmap indicating the portion of the texture which is to have the color associated with that pattern. The pairs are processed in the order in which they are specified and the color is imaged as an opaque ink using the pattern as a mask. Pattern. This is a mask used to construct a texture. It can also be used to create a screen. Palette. A collection of screens, patterns, and inks. Ink Catalog. A collection of palettes. Fig 25 shows the difference between a color which has uniform appearance and a texture which has visible structure. Also, shown are multiple palettes where colors and textures are defined. Ink Source Language. This section defines the structure and syntax of the ink source language (ISL) which is used to create inks. Inks are organized into a multi-level hierarchy which is composed of catalogs, palettes, and palette items. The palette items are individual inks. Inks are grouped into collections called palettes. A group of users may employ several palettes for different applications. All the palettes used by the group are stored in an ink catalog. The use of separate catalogs for different groups of users permits each group to define and name inks independently. Creating Inks There are two types of inks: colors and textures. Inks typically contain two types of repeating structures. One type called micro-structure, such as a halftone, is non-visible or barely visible for colors, and the second type, such as a large checkerboard pattern, called macro-structure is easily visible for textures. The ink is defined by specifying a minimum portion of the structure which can be replicated to make the ink as large as the page. Because all colors are page-registered, a color is aligned with the page such that its origin and the origin of the page coincide. For textures, an optional offset allows the repeating structure of the ink to be aligned with the object being printed. An ink is defined by indicating the pixels to receive each of the primaries provided by the printing process. A monochrome printer has a single primary, typically black. A highlight color printer has at least two primaries, such as black and red. All colors that can be produced are created by combining one or more primaries on the printing medium. The printer assumes that the printing medium is white and no attempt is made to correct for non-white media. A color is specified by a device-independent description comprising selection of one of the supplied parametric color models and color parameters to be applied to that model. A color typically has a uniform appearance with no visible structure when viewed from a normal reading distance. A texture is a composite ink constructed from previously defined inks and patterns which indicate the portion of the texture to receive each ink. In contrast to colors, textures typically have a non-uniform appearance exhibiting some form of gross structure. Fig 26 is a pictorial view of the relationship between screens, colors, patterns and textures. The following sections describe the ink source language (ISL) in detail. Defining Primaries. The primary statement is provided to associate a primary name with a dry ink (toner) identification number. This is used to identify that particular primary when communicating to or from the IOT. The format of the primary statement is as follows: 'primaryname': Primary ID = n, RGB = (rvalue, gvalue, bvalue); where n is from 0 to 255, and rvalue, gvalue, bvalue are expressed in decimal, scaled by 10,000, and given as an integer. Defining Ink Catalogs An ink catalog contains palettes which contain ink definitions that are designed for a specific user community. In many cases, a single catalog will be sufficient for an entire organization. Multiple ink catalogs may be established for specific groups within an organization that have different ink requirements. An ink catalog definition is initiated with the ICATALOG statement. The ink catalog comprises all palettes defined before the next ICATALOG statement, END statement, or physical end-of-file. All entities defined prior to and outside an ink catalog will be made globally available. Palette names must be unique within an ink catalog, but may be reused in different catalogs. The format of the ICATALOG statement is as follows: 'inkcatalogname': ICATALOG; Defining Palettes Colors and textures are defined in collections called palettes. Multiple palettes may be required to support the needs of different user groups or to support the needs of different applications. The contents of a palette are defined by all the statements following the PALETTE statement. The palette comprises all colors and textures defined before the next ICATALOG statement, PALETTE statement, END statement, or physical end-of-file. Ink names must be unique within a palette, but may be reused in different palettes. The format of the PALETTE statement is as follows: 'palettename':PALETTE Defining Colors Color definition associates a color name with a specification for a desired appearance. This specification includes the color model, color parameter values, primaries, and screenset. Color models provide a method for specifying color in a manner that is easy to use and extensible. Four models are described below, providing a means of easily specifying colors for printers with capabilities ranging from monochrome to highlight and full color. Currently defined models are MONOCHROME, TINT, and HSM (Highlight Shade and Mixture). The user is advised to select the least capable model which provides the desired capabilities since this will minimize the amount of information that must be supplied. The interpretation of the color parameters values depends on the color model specified with the MODEL command. These values are used to associate with this color a screen within a screenset specified by the SCNSET command. Colors can access screensets that are global or residing within the current ink catalog and palette. Also dependent upon the color model are the primaries given by the PRIMARY command. Because the interpretation of the values and the primaries are dependent on the color model, the user should specify the model first unless the default model is desired. The general form of the COLOR statement is as follows: 'colorname': COLOR [colorcommands] [,VALUE[S] = {n|(n[,n]...)}]; Colorcommands are separated by a comma. colorcommands: = MODEL = { MONOCHROME |TINT|HSM|RGB|QUANTITY} {PRIMARY|PRIMARIES} = {'primaryname'|('primaryname' [,'primaryname']...) } (The default primary name is the one with ID = 0. If however, no primary is given with ID = 0, then there will be no default primary. If this command is used with the COPTS statement, then the first primary name given will be used when creating a color with the MONOCHROME or TINT model and the first two will be used with the HSM or QUANTITY model) SCNSET = {'screensetname'| DEFAULT } The COPTS statement is optional, but is provided to facilitate definition of colors by allowing default values for commands of the COLOR statement to be specified. The default value for a command remains in effect until a new value is specified in a subsequent COPTS statement, the end of a palette, or the end of an ink catalog. Options specified on the COLOR statement override the default values provided by the COPTS statement. The format of the COPTS statement is as follows: COPTS colorcommands; Monochrome Model In the MONOCHROME model, objects are of a single primary, typically black. The general form of the COLOR statement in MONOCHROME model is as follows: 'colorname': COLOR MODEL = MON [,colorcommands]; Tint Model In the TINT model, the objects are described as a single primary color or tints of that primary. For example, if the COLOR command specifies PRIMARIES = 'BLACK', then available colors are black and tints of black (grays). The VALUE command contains shade, where shade is in the range of 0 (white) to 100 (solid color, typically black). The general form of the COLOR statement in the TINT model is as follows: 'colorname': COLOR MODEL = TINT, VALUE = shade [,colorcommands]; Highlight Shade and Mixture Model In the Highlight Shade and Mixture (HSM) model, the objects are described as a mixture of two primaries, the normal and highlight colors, applied to give the specified shade. The normal and highlight primaries are specified by the PRIMARIES option: PRIMARIES = (normal, highlight). The VALUE command contains shade and mixture. Shade is the quantity of the combination to apply from none (0) to the maximum amount (100). Mixture is the fraction of the combination which is the highlight color, expressed as a percentage. The general form of the COLOR command in the HSM model is as follows: 'colorname': COLOR MODEL = HSM, VALUE = (shade, mixture) [,colorcommands]; Quantity Color Model In the Quantity Model, the objects are described as a mixture of two primaries, the normal and highlight colors, applied to give the specified appearance. The normal and highlight primaries are specified by the PRIMARIES option:PRIMARIES = (normal, highlight). This is similar to the HSM model. The VALUE command contains two quantities which apply to the two primaries, normal and highlight. Both quantities range from none (0) to a maximum amount (100). The general form of the COLOR command in the QUANTITY model is as follows: 'colorname': COLOR MODEL = QUANTITY, VALUE = (normal quantity, highlight quantity) [,colorcommands]; Defining Screens A screenset is a collection of halftone screens with common characteristics. Screens are used to implement colors. They specify the arrangement of the black and color pixels to be printed. The screen set is referenced by the COLOR or COPTS statement. Multiple screen sets are allowed so that the user may select the proper screen characteristics for an application. For example, one screen set may use halftone screens based on a blob growth algorithm. This screen set would be used for applications where a smooth variation in shading is required. Another screen set may use the highest possible screen frequencies. It would provide superior appearance for large tinted areas. Members of a screen set are specified by SCREEN commands following the SCNSET statement. The definition of a screen set must precede any reference to it. The format of the SCNSET statement is as follows: 'screensetname': SCNSET; Screens are halftone patterns used to implement colors. Within the SCREEN statement, there are three sets of screen commands: MODEL and VALUES; DTYPE, SIZE, and DATA; PLOC and PNAME. The MODEL AND VALUES commands are identical to those same commands in the COLOR statement. (Because the interpretation of the values and the data or patterns are dependent on the model, the user should specify the model first unless the default model is desired.) The DTYPE, SIZE, and DATA commands allow halftone patterns to be directly specified. The PLOC and PNAME commands allow halftone patterns from an external location to be specified. The interpretation of the DATA and the PNAME commands depends on the color model specified with the MODEL command. When halftone patterns are directly specified, only the smallest repeating portion of the pattern need be specified. It will be replicated to the size required by the imaging subsystem. Data values are entered in the radix specified by the DTYPE command. Alternately, the value may be specified as a string constant, preceded by the radix indicator X for hex, O for octal, B for binary or D for decimal. It is recommended that all hex values begin with a digit so the compiler will not interpret any hex letters as radix indicators. The radix indicator takes precedence over the DTYPE command. Data values are grouped by parentheses, with either one group of values per primary, or the keyword NONE indicating that the corresponding primary is not used in constructing the color. The data is organized as an array of pixels, n columns by m rows as specified with the SIZE command. This corresponds to portrait orientation with column numbers increasing across the page and row numbers increasing down the page. Data values are placed into the array with the least significant bit corresponding to the highest column number. A 1-bit indicates that ink is to be deposited for the pixel. A 0-bit indicates that no ink is to be deposited for the pixel. If the value provides more than n pixels, the excess pixels are ignored. If less than n pixels are provided, the remaining pixels are filled with zeros. If less than m rows are given, then the ink compiler will repeat those rows given to make up the difference. However, if more than m rows are given, then an error message is generated and the screen will not be created. When halftone patterns from an external location specified by the PLOC command are used, individual patterns are referred to by name in the PNAME command. In the PLOC command if the keyword CURRENT is used, the pattern location is the current ink catalog and the current palette. (NOTE: All global patterns are considered part of the current ink catalog and palette.). In the PNAME command, either a pattern name or the keyword NONE must be specified for each primary. The keyword NONE indicates that the corresponding primary is not used to construct the color. Ink catalog and palette names given in the PNAME command will override those given in the PLOC command. When using the PLOC or PNAME commands, an error message will be generated if a specified ink catalog or palette location does not exist. Also, an error message will be generated if the pattern does not exist. When a halftone pattern is specified whether directly or from an external location using the TINT model with a value of zero, it will be taken as the definition of a highlight TINT screen. The format of the SCREEN statement is as follows: The SOPTS statement is provided to facilitate definition of screens. It allows default values for commands of the SCREEN command to be specified. The default value for a command remains in effect until a new value is specified for the command in a subsequent SOPTS statement, end of a palette, or end of an ink catalog. Commands specified on the SCREEN statement override the default values provided by the SOPTS statement. The format of the SOPTS statement is as follows: Defining Textures A texture is a composite ink. A texture is constructed by "imaging" a series of patterns each with a specific ink. The patterns are treated as masks and are "imaged" with the corresponding ink in the order specified. A texture is constructed by the following process. It is initialized to all zero pixels. For each pattern-ink pair, the result is calculated as follows: texture = (texture AND (NOT (pattern))) OR (pattern AND ink) The format of the TEXTURE statement is as follows: There must be an identical number of INKs and PATTERNs. For example ,if two (2) patterns are given then two (2) corresponding inks must also be given, the first ink for the first pattern, the second ink for the second pattern. Defining Pattern Ink Source Language Command Summary 'primaryname': PRIMARY ID = n, RGB = (rvalue, gvalue, bvalue); The PRIMARY statement is provided to associate a primary name with an identification number and the RGB color coordinates. The identification number, n,is used to identify that primary in communication to or from the IOT. Rvalue, gvalue, and bvalue are scaled by 10,000 and given as an integer. 'inkcatalogname': ICATALOG; An ink catalog definition is initiated with the ICATALOG statement. 'palettename': PALETTE;A palette definition is initiated with the PALETTE statement. COPTS colorcommands; The COPTS statement is optional. It is provided to allow default values for commands of the COLOR statement to be specified. 'colorname': COLOR [colorcommands] [VALUE[S] = n|(n[, n]...)]; The COLOR statement associates a colorname with a specification for a desired appearance. Colorcommands are as follows: Ordering of ISL Statements Inks are organized into a multi-level hierarchy which is composed of ink catalogs, palettes, and palette items. When using ISL statements to define ink catalogs, palettes, or palette items, the ordering and grouping of statements are important since any item must be defined first before it can be referenced. Also, the ink compiler expects certain ordering of commands to allow the successful creation of ink catalogs. Ordering and grouping rules along with general rules are defined below. Ordering and Grouping Guidelines: The first commands specified should be the PRIMARY commands. This command allows the customer to associate the desired name with a dry ink (toner) identification number. The ink compiler needs to know this information up front 2. A PALETTE command cannot precede the first ICATALOG command in an ISL file. This is because a palette must be defined within a specific ink catalog. 3. Any command which precedes an ink catalog command is considered global. Also, any command which is after an ink catalog command, but prior to the first palette command, is considered global to all the palettes within that ink catalog. The ink compiler will only allow commands to create screens and patterns to be global. 4. Stray commands which are those commands that do not reside within a palette boundary or within the global area are not allowed. General Rules 1. Ink Catalog names must conform to the current printing system convention for file names, with all characters being alphanumeric and enclosed in single quotes. 2. Primary names must be enclosed in single quotes and have a limit of 32 alphanumeric characters. 3. Palette, screenset, pattern, color, and texture names must be enclosed in single quotes and have a limit of 32 alphanumeric characters plus the space character, with at least one character being alphanumeric. 4. Keywords cannot be used as names. 5. Palette names must be unique within an ink catalog, but may be reused in different catalogs. 6. Screenset, pattern, color, and texture names must be unique within a palette, but may be reused in different palettes. 7. Primary ID numbers must be unique. 8. Comments are allowed and must be enclosed with /* and */. Any item must be defined before it can be referenced in another statement. One possible ordering of statements which will avoid this problem is shown below: An .ISL (Ink Source Language) file is created using EDIT and contains the commands defined in section 3.2.9.1 Ink Source Language. The Ink Compiler will compile this file with the following command: ICO filename options, where filename is explained below: Filename specifies the 1 to 6 alphanumeric character name of an ink source language (ISL) file which is the input to the ink compiler. This filename may optionally include the file extension. (.ISL.), and where options may be any combination of the following, each being separated by a space: NOP[RINT] specifies that all source records and syntax or fatal errors are to be printed during compilation. If there are no syntax or fatal errors, there will be no print out. The default is to print all messages plus the source records. REP[LACE]specifies that the ink compiler may replace an existing ink catalog (.ICT) file with a new output file of the same name. This is the default. NOR[EPLACE] specifies that the ink compiler is not to create an ink catalog (.ICT) file if it has the same name as an existing file. REPLACE is the default. (NOTE: If both REPLACE and NOREPLACE are specified in the compilation command, then whichever was given last will be honored). TRA[Y] specifies that the listing and error messages from the ink compiler are to go to the sample tray. If TRAY is not specified, the printout will go to the output stacker. DIS[PLAY] specifies that all syntax error messages are to be displayed on the keyboard/display. The default is to print the syntax error messages only on the listing. The following new messages, which are shown here with a brief explanation, may be displayed to the operator by the ink compiler. Most of these messages are identical or similar to the PDL messages which are shown in the 4050 Reference Manual. All messages that exceed 80 characters will be truncated to 80 characters. Printed Error Message Summary The ink compiler is a two-pass compiler and syntax analysis occurs during the first pass. If a syntax error is found, then an error message will be immediately generated for the line in which the error occurred and analysis will resume on the next ink source language statement. The ink compiler tries its best to recover from errors found during the second pass. These error messages are generated for the entire ISL statement, with this being after the terminating semicolon is processed. SYNTAX ERROR ON LINE 〈line number〉. (A syntax error was detected.) SYNTAX ERROR: The number of patterns and inks are not equal. (In a TEXTURE statement, the number of patterns is not the same as the number of inks.) SYNTAX ERROR: Expecting 〈value〉 and not 〈value〉. (During syntax analysis, the ink compiler was expecting a certain value and it was not found.) SYNTAX ERROR: Keywords cannot be used as names. (Keywords cannot be used as names.) SYNTAX ERROR: Cannot use name 〈name〉 as specified. (Invalid name given.) SYNTAX ERROR: Invalid keyword 〈keyword〉. (Invalid keyword was detected.) SYNTAX ERROR: Invalid command. (Invalid command was detected.) LINE 〈line number〉: Pattern location does not exist. (The external pattern location which is either an ink catalog or palette, specified with the PLOC/PNAME commands is not defined.) LINE 〈line number〉: Pattern does not exist. (The pattern specified with the PNAME command is not defined.) LINE 〈line number〉: Names should be unique. (Ink names must be unique within a palette, but may be reused in different catalogs.) LINE 〈line number〉: 〈name〉 has not been previously defined. (The ordering of ISL statements is important. All items must be defined before they can be referenced.) LINE 〈line number〉: Data values do not match size specified. (This message is given when the ink compiler cannot create a bitmap with the data values given.) LINE 〈line number〉: Command is inconsistent with model. (In the COLOR statement, the number of values and primaries depend on the color model specified. In the SCREEN statement, the number of values, datagroups, and patterngroups depend on the color model specified.) LINE 〈line number〉: Ink catalog must contain at least one palette. (An ink catalog must contain at least one palette.) LINE 〈line number〉: Encountered a premature END or EOF (END command or EOF (end of file) encountered unexpectedly.) LINE 〈line number〉: Value 〈value〉 is incompatible with radix. (Data value given could not be used with the DTYPE specified;) LINE 〈line number〉: Bad value 〈value〉 given. (In the VALUE command, shade or mixture was not in the range of 0 to 100; or in PRIMARY command, the ID was not in the range of 0 to 255.) LINE 〈line number〉: All primary names must be defined first. (Primary commands must be defined at the beginning of an ISL file.) LINE 〈line number〉: ICATALOG command must precede PALETTE command. (A palette command must reside in an ink catalog boundary.) LINE 〈line number〉: END command is not balanced. (Too many END commands were encountered.) LINE 〈line number〉: Primary ID numbers must be unique. (The Ink Compiler will not accept similar primary ID's.) LINE 〈line number〉: 〈name〉 cannot be created. (Because of errors, a screen, color, texture, or pattern could not be created.) LINE 〈Line number〉: Ink does not exist. (There is no such ink defined.) LINE 〈line number〉: Size command is invalid. (The size command takes two values: n and m. n or m can be only 2,4, or 8.) LINE 〈line number〉: Command exceeds ink compiler's capability. (The TEXTURE command and the RGB color model exceed the ink compiler's capability. Also, any command other than SCNSET, SCREEN or PATTERN in the global area exceeds the ink compiler's capability. Stray commands (those commands which do not reside within a palette boundary or within the global area) exceed the ink compiler's capability.) LINE 〈line number〉: Maximum limit has been exceeded. (The maximum number of palettes (999), ink fonts (65534), or primaries (256) has been exceeded.) LINE 〈line number〉: WARNING! Screen approximation occurred. (The specified screen does not exist in the screenset, so the closest screen was used instead). The following is the system default ink catalog. The first four entries are examples of primaries (toners). The ID number identifies the commercial number of the ink, and the YES value is the industry standard definition of the color. The following is a portion of a typical catalog of colors. The screen value is the amount of each color half the time. Thus, SCREEN VALUES = (20,50) means that the first primary is applied at a 20% level for the first half of the screen ( = 10%) and the second primary is applied at a 50% level for the second half of the screen (25%). The DATA represent the bit map in hex. Thus for a 4 by 4 bit matrix, if DATA = 8,0,2 0, then the first line of the bit map is 1000, the second is 0000, the third is 0010, and the fourth is 0000. In the program the primary colors are identified as follows: The following are examples of colors that can be created from red and black primaries: The compiler will produce these files by the process shown as data flow diagrams on Figs 27 through 31. Fig 27 is a simplified diagram of the entire compiler. The OCS is the operating system that the operator works with. User commands entered at the terminal are sent to the compiler and the compiler generates formatted messages to be displayed at the terminal. The compiler works as an interpreter in that commands in the form of instructions and data are operated on by the compiler one at a time as they are entered. Any errors encountered in the input commands result in an error message which is sent from the Message file to the operator. The ISL file stores and transmits source records to the compiler which are used in conjunction with the commands to build an ink catalog. The ICOPRT.TMP file keeps a record of the process by storing source records and error messages. Fig 28 shows the process in more detail. The OCS is the operating system at which the operator types in user commands. At 1.0 these commands are verified and if any errors are encountered, the process is aborted and a code number corresponding to the associated error message is sent to the display message section 4.0 where the code number is translated into a text message and sent to the operating system for display. This message can also be sent to the print listing if the user needs a printed version. Commands are sent to the user option file, and the source record and error messages are stored in the ICOPRT.TMP file. The user options are taken in by the parse commands section 2.0 and are parsed into tokens. Then each token is acted upon in order. If the command is to access a previously entered file, it is taken from the ISL file, and if it is to access a previously entered command it is taken from the command properties file. Commands are entered into the command structure and data and entered into the new entry file. The new data are then acted upon in accordance with the new command by the execute command section 3.0 which results in a new symbol table and a new ink catalog. Fig 29 shows the parse command section 2.0 of Fig 28 in more detail. The contents of the ISL file is read into the read user file section 2.4 a block at a time, and is parsed into tokens which are sent, one at a time, to the lexical analyzer 2.1 and the analyze syntax section 2.2 for error checking. If this is the first pass, the process ends here. If this is the second pass, the program continues by storing new data in the new entry file, and new commands in the command properties file. The build command structure section 2.3 then uses the command properties to build a command structure. The build command structure 2.3 section of Fig 29 is shown in more detail in Fig 30. The command properties are distruibuted by type as shown, resulting in separate files for the building of catalogs, lists of primaries, palettes, etc, all of which are stored in the command structure file. Fig 31 shows that either the new entries are acted on by the commands in the command structure in the build options list section 3.1 to generate a symbol table, or that the symbol table entries are acted upon in the build ink catalog section 3.2 by the commands to create an ink catalog. Each element in the discussion of the data flow diagrams 27 through 31 is described in more detail as follows. Commands.D These are the JSL-like statements which are entered into a file using EDIT. The ink compiler parses these statements and then executes them accordingly. Prior to being parsed, these statements are written to a file called ICOPRT.TMP which is used to print the statements, plus any existing error messages, after the compilation process. Date Created: AUGUST 14, 1989 Last Modified: SEPTEMBER 28, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: Command Properties.DS This is a structure composed of the command type along with valuable information regarding the command type that needs to be passed to the routine build command structure. Date Created: NOVEMBER 14, 1989 Last Modified: NOVEMBER 14, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: cmdprp, Command Prop. Comments: Command Structure.D This is a structure composed of the command type along with valuable information regarding the command type that needs to be passed to the routine execute command. Date Created: AUGUST 14, 1989 Last Modified: AUGUST 14, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: [ICATALOG structure | PRIMARY structure | PALETTE structure | COLOR structure |COPTS structure | SCNSET structure | SCREEN structure | SOPTS structure | TEXTURE structure | PATTERN structure | END structure] Formatted Message.D A message from the message file that may be formatted with appropriate data to make the message more meaningful. Date Created: JANUARY 10, 1990 Last Modified: JANUARY 10, 1990 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: EX. A message from the message file may look like: ICXXXX Invalid keyword '%s'. but the formatted message may look like: ICXXXX Invalid keyword 'TEXTRUE'. ICOPRT.TMP.DS This is a file containing the source records fom the ISL File plus any messages. This file will be used to print the listing of the ISL file after compilation. Date Created: NOVEMBER 14, 1989 Last Modified: NOVEMBER 14, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: Ink Catalog.DS This is the end product of the ink compiler which is a file that contains all the information about the user defined palettes, colors, screens, patterns, and textures. Date Created: AUGUST 14, 1989 Last Modified: AUGUST 14, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: ISL File.DS This is the actual file which contains the ISL (JSL-like) statments. Date Created: AUGUST 14, 1989 Last Modified: JANUARY 10, 1990 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: ISL Filename.D This is name of the file which contains the ISL commands which is extracted from the user commands. Date Created: AUGUST 14, 1989 Last Modified: JANUARY 10, 1990 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: name of file which is a maximum of six alphanumeric characters + a period + ISL. Aliases: Comments: Message.D This is an informative sentence that is stored in the message file. It may contain symbols which mark places in the message that will be replaced when the message is formatted by display message. Date Created: AUGUST 14, 1989 Last Modified: JANUARY 10, 1990 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: EX. A message may look like: ICXXXX Invalid keyword '%s'. where %s is a symbol that will be replaced with the exact string. Message File.DS This is the file which contains all the messages that the Ink Compiler displays to the user. Date Created: AUGUST 14, 1989 Last Modified: AUGUST 14, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: Message Number.D This is a number which corresponds to a particular message within the message file. Date Created: AUGUST 14, 1989 Last Modified: AUGUST 14, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: New Entry.D This is a new entry into the symbol table. The new entry is kept in temporary storage until it is appropriate to insert it into the symbol table. Date Created: NOVEMBER 2, 1989 Last Modified: NOVEMBER 30, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: newent, newsym New Symbol.D This is a new symbol (name or identifier) to be inserted into the symbol table. Date Created: NOVEMBER 2, 1989 Last Modified: NOVEMBER 2, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: char newsym[LEXLEN] /* LEXLEN = 7 */ Aliases: newsym Comments: See New Entry. Options.D This is part of the User Command that tells the Ink Compiler what the user wants during the compilation process. The options that the user may specify in the user command are: NOPRINT, REPLACE, NOREPLACE, TRAY, DISPLAY Date Created: JANUARY 10, 1990 Last Modified: JANUARY 10, 1990 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: See also User Command. Source Records.D These are 80 byte records from the user editable ISL file that is specified in the ICO (compilation) command. Within these records are ISL commands, comments, and sequence numbers. Date Created: SEPTEMBER 28, 1989 Last Modified: SEPTEMBER 28, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: Source File.DS See ISL File. Date Created: SEPTEMBER 28, 1989 Last Modified: SEPTEMBER 28, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: Symbol Table.D Table of labels which is built during the first (?) pass of the ink compiler. Each entry in the symbol table contains a pointer to the label itself (in ASCII), the type of label it is, and its attributes which may be a pointer to an options list or some other one word attribute.There will be four markers into this table. One marker, called Istent, will mark the last position in the symbol table. Two other markers, called curcat and curpal, mark the beginning of the current icatalog and the current palette respectively. The fourth marker, called Istset, marks the last set (either palette, icatalog, or dfv1). When a new catalog or palette begins, all entries up to curcat or curpal are cleared, thus making available space in the symbol table. Date Created: SEPTEMBER 11, 1989 Last Modified: NOVEMBER 2, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: symtbl, lexems Token.D This is a sequence of characters having a collective meaning. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: TMCB.D Data that are transfered to OCS to spawn a print job. Date Created: SEPTEMBER 28, 1989 Last Modified: SEPTEMBER 28, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: User Command.D This is the command line that the user entered to initiate compilation. Date Created: JANUARY 10, 1990 Last Modified: JANUARY 10, 1990 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: ISL Filename + User Options Aliases: Comments: EX. A User Command looks like: ICO COMPILE JOANNE.ISL, TRAY where JOANNE.ISL is the ISL Filename, COMPILE and TRAY are User Options. User Options.DS Storage space holding flags which represent the options the user specified when the user command was entered. Date Created: JANUARY 10, 1990 Last Modified: JANUARY 10, 1990 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: Command Structure Definitions N OTYPE structure.D A fixed length structure. Date Created: NOVEMBER 14, 1989 Last Modified: NOVEMBER 14, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type + optional number of items] Aliases: ICATALOG structure.D A fixed length structure containing ICATALOG information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 1 + optional number of items + RAD50 filename] Aliases: PRIMARY structure.D A fixed length structure containing PRIMARY information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 2 + optional number of items + RAD50 filename + ID number] Aliases: PALETTE structure.D A fixed length structure containing PALETTE information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 3 + optional number of items + RAD50 filename] Aliases: COLOR structure.D A variable length structure containing COLOR information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 4 + optional number of items + RAD50 filename + length + COLOR Sub-Option(s)] Aliases: COLOR Sub-Option.D This is either a Value Sub-Option structure or any one of the COPTS Sub-Options structures. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: Model Sub-Option structure.D A fixed length structure containing information for the Model Sub-Option of the COLOR, COPTS, SCREEN, and SOPTS commands. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 4A + optional number of items + flagword] Aliases: Comments: flagword values: 1 = MONOCHROME 2 = TINT 3 = HSM 4 = RGB Scnset Sub-Option structure.D A fixed length structure containing information for the Scnset Sub-Option of the COLOR and COPTS commands. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 4B + optional number of items + RAD50 name] Aliases: Comments: The RAD50 name is zero if DEFAULT is selectedotherwise RAD50 name is the screensetname. Primary Sub-Option structure.D A variable length structure containing information for the Primary Sub-Option of the COLOR and COPTS commands. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 4C + optional number of items + length + RAD50 filename(s)] Aliases: Comments: The RAD50 name can be BLACK or any other primaryname. Values Sub-Option structure.D A variable length structure containing information for the Values Sub-Option of the COLOR command. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 4D + optional number of items + length + number(s)] Aliases: Comments: The RAD50 name can be BLACK or any other primaryname. COPTS structure.D A variable length structure containing COPTS information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 5 + optional number of items + length + COPTS Sub-Option(s)] Aliases: Comments: COPTS Sub-Option.D This is either a Primary Sub-Option structure, a Model Sub-Option structure, or a Scnset Sub-Option structure. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: SCNSET structure.D A fixed length structure containing SCNSET information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 6 + optional number of items + RAD50 filename] Aliases: Comments: SCREEN structure.D A variable length structure containing SCREEN information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 7 + optional number of items + length + SCREEN Sub-Option(s)] Aliases: Comments: SCREEN Sub-Option.D This is either a Values Sub-Option structure, a Data Sub-Option structure, a Pindex Sub-Option structure, or any one of the SOPTS Sub-Options. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: Data Sub-Option structure.D A variable length structure containing information for the Data Sub-Option of the SCREEN and PATTERN commands. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 7A + optional number of items + length + number(s)] Aliases: Comments: Size Sub-Option structure.D A fixed length structure containing information for the Size Sub-Option of the SCREEN, SOPTS, PATTERN, and POPTS commands. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 7B + optional number of items + number + number] Aliases: Comments: Dtype Sub-Option structure.D A fixed length structure containing information for the Dtype Sub-Option of the SCREEN, SOPTS, PATTERN, and POPTS commands. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 7C + optional number of items + flagword] Aliases: Comments: flagword values: 1 = BINARY 2 = OCTAL 3 = HEX 4 = DECIMAL Plib Sub-Option structure.D A fixed length structure containing information for the Plib Sub-Option of the SCREEN, SOPTS, PATTERN, and POPTS commands. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 7D + optional number of items + RAD50 filename] Aliases: Comments: Pindex Sub-Option structure.D A variable length structure containing information for the Pindex Sub-Option of the SCREEN and PATTERN commands. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 7A + optional number of items + length + index(es)] Aliases: Comments: SOPTS structure.D A variable length structure containing SOPTS information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 8 + optional number of items + length + SOPTS Sub-Option(s)] Aliases: Comments: SOPTS Sub-Option.D This is either the Model Sub-Option structure, the Dtype Sub-Option structure, the Size Sub-Option structure, or the Plib Sub-Option. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: TEXTURE structure.D A variable length structure containing TEXTURE information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 9 + optional number of items + RAD50 filename + length + TEXTURE Sub-Option(s)] Aliases: Comments: TEXTURE Sub-Option.D This is a Pattern Sub-Option structure or an Ink Sub-Option structure. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: Pattern Sub-Option structure.D A variable length structure containing information for the pattern Sub-option of the TEXTURE command. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 9A + optional number of items + length + RAD50 filename(s)] Aliases: Comments: The number of items in this structure must equal the number of items in the corresponding ink sub-option structure. Ink Sub-Option structure.D A variable length structure containing information for the Ink Sub-Option for the TEXTURE command. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 9B + optional number of items + length + RAD50 filename(s)] Aliases: Comments: The number of items in this structure must equal the number of items in the corresponding Pattern Sub-Option structure. PATTERN structure.D A variable length structure containing PATTERN information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 10 + optional number of items + RAD50 filename + length + PATTERN Sub-Option(s)] Aliases: Comments: PATTERN Sub-Option.D This any one of the POPTS Sub-Options structure, a Data Sub-Option structure, or a Pindex Sub-Option structure. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: POPTS structure.D A variable length structure containing PATTERN information. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 11 + optional number of items + length + POPTS Sub-Option(s)] Aliases: Comments: POPTS Sub-Option structure.D This is either a Dtype Sub-Option structure, Size Sub-Option structure, or Plib Sub-Option structure. Date Created: AUGUST 14, 1989 Last Modified: Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: Aliases: Comments: END structure.D A fixed length structure for the END command. Date Created: NOVEMBER 14, 1989 Last Modified: NOVEMBER 14, 1989 Status: { No walkthrough |Informal|Formal|Accepted Into Library} Composition: [type 12 + optional number of items] Aliases: Comments:

Claims: A process of printing fonts in a plurality of colors using any combination of two colorants on an output medium comprising the steps of: specifying two original bit maps of pixels by a plurality of numbers, each bit map having a bit pattern, each number specifying the bit pattern of a line of a bit map, the two bit maps having different pixel patterns, replicating each of the original bitmaps a plurality of times and combining the plurality of replicated bitmaps to form respective larger bit maps, generating a number of characters, each character comprising two larger bit maps of equal size and unequal pattern, grouping characters of various sizes into a font, and printing a document using said font, one larger bit map of each character being used to print in each color. A process as claimed in claim 1, wherein the printing is carried out by a tri-state xerographic printer which prints both colorants in one pass. A process as claimed in claim 1 or claim 2, wherein one of the colors is black.

Inventors: LAMAN ROBERT R, TAGAMI JOANNE M, LAMAN, ROBERT R., TAGAMI, JOANNE M.
Applicants: XEROX CORP, XEROX CORPORATION
Application year: 1992
Main classification: B41J2
IPC codes: G06K15