T.R | Title | User | Personal Name | Date | Lines |
---|
3005.1 | is this for DOS-only? | NETCAD::ROLKE | The FDDI Genome Project | Mon May 05 1997 14:10 | 43 |
| 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.2 | Some more details ... | MIASYS::BONNEAU | Rich Bonneau Windows NT S/W Group 226-2453 | Wed May 07 1997 13:17 | 41 |
| 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.3 | just a thought... | ODIXIE::SIMPSONT | PC = world's biggest con job! | Wed May 07 1997 19:21 | 7 |
| 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.4 | Re: Exceeding line length (3005.3) | MIASYS::BONNEAU | Rich Bonneau Windows NT S/W Group 226-2453 | Thu May 08 1997 14:33 | 14 |
| 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.5 | Some more results ... | MIASYS::BONNEAU | Rich Bonneau Windows NT S/W Group 226-2453 | Mon May 12 1997 13:14 | 13 |
| 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
|