Problem printing from Clipper to a file

AlejandroSdeL commented 2 years ago

Code of Conduct & Contributing Guidelines

[X] I agree to follow the code of conduct and the contributing guidelines.

Have you checked that no other similar question(s) already exists?

[X] I have searched and didn't find any similar issues.

Question

Hi.

I would like writing to files the data that some old Clipper programs send to LPT1. The name of each file depends on the specific program. So I tried the CONFIG command to modify the parallel1 property. However, it did not work as expected. On the contrary, everything goes fine if I start DB-X with a configuration file having a modified parallel1 property. Details on my tests follow.

I wrote this very simple Clipper program prntest.prg that should print "Hello world."

SET DEVICE TO PRINTER
@ PROW(), PCOL() SAY "Hello world."
SET DEVICE TO SCREEN
RETURN

I also wrote this script dothis.bat:

config -get parallel1
prntest.exe
dir > lpt1
prntest.exe

I copied a standard configuration file as 1.conf and 2.conf, and modified the parallel1 property as follows: in 1.conf: parallel1 = printer in 2.conf: parallel1 = file file:prntest.spl timeout:1000 openwith:check.bat

All the above mentioned files are located in a folder c:\temp\prntest.

If I launch DB-X with the command \DOSBOX-X\dosbox-x.exe /conf 1.conf /c "CONFIG -set parallel1=file file:prntest.spl timeout:1000 openwith:check.bat" /c "mount c c:\ " /c "c:" /c "cd \temp\prntest" /c "dothis.bat" I obtain these results:

config -get correctly shows the above setting
first prntest.exe gives an error (printer not ready)
dir > lpt1 correctly generates the file prntest.spl
second prntest.exe sends its output to the screen

If I launch DB-X with 2.conf instead of 1.conf with the command \DOSBOX-X\dosbox-x.exe /conf 2.conf /c "mount c c:\ " /c "c:" /c "cd \temp\prntest" /c "dothis.bat" I obtain these results:

config -get correctly shows the setting in 2.conf
first prntest.exe correctly generates the file prntest.spl
dir > lpt1 correctly generates the file prntest.spl
second prntest.exe correctly generates the file prntest.spl

In summary, the CONFIG command is given strange results when combined with the Clipper program. Is this a bug in DB-X or am I doing something wrong? Thanks.

JoeC4281 commented 2 years ago

I do not have a solution for your problem, but I have issues with Clipper 5.3 myself.

My problems were caused by using the MSVC 64-bit compiled DosBox-X.exe

Switching to a MSVC 32-bit compiled DosBox-X.exe solved my problem.

Ref: https://github.com/joncampbell123/dosbox-x/issues/2401

This may not solve your printing problem, but you could try a different compiled version of DosBox-X.exe, there are several to choose from.

E:\DOSBox-X\dosbox-x.exe
E:\DOSBox-X\Win32_builds\ARM_Release\dosbox-x.exe
E:\DOSBox-X\Win32_builds\ARM_Release_SDL2\dosbox-x.exe
E:\DOSBox-X\Win32_builds\mingw\dosbox-x.exe
E:\DOSBox-X\Win32_builds\mingw-lowend\dosbox-x.exe
E:\DOSBox-X\Win32_builds\mingw-sdl2\dosbox-x.exe
E:\DOSBox-X\Win32_builds\mingw-sdldraw\dosbox-x.exe
E:\DOSBox-X\Win32_builds\x86_Release\dosbox-x.exe
E:\DOSBox-X\Win32_builds\x86_Release_SDL2\dosbox-x.exe
E:\DOSBox-X\Win64_builds\ARM64_Release\dosbox-x.exe
E:\DOSBox-X\Win64_builds\ARM64_Release_SDL2\dosbox-x.exe
E:\DOSBox-X\Win64_builds\mingw\dosbox-x.exe
E:\DOSBox-X\Win64_builds\mingw-lowend\dosbox-x.exe
E:\DOSBox-X\Win64_builds\mingw-sdl2\dosbox-x.exe
E:\DOSBox-X\Win64_builds\mingw-sdldraw\dosbox-x.exe
E:\DOSBox-X\Win64_builds\x64_Release\dosbox-x.exe
E:\DOSBox-X\Win64_builds\x64_Release_SDL2\dosbox-x.exe

Joe

rderooy commented 2 years ago

FYI. You don't need to do "-c config....", you can directly set a config setting from the terminal with "-set".

e.g.

dosbox-x -conf myconfig.conf -set "parallel1=file timeout=2000"

Also have a look at the printing guide on the wiki. There is a "[printer]" section where you can set many of the settings for the emulated Epson printer. One of the things that may be causing a problem is that on Windows hosts, the emulated printer will try to redirect to your actual printer, and this may possibly cause problems.

AlejandroSdeL commented 2 years ago

Hi.

@JoeC4281 I am doing my tests in Windows 32-bits, although the programs should finally run in 64-bits. I will grab a 64-bits machine and look what happens. I did not expect things work differently depending on the compiled version. Thanks.

@rderooy I do not want to print directly on a physical printer because I would like to do some special treatment on the output (eg, both print it and send it by mail). Besides, the problem seems not related with the parallel1 property itself, but with the way the property is set (configuration file vs. CONFIG command). I did no try with -set till now. Thanks.

EDIT: I tried with -set in the command line. It works fine, that is, the same way that when the parallel1 property is set in the configuration file. Strange behaviour occurs just if the CONFIG command is used.

rderooy commented 2 years ago

@AlejandroSdeL as I mentioned, by default when you set parallel1=printer, you tell it to use the emulated Epson dot-matrix printer. This emulated Epson printer is controlled by the settings in the [printer] section.

In addition, as mentioned, it will (on Windows) hosts, default to trying to print to your real printer. You may want to disable this as such:

[printer]
printer=true
printoutput=ps
multipage=true

https://dosbox-x.com/wiki/Guide%3ASetting-up-printing-in-DOSBox%E2%80%90X#_printer_section_options

AlejandroSdeL commented 2 years ago

@rderooy I have a working solution for 32-bits, without DB-X, that uses DOSprn for generating an xps file and a copy on paper. I would like to port it to 64-bits, by means of DB-X. I read the printing guide and I know that DB-X is able to print directly without using DOSprn. However, I tried without succeeding. At least the way I want it (by now, I do not remember exactly what failed). So now I am trying to use DB-X to capture the LPT1 port and keep DOSprn for generating the final output.

AlejandroSdeL commented 2 years ago

@JoeC4281 , @rderooy I repeated my three tests using the folowing Win64_builds:

mingw
mingw-sdl2
x64_Release
x64_Release_SDL2

In all cases the behaviour was the same as with the Windows 32-bits standard build. Now I think this is probably a kind of bug in DB-X, which might have certain problems changing the parallel1 property on the fly. Thus I will switch to the -set command line option, which allows me to provide a variable file name easily, without using the CONFIG command.

joncampbell123 / dosbox-x