[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::ibmpc-95

Title:IBM PCs, clones, DOS, etc.
Notice:Intro in 1-11, Windows stuff in NOTED::MSWINDOWS please
Moderator:TARKIN::LINND
Created:Mon Jan 02 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3023
Total number of notes:28404

3005.0. "Sending escape sequences to HP Laser Jet (4P)" by MIASYS::BONNEAU (Rich Bonneau Windows NT S/W Group 226-2453) Mon May 05 1997 12:32

I have a small application which prints to a printer and I have
included support to send PCK escape characters to the printer to
do lines/page, VMI, compressed, bold, etc.  I am seeing the
following situation:

	Try to adjust lines/page (66) and VMI (7) by sending
	directly to the printer - not seen

	If I direct the output to a file and then copy the
	file to the printer, it works!

The only thing I can consider is a timing problem - there can
be a significant time between sending the initial escape sequence 
and issuing further print lines, when going direct to the printer.
In the file mode, this is obviously not the case.

Any suggestions, contacts, etc?

Many thanks,
Rich BOnneau
Systems Application Integration Engineering
ZKO 1-3
DTN 881-2126
T.RTitleUserPersonal
Name
DateLines
3005.1is this for DOS-only?NETCAD::ROLKEThe FDDI Genome ProjectMon May 05 1997 14:1043
Hi Rich,

First off, sending escape sequences to printers is possible.
Obviously some friendly entity is getting in your way and clobbering
the stream that you send.

  Have you been able to get ANY escape sequence to work?  
    Getting the first to work is a big step.

  What's your environment?
    NT & VC++5.0?
    DOS 4 & TurboPascal?
    MASM from a DOS Box in WIN3.1?
      Each of these has its own set of problems...

I have found that Windows95 and WindowsNT reset my printer between print
jobs while Win3.11 did not.  By "between print jobs" I mean either

  1. Open a DOS box - Copy a file - Close the DOS box
    <-- printer is reset, page formatting is lost ---
  2. Open a DOS box - Copy a file - Close the DOS box

OR

  1. Open a channel to LPT1 - do some output - Close the channel
    <-- printer is reset, page formatting is lost ---
  2. Open a channel to LPT1 - do some output - Close the channel

You may try disabling your print spooler so that it doesn't reset the
printer behind your back.

You may try PCMagazine's PRN2FILE which redirects PRN: output to a file.
Then you can examine the file to make sure that nobody has inserted
nulls, expanded your tabs to spaces, swallowed the escapes or other
evil things.  (This sounds like an unlikely problem if your file-copy
prints okay.)

In the end I've learned to make do with printing to files and then
copying the files to LPT1: from a DOS box. (Except in VC++ where the
printing services of WinNT are the way to go.)

HTH,
Chuck
3005.2Some more details ...MIASYS::BONNEAURich Bonneau Windows NT S/W Group 226-2453Wed May 07 1997 13:1741
In response to .1 here are some more details about my problem

This is a Turbo Pascal V6 program which runs under DOS, although
the testing discussed earlier was all done in a Windows 95 DOS
window.

The program uses the write(lst, ...) and writeln(lst,...) I/O
functions to output lines to the printer.

I have used write(lst, ...) to output escape codes for the printer
reset and initialization strings.
  
	Perhaps I should use writeln to guarantee transmission immediately?

In any case, in the intialization of the overall program, the type of 
printer is determined and the appropriate initialization string is sent
to the lst device using only write(lst, ...)

At a later point in the program, if the user ever decides to print anything,
at that point, additional escape characters might be send (to do bolding
or underlining, or compressed font) etc. as well as the actual text to
be printed - most of all of this is done with writeln(lst, ...) calls.

The behavior is that the init string stuff (setting lines per page and
space between lines (VMI)) don't appear to get to the printer, but all the
remaining stuff, including formatting esc characters, do seem to get there.

All well and good.  My program also has the capability of issuing all of its
output commands to a file (actually redirect lst device to a disk file)
even while keeping all the intended control strings going there.

If I do this, then I can see all the characters in the output file and 
when I copy that file to the laser jet printer - it prints correctly!!

So the issue is why doesn't it work when the output goes directly to the
printer and not to the file.

If any one can help, please!

Thanks,
Rich Bonneau
3005.3just a thought...ODIXIE::SIMPSONTPC = world&#039;s biggest con job!Wed May 07 1997 19:217
    What is the maximum string length and are you exceeding it?  It used to
    be 256 characters...I think...  In which case changing to writeln
    should fix it.  I think that is what is, in effect, happening when you
    output to a file then send the file.
    
    Rgds,
    Tom
3005.4Re: Exceeding line length (3005.3)MIASYS::BONNEAURich Bonneau Windows NT S/W Group 226-2453Thu May 08 1997 14:3314
Thanks, but I don't think that is the problem.  My longest lines of text are
around 132 columnse, with possibly a bit more for bolding on/off characters.
And even if that were the problem, wouldn't I just miss the end of the line
and not the beginning where the esc characters are located?

In any case, I am seriously considering modifying my program to ALWAYS write
the output to a file and then do a DOS command to PRINT or COPY the file
to the printer.  This does take away what had been a handy feature to allow
the user to interrupt and cancel printer output, but ...

Thanks for the help and if anyone else has any additional info about this
printing issue, please, please send it along!

Rich
3005.5Some more results ...MIASYS::BONNEAURich Bonneau Windows NT S/W Group 226-2453Mon May 12 1997 13:1413
Did a bit of experimenting this weekend and found that I can get the right
behavior if I send the characters out to the printer as if it were simply
a 'file of char' in Turbo Pascal.  So the program has now been modified
to use all the standard text output and output to a file, then I
re-open the file and the prn device both as 'file of char' and do
a simple read-char, write-char until eof found.  And this seems to work
fine!  Apparently opening the print device as 'file of char' allows
the program to output anything to it including esc chars and control
chars, and these simply get passed to the print device as is.

(Wish I could avoid the 'spooling' aspects but this will do for now.)
Thanks for all help given,
Rich