Print form border shifted

[mike]

Hi, we are printing forms with border that consists of "|" symbols. 

On Win7 it's a straight vertical line but on Win10 through vDos we get vertical "|" symbols misaligned by 1 space.

****************
|
 |
|
****************

Can you help please?

Thanks and Regards,

Mike
  

 

[Jos]

Can you post a LPT1.asc file with such a form?

Jos

[mike]

Here it is - thanks!

Attachments:

LPT2.asc (2.76 KB)

[Jos]

Mostly DOS program use spaces to align stuff, your program however uses absolute or relative position codes. Somehow those are miscalculated by vDos, I will have a closer look, can be caused by several things.

For now you could:
Add the RAW option to the LPT2 = directive in config.txt, so parsing the printer data will be done by the printer.
Or download vDosPCLPS.zip at www.columbia.edu/~em36/ghostpcl.html. That will then create a PDF file, eventually to be printed directly.

Jos

[mike]

Hi Jos, thank you very much! We are looking to roll out win10 in a couple of weeks so if you can take a look and make a fix it would be great. We are working on the process to procure the license in the meantime.
I also will try the first fix. The second one is not an option for us i'm afraid cause the users won't be printing pdf's manually - they just want to push the button and be done...

Thanks again,
Mike

[mike]

Hey Jos, RAW option worked just fine for us. We are checking if all our printers are PCL/Postscript to support the RAW option.
Thanks and Regards,

Mike

[Jos]

Don’t know if this is of much interest anymore:

I had a closer look at the formula that parses the PCL <esc>*pnnnX command, and calculates the next print position.
Major problem: nnn is given in printer dots. With vDos you can set margins (default 15mm left and 10mm right), eventually margins set by a program are ignored. So the hardcopy can scaled and positioned. That nnn value should then also be scaled and moved.

Tricky part is that nnn was once determined for printing at 12 cpi, and supposed to position to the start of a character. If the margins in vDos don’t match those once used, it takes more than just subtracting margins, calculate a new page width, some divisions and multiplications. Characters are printed at integer dot positions, not for instance at 948.45. Some correction would have to be made to the calculated next print position. Though that depends on the CPI (can even vary in a line), while it’s unclear the program even wants the next print position to match the start of a character.

Will keep it in mind, but could be there’s no real (general) solution.
Except of course one of your own: Set the printer margins in config.txt to somewhat they were supposed to be once. I suppose you have letter size paper, and added:

lpt1 = HORZ: 7,0,80 VERT: 1,2,65

That produced vDosMarg.pdf. As a reference lpt1.pdf, produced by PSPCL6 (should closely match your hardcopy).

Jos

Attachments:

vDosMarg.pdf (12.91 KB)

LPT1.pdf (37.63 KB)

[mike]

Hi Jos, I see the issue and really appreciate such quick response (and expertise) - thank you very much!
So far the testing is going on with the RAW option. Now we have one more fix in case some station has an incompatible printer.

Thanks again,

Mike

[Jos]

You could use/try "lpt2 = HORZ: 7,0,80 VERT: 1,2,65"?
If you prefer double lines, set a monospaced font like Courier.
The hardcopies should then be consistent, no matter what printer is used. With the option to print to PDF.

Jos

[mike]

Hi Jos, thank you very much! We will try it next week.
Thanks and Regards,
Mike