12.11.2012 Views

ijpds formats.book - Kodak

ijpds formats.book - Kodak

ijpds formats.book - Kodak

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 4. Record Formats<br />

Character Definition Record (CDR)<br />

Character Definition Record (CDR)<br />

CDR records follow the FDR record and define each character in the font.<br />

The CDRs contain the bitmap patterns for the characters. Up to 256<br />

characters can be defined for each FDR. Usually, there is one CDR for<br />

each character. However, in some fonts, a continuation CDR is used to<br />

divide a character bitmap into two or more records if it is necessary to limit<br />

the size of the records (because of block length restrictions or other<br />

reasons). The character bitmap can be broken only at the end of a row.<br />

When continuation CDRs are used, all fields up to the bitmap pattern field<br />

must be the same in each CDR for the character except for the<br />

continuation bit in the last CDR.<br />

Note: As an option, a single CDR may immediately follow an SFD to define the<br />

default character for any undefined character in the super font.<br />

When an FDR is received, the printer defines null and default characters<br />

in the following manner. When an FDR is first processed by the printer, all<br />

256 characters in the font are set as null characters. If the first CDR<br />

received has a hex 00 in the Character Identifier field, then the character<br />

in this record is used as the default character for character identifiers hex<br />

01 through FF (character 00 remains a null character). Subsequent CDRs<br />

then redefine the characters for their respective character identifiers.<br />

Character 00 can be redefined from the null character in this manner. If<br />

the first CDR does not have a hex 00 in the Character Identifier field, then<br />

all characters remain null until redefined by subsequent CDRs.<br />

A null character has zero width, and takes no space when printed.<br />

Note: An example of FDR and CDR coding is shown in Appendix B.<br />

Byte Position Bytes Field Name Description<br />

1-2 2 Record Length The length of this record, in binary, including the record length<br />

field. For example, hex 00 8C specifies a record length of 140<br />

bytes.<br />

3 1 Cyclic Record Count A binary cyclic record count using modulo 256. Each record in the<br />

job is counted, starting with hex 01 for the first record. The 255th<br />

record is hex FF and the 256th record is hex 00. This count is used<br />

to verify record sequence.<br />

4 1 Control Code A binary code that identifies the record type. A value of hex 14<br />

identifies the CDR record.<br />

5 1 Character Identifier A binary code that identifies the character defined in this record.<br />

This is the code that must be used in the input data to access this<br />

character for printing. The range is 0 - 255.<br />

6 1 Equivalent Character<br />

Identifier<br />

A binary code that identifies a character in the font that has a<br />

bitmap pattern identical to this character. If 2 characters are the<br />

same, it is not necessary to repeat the bitmap pattern. The<br />

“Equivalent” bit in byte position 8 must be set for this field to be in<br />

effect.<br />

If the equivalent bit is set, the character defined in this field is part<br />

of the font currently being defined unless another font is identified<br />

in byte 9 or in bytes 9 and 10. If byte 9 identifies a regular font,<br />

then byte 10 (if present) is ignored. If byte 9 identifies a super font,<br />

then byte 10 must be present and identifies the subfont. In any<br />

case, the character must have been previously loaded in the same<br />

RIP.<br />

Reference Guide 4 - 23

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!