home *** CD-ROM | disk | FTP | other *** search
/ Oakland CPM Archive / oakcpm.iso / cpm / sysutl / tools.lbr / LIST.DZC / LIST.DOC
Encoding:
Text File  |  1987-08-07  |  2.3 KB  |  49 lines
  1. LIST
  2.  
  3. LIST is a file print program.  It sends a file or series of files
  4. to  the  LST device.  A left border of 4 spaces  is  provided.    A
  5. header with page count is given at the top of each page,  and the
  6. program does not print over perfs. Usage is
  7.  
  8.      LIST <filename> <filename> ... <filename>
  9.  
  10. Wildcards ARE supported. Tabs in the source are handled properly.
  11.  
  12. Of all the programs I have written, I am least proud of this one.
  13. It works fine most of the time,  which is why I tolerate it.  The
  14. problem is that is is much too rigid:  the left border setting is
  15. compiled into the program, and the width is set for 8" paper. The
  16. tab setting commands are specific to Epson/Gemini control  codes.
  17. If  any of your needs are different than this,    you will have  to
  18. recompile the program ... I'm including the BDS C source.
  19.  
  20. Worse,    the program doesn't respond well to lines too long to fit
  21. on the page.  Long lines are sent on to the printer as is,  which
  22. means that the printer will do with them whatever it is set up to
  23. do.  Depending upon dipswitch settings, most printers will either
  24. return    to column one and continue from there,    or do CRLF to the
  25. next line. If the latter, the line count will get bollixed up.
  26.  
  27. There are a number of things that can be done to improve  things.
  28. First,    I should probably expand tabs into spaces,  to accomodate
  29. plain  vanilla    printers.  I  could  also set  page  width  as    a
  30. variable.
  31.  
  32. The problem with the line length is more difficult.  The  obvious
  33. thing  to  do is to truncate all lines that are longer    than  the
  34. available  space,  but that seems a bit brutal.  Short    of  that,
  35. there  are only two options:  split the line onto two lines (with
  36. proper line count),  or use a compressed print pitch.  I  thought
  37. about  switching  the  pitch  dynamically,  from  line    to  line,
  38. depending upon the line length. But that would produce a printout
  39. too  bizarre for words.  And the idea of pre-scanning the  entire
  40. document, to find out how long the lines are, offends my sense of
  41. efficiency.  If  anyone has a sugggestion how best to handle this
  42. one, I'd appreciate it. Even better, how about just rewriting the
  43. program for me!
  44.  
  45. Jack W. Crenshaw
  46. P.O. Box 15888
  47. Tampa, Fla. 33684
  48. CIS 72325,1327
  49.