vDos and printing to LPT1

[wtc]

Hello,

I'm noticing when I print something in vDos to my generic Epson receipt printer, each line is shifted 4 spaces to the left, and positions 37-40 are printed at the extreme left like this:

    012345678901234567890123456789012345

6789

    012345678901234567890123456789012345
6789

I've used the simple dos command "dir > lpt1" and the same thing happened.

If I print to the same printer from MS Notepad, the printout is correct, meaning:

0123456789012345678901234567890123456789

0123456789012345678901234567890123456789

This suggests to me that vDos is adding a margin to the output. If not, perhaps the driver is adding a 4 space margin; is that possible? I don't see any such parameter where I would find it on a more sophisticated printer.

Does anyone have any idea(s)?

Thank you.

[Jos]

Left would be right.

If you use the RAW option, the output of your program is send as-is (ASCII data stream) to the printer.

Without RAW, the output is interpreted by vDos and formatted as GDI pages. Adding a left margin, defaulting to 10mm.

You'll have to use RAW, or set the left margin with HORZ:.

Jos

[wtc]

Hi Jos,

And thank you for getting back so quickly.

On the "Print Processor" tab, "Default data type" is set to RAW, and "Print processor" is set to "winprint."

Assuming this is what you were suggesting, I'm supposing I have to set the left margin with " HORZ: " which I'm not familiar with. Would you mind getting me up to speed on that?

Thank you for your time,

Wayne

[Jos]

Add this line to config.txt:
LPT1 = SEL:"Windows_name_of_the_Epson_printer" RAW

Or:
LPT1 = SEL:"Windows_name_of_the_Epson_printer" HORZ:0

Because of the low resolution of the printer, the first line (with RAW) would be best.

LPT1=, RAW, HORZ: and other printing options are documented in the Printing.pdf document.

Jos

[wtc]

Worked.

Thank you, Jos. I just added your suggestion to make:

LPT1=SEL:"Generic-Text-Only" TIO:1 HORZ:0

and that printed very nicely.

Thank you, again,

Wayne

[Jos]

The "Generic-Text-Only" driver doesn’t support formatting.

Not using RAW, the ASCII output of your program is converted by vDos to GDI pages. That includes for instance font selection and text positioning. Those are then filtered out by the "Generic-Text-Only" driver to isolate the plain text again. The ASCII text is also converted to Unicode, and back to ASCII again. This conversion back to plain ASCII text can lead to unexpected side effects, like characters being added or dropped.

So use RAW instead of HORZ:0. The actual printer driver doesn’t matter, as long it is connecting the Epson printer.

If not already tried, TIO:0 could get the printer to respond quicker.

Jos

[wtc]

Hello, yet again, Jos,

And I have second question, related to another printing question I asked you some time ago: Is there a way, now, to add a carriage return to a line feed automatically, or do I still have to embed escape key codes each time my program calls the printer? I hope you don't mind answering another question.

In any case, thank you for your time,

Wayne

[Jos]

Don’t know the specifics of your previous carriage return/line feed question.

A carriage return instructs the “printhead” to return to the first position on the same line. A line feed to advance the printhead one line downwards.
A single carriage return or line feed is mostly translated to the pair, by software or hardware.

Jos

[wtc]

Thank you, Jos.

Now, there's another strange thing happening. I've installed vDos for the first time on a 64 bit machine (32 bit machines are just too old now (though they work)) and for the first time I'm not using a parallel port but a usb to parallel cable. Here is what's weird. I print out a receipt as a simulated sale and everything is fine. When I attempt to print out a second receipt, the screen "hangs"--it doesn't update--BUT if I hit the key stroke to print out, the receipt prints, so the program hasn't hung. After the second receipt starts to print out, and I hit a key, everything goes back to normal--everything's fine. A third receipt "hangs" like the second. Etc.. Do you have an idea? This program has work reliably on vDos on the 32 bit machines with 100% reliability for a long while. Any thoughts?

Thank you for reading this,

Sincerely,

Wayne

[Jos]

I even read that several times and am still clueless.

It doesn’t matter running on 32- or 64 bit Windows, neither using a parallel port or USB adapter. If the program would inquire whether the printer is online/ready, it just always is.
Perhaps it is some timing issue, the program running too fast now?

Jos

[wtc]

Hello, Jos,

I tried to attach a short video of what I was trying to describe. If the account I'm about to give is still not clear, is there a way for me to send you a 35 second vid of 80mb?

Let me try again. When I go through the key strokes to print out an output of my dBase application on vDos multiple times, the monitor stops displaying the white letters on the black screen. (The monitor is a reasonably new Dell flat screen VGA.) The first time I print out will be fine. If I follow what I know to be the correct keystrokes a second time, the printer prints out correctly, but I can't see the current menu. After the printout completes, and I hit any key, the screen refreshes and I can see the letters again. For example, I know that the screen says

"Print out? y/n"

but all I will see on the screen is the

"y"

that I just entered. The rest of the screen is black. The printer prints. When I hit another key I see the next correct menu in its entirely. The program and the code are the same as I have used on the 32 bit machine for years. Is there any explanation you can think of that would cause vDos not to display on a monitor only when printing?

I hope I've made myself understood this time.

In any case, thank you for reading this,

Wayne C.

[Jos]

The maximum size of an attachment is 10MB, that’s why you couldn’t upload the video. Though not that interesting to have a look at.

You could select the text area where “Print out? y/n” should be by Ctrl+Win+Left mouse click. Then paste the content in for instance Notepad to check there’s actually no text, or black on black background.

If you still have the 32-bit (or a copy of that) installation, what if you copy that over to the 64-bit machine. Eventually temporary add/change LPT1=DUMMY for testing.

Jos

[wtc]

Hello, Jos,

Here attached are two images, the first at the point of printing out a receipt by hitting "y" for the first time after starting vDos/dBase, and the second photo is the same moment of printing a receipt a second time. Up until hitting the "y" the first time everything is normal. Actually the "y" you see in the first photo mysteriously requires a carriage return before the application continues, which is not the case on the 32 bit machine. As I mentioned before, the program reacts normally, but I can't have employees guessing what to do next. I wrote this POS system 30 years ago, and it has worked perfectly every since, and it does exactly what I need it to do for my business, so I'd like to keep using it running on more modern machines.

Do you have any ideas?

Thank you, yet again, for your time,

Wayne C.

Attachments:

[Jos]

I guess you also installed (not copied) dBase on 64-bit Windows. Verify all dBase settings are like before. There’s no reason why dBase/vDos would function differently.

Jos

[wtc]

Hi Jos,

I only copied vDos and dBase. Is there a way to install either of them?

I suspect there is a conflict in each of my 64 bit computers between the printer drivers and the screen drivers. You might well disagree. You know a great deal more than I do. I just have an hypothesis.

Sincerely,

Wayne C.