README.protocol 6.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168
  1. This file is an explanation of what I've figured out about control codes
  2. for StyleWriter printers. If you just want to use the driver, you
  3. don't need to read any further -- this is here purely to satisfy
  4. curiosity about how the driver works (or fails to work, as the
  5. case may be).
  6. If you have specific questions you would like to see answered here in
  7. future versions, send them to monroe@pobox.com.
  8. All StyleWriters use a serial interface. They have a standard RS422
  9. DIN8 plug, which is electrically compatible with RS232 given the
  10. right plug adapter. At power-on, they default to communicating at
  11. 57600 baud, and later models can be put into a mode where they
  12. externally clock the serial port at a rate close to 1 megabit.
  13. The communication protocol with the printer uses _no_ flow control
  14. in the traditional sense. There is no hardware handshaking and
  15. no XON/XOFF flow control. The driver must be aware of the size of
  16. the printer's buffer, and not send too much data at one time. One
  17. of the codes the driver can send causes the printer to return a
  18. byte which seems to indicate how full its buffer is. The driver
  19. could potentially use this information to keep feeding data as
  20. quickly as possible, but it currently just waits for the buffer to
  21. drain completely before sending more data.
  22. This protocol is the main reason that the driver is a standalone
  23. program, and not simply a driver module in ghostscript. When I
  24. started work on the driver, I looked into making a gs driver module,
  25. but the architecture didn't seem to support two-way communication
  26. with the printer. It's possible that later versions of ghostscript
  27. have removed this limitation, but I haven't looked at it lately.
  28. StyleWriters are rather unforgiving to experimentation. Sending
  29. a control code that the printer doesn't understand or a buffer of
  30. image data that has been encoded incorrectly causes the printer to
  31. eject the page and reset itself.
  32. Sending the question mark character '?' causes the printer to return
  33. a string identifying which model it is. The string is terminated
  34. with a carriage return (character 0x0D).
  35. All other control codes seem to be of one of two types. One type
  36. consists of four characters; three 0xFF bytes followed by a one-byte
  37. code. The other type consists of one- or two-byte codes that are
  38. not preceeded by 0xFF bytes. The first type causes the printer to
  39. send back one byte of data, usually some sort of error code or
  40. configuration information. The second type causes no reply. I
  41. speculate that the first type could be sent in the middle of a
  42. block of image data -- because of the data encoding used, there
  43. should never be three 0xFF bytes in a row in the image data.
  44. All of the definitions of control codes given here were arrived at
  45. by deduction or simple trial and error. This should not be taken
  46. as definitive information. If you find errors or omissions in this
  47. list, or figure out anything interesting that belongs here, please
  48. send your information to monroe@pobox.com.
  49. Known ident strings:
  50. "IJ10\r" = StyleWriter I
  51. "SW\r" = StyleWriter II
  52. "SW3\r" = StyleWriter 1200
  53. "CS\r" = Color Stylewriter 1500, 2200, 2400 or 2500
  54. Type 1 codes (prefix these with "\xFF\xFF\xFF"):
  55. "I" - Ejects the page and resets the printer.
  56. "1" - Returns something about the status of the printer.
  57. "2" - Returns error status of the printer. The return value may actually
  58. consist of bitfields. Known return values:
  59. 0x00 -- nothing wrong
  60. 0x80 -- nothing wrong (possibly "bad command?)
  61. 0x04 -- printer is out of paper
  62. "B" - Returns the status of the printer's buffer. The meaning of the
  63. return value is different on different printer models. On the 2400,
  64. 0xF8 means the buffer is empty, and lower values indicate more data
  65. in the buffer. On the 2500, 0x80 means the buffer is empty, and lower
  66. values indicate more data in the buffer. I don't know what values
  67. indicate a completely full buffer on either model.
  68. "p" - Distinguishes between the printers that return 'CS'. Known return
  69. values:
  70. 0x01 -- StyleWriter 2400
  71. 0x02 -- StyleWriter 2200
  72. 0x04 -- StyleWriter 1500
  73. 0x05 -- StyleWriter 2500
  74. Honorable mention goes to the person who finds a printer with 0x03 as
  75. its 'p' code.
  76. "S" - Tells the printer to try again after it has reported being out of
  77. paper. This code is only known to work on the 2400/2500.
  78. "H" - Tells something about the configuration of the printer. The return
  79. value may actually consist of bitfields. Known return values:
  80. 0x01 -- Black ink cartridge installed (in 2400/2500)
  81. 0x81 -- Color ink cartridge installed (in 2400/2500)
  82. "R" - Not sure, but it seems to have something to do with turning on
  83. high-quality printing on the 2400/2500.
  84. Type 2 codes (sent by themselves):
  85. "?" - Tells the printer to return its ID string.
  86. "\x0C" - Marks the end of the data for a page.
  87. "nuA" - Start a new page on a StyleWriter I.
  88. "L" - Start a new page on all other StyleWriters.
  89. The following were gleaned from the MacOS printer drivers, and are used while
  90. setting up the printer. I don't know exactly what some of them do.
  91. "D" - I don't remember.
  92. "N" - I don't remember.
  93. "m0nZAH" - Sets up for normal-quality printing.
  94. "m0sAB" - Sets up for high-quality printing.
  95. Image Data
  96. ----------
  97. Bitmap data for the printer to print is sent in encoded blocks.
  98. Each block consists of a rectangle in printer coordinates, the
  99. two-byte length of the data, and the encoded scanlines in top-to-bottom
  100. order. Printer coordinates have (0,0) at the top left of the
  101. _printable_ area of the page. This means that the top and left
  102. margins must be dealt with by the driver. Very similar formats
  103. are used for monochrome and color data.
  104. The overall format of a data block is as follows:
  105. 'R' for monochrome or 'c' for color
  106. <LSB of rect.left>
  107. <MSB of rect.left>
  108. <LSB of rect.top>
  109. <MSB of rect.top>
  110. <LSB of rect.right>
  111. <MSB of rect.right>
  112. <LSB of rect.bottom>
  113. <MSB of rect.bottom>
  114. 'G'
  115. <LSB of size>
  116. <MSB of size>
  117. <'size' bytes of encoded data>
  118. '\0'
  119. Bitmap data is encoded using a modified RLE scheme with differencing
  120. from previous lines. The differencing algorithm is reset for each
  121. new block of data that is sent. For color data, the bitmap for
  122. each plane (C,M,Y,K) is encoded separately and the encoded data
  123. for the planes in each scanline is interleaved in CMYK order.
  124. The encoding scheme is best described by the code in the function
  125. encodescanline(). The code was written while figuring out the
  126. encoding scheme by trial-and-error. During the course of this it
  127. was redesigned and rewritten several times, and it's not pretty,
  128. but it works.