|
Post by Jos on May 5, 2021 20:14:30 GMT 1
Again: Though what if you open that, or #LPT1.txt, in Notepad and print from there to the Generic driver?
You will be the only one with this problem, while DOS receipt printers and dBase programs are fairly common.
Eventually remove the RAW option, and select some Windows printer (not a virtual one). Not that useful since Epson control codes will be printed as text. But you'll at least be convinced printing does work. You could then for instance just copy that printer/driver, set the port to LPT1, and add the RAW option back in. Since RAW instructs vDos and the driver to pass on the output as-is to the printer, the driver doesn't actually matter. Only that it connects to the Epson printer.
Jos
|
|
|
Post by Jos on May 10, 2021 21:22:04 GMT 1
Probably too obvious, but one last thought: It’s not just Windows Print Spooler jammed on a previous failed print job, or offline for the Epson printer?
Jos
|
|
|
Post by wtc on May 10, 2021 21:29:22 GMT 1
Hello, I had the time to work on this project some more. I just printed from the text editor, xed, and I had the same slow one-line-at-a-time printing. While it was printing out, I brought up "Job attributes" and found that "document-format" indicated PDF. I presume that somewhere in Mint, the raw text is then being converted to PDF and then unconverted back to text. That might well be what's taking so much time for a simple receipt to print out. How can I convince Mint not to make a PDF in the first place? (I also see: "Status: Rendering completed".) Thank you.
|
|
|
Post by wtc on May 10, 2021 21:31:16 GMT 1
Hello, Jos, I received your message just as I had sent mine. I'll respond in a moment. I'm amazed (and thankful) that you have continued thinking about this. Sincerely, Wayne
|
|
|
Post by wtc on May 10, 2021 21:35:56 GMT 1
Now, I know, I'm a complete dodo. I forget these prior questions were on Windows. Now, I'm on my Mint computer. Geepers.
|
|
|
Post by wtc on May 10, 2021 21:39:44 GMT 1
But to answer your question. No, I even rebooted my computer and got the same results. I could double check, but I doubt that's the problem. Thank you.
|
|
|
Post by Jos on May 10, 2021 21:46:44 GMT 1
vDos is Windows-only. I stay away from Linux, not many vDos users in the Linux community.
You run vDos as provided by Edward Mendelson for Wine? Certainly any in-between conversion to PDF, will lose ASCII printer control codes at the end. Perhaps Edward can jump in and clarify what’s going on…
Jos
|
|
|
Post by wtc on May 10, 2021 21:52:58 GMT 1
But I did come up with an interesting hack on my Windows system. When I run vDos, I note that it automatically prints a small text file. I found a small small small spooler program called "PrintFile" (for Windows) that automatically prints the vDos print-to-file output and then erases it. Now (if you aren't done with my questions), is there a specific command in vDos that turns off print to file which might be overriding my attempts to print to lpt1?
|
|
|
Post by wtc on May 10, 2021 22:01:10 GMT 1
Thank you, Jos, for the offer to speak with Edward. I guess it's all a matter of CUPS taking a raw output and turning it to a PDF and then changing it back (since it's happening to any program's output that prints to lp0). If he were willing to comment, I'd listen.
|
|
|
Post by Jos on May 10, 2021 22:06:44 GMT 1
To your Windows system: Disable/remove the interfering "PrintFile" program. Although vDos printing should prioritize, there still will be that background monitoring “PrintFile” messing things up.
Eventually first add the PRIVATE option to LPTx=, so vDos won’t create the files “PrintFile” monitors.
Jos
|
|
|
Post by emendelson on May 10, 2021 22:38:06 GMT 1
My Wine version is Mac-only. It won't run on any variety of Linux. I have no idea how vDos can be running under Mint. I think we need to start over from the beginning and say exactly how vDos is running and where.
|
|
|
Post by Jos on May 10, 2021 23:20:30 GMT 1
I probably should have known that, but I’m Linux and Mac phobic.
Whatever it is or done, as a last resort you could try something like LPT1="LPT1": (mind the trailing colon).
In Windows perspective that’s foolish: You’ll bypass vDos (and Windows) printing awareness. Every byte sent to DOS LPT1 will be directly passed on to the host LPT1 device.
Jos
|
|
|
Post by harrya on May 10, 2021 23:28:32 GMT 1
I used the following in my config.txt file. I use the PCL driver on a Brothers laser jet, the share name is brotherpclro. This appears to work fine.
LPT1=SEL: "BROTHERPCLRO" RAW
|
|
|
Post by wtc on May 11, 2021 1:36:00 GMT 1
Hello All, and thank you, To the various responses, first, I will stick to discussion of the Windows machine. To Jos, are you suggesting that in the vDos config file I should put the line exactly as: LPT1=RAW ? Is that, also, to say that the print-to-file feature was keeping the data from the parallel port? (And of course I'll turn off PrintFile.) Then, if I understand, as a last resort, I can change that line (unless I can have two LPT1= lines in the vDos config file) to: LPT1="LPT1": (leaving in the ":") I can also try harrya's suggest of replacing LPT1="LPT1": with LPT1=SEL: "PARALLELPRINTERNAME" RAW Also, in the future, could I direct the LPT1 output to another printer as: LPT1=SEL: "USBPRINTERNAME" ? Am I wrong about what any of you meant by your suggestions? Again, thank you, Wayne
|
|
|
Post by emendelson on May 11, 2021 2:44:53 GMT 1
And now that I've read the actual posts, I see that you never said you were using vDos in Mint - you were using a Linux text editor in Mint and looking at its output. Next time I'll read more slowly.
|
|