× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Before we throw HPT under the bus, do a google search for 'default margins laser printers' and you will find it is a very non-standard world. Many printers from HP not same, and now the Universal Driver is something else..

You might try testing the ovrprtf margin settings, so you are setting the margin on each print,
and make sure COR not on.. set rotation to 0 (zero). Test this on diff printers.

Jim Franz

----- Original Message ----- From: "rick baird" <rick.baird@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, January 17, 2012 10:04 AM
Subject: Re: overlays and laser printer shifting issues


that's an interesting idea, but but we don't know what the client has
named their devices. the output could go to a general outq and then
be moved to the printer of their choice.

we have company option flags we can set to determine these things -
the customer can set to what they want it to be after testing to see
where it belongs.

thanks again,


On Tue, Jan 17, 2012 at 9:59 AM, James Horn <jdhorn@xxxxxxxxxxxxxx> wrote:
We have used the old technique of printing a device description and finding
the TYPE or WSCST and returning that to the program.
If both exist it returns the WSCST. We test that to determine overlay
placement.

Jim

/*------------------------------------------------------------------*/

/* retrieve the TYPE/WSCST OF a printer
*/


PGM PARM(&PRT &TYPE
&WSCST)


DCL VAR(&prt ) TYPE(*CHAR)
LEN(10)
DCL VAR(&TYPE ) TYPE(*CHAR)
LEN(10)
DCL VAR(&WSCST ) TYPE(*CHAR)
LEN(10)
DCL VAR(&JOBNAME) TYPE(*CHAR)
LEN(10)
DCL VAR(&USER) TYPE(*CHAR)
LEN(10)
DCL VAR(&NUMBER) TYPE(*CHAR)
LEN(6)
DCL VAR(&text ) TYPE(*CHAR)
LEN(15)




DCLF
FILE(QTEMP/TEST)


MONMSG
MSGID(CPF0000)


RTVJOBA JOB(&JOBNAME) USER(&USER)
NBR(&NUMBER)



DLTSPLF FILE(Qpdcdev )
JOB(&NUMBER/&USER/&JOBNAME)


OVRPRTF FILE(QPDCDEV)
HOLD(*YES)
DSPDEVD DEVD(&prt)
OUTPUT(*PRINT)


CRTPF FILE(QTEMP/TEST)
RCDLEN(132)


CPYSPLF FILE(Qpdcdev ) TOFILE(QTEMP/test)
+

JOB(&NUMBER/&USER/&JOBNAME)
STARTLOOP:
RCVF
MONMSG MSGID(CPF0864) EXEC(GOTO
CMDLBL(ENDloop))


IF COND(%sst(&Test 41 4) *EQ 'TYPE')
THEN(DO)
CHGVAR VAR(&type ) VALUE(%SST(&test 53
10))
GOTO
CMDLBL(STARTLoop)

enddo


IF COND(%sst(&Test 41 5) *EQ 'WSCST')
THEN(DO)

CHGVAR VAR(&type ) VALUE(%SST(&test 53 10))
GOTO CMDLBL(STARTloop)
enddo

GOTO CMDLBL(STARTLOOP)

ENDloop: DLTSPLF FILE(Qpdcdev ) JOB(&NUMBER/&USER/&JOBNAME)

ENDPGM
------------------------------

message: 3
date: Mon, 16 Jan 2012 16:31:36 -0600
from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
subject: Re: overlays and laser printer shifting issues

hi Rick,

On 1/16/2012 4:12 PM, rick baird wrote:
In the last 2 or 3 years, we've had an ongoing problem with overlay
and/or laser output shifting out of alignment at some of our client
sites.


Yes, in my experience, overlays printed through Host Print Transform
tend to print in different positions, depending on the particular
MFRTYPMDL specified.

In one of my programs, I have worked around it as follows...

The DDS for the PRTF has this:

A OVERLAY(MYLIB/INVOICE -
A &PROVLDWN &PROVLACS)

(Mine is done via DDS, though you could do the same thing via parameters
on CRTPRTF, CHGPRTF or OVRPRTF if you prefer.)

Then my RPG code does this:

prOvlDwn = 0;
prOvlAcs = 0.25;

if (wkDev = 'PRT06');
prOvlDwn = 0.167;
endif;

So, for some devices, the "down" position is 0, and others it's 0.167.
This makes it line up in both cases. Sadly, I have it hard-coding the
device names of the devices that need a different offset (there's
probably a better way, but I haven't found it yet.)

My suggestion to you, therefore, is to make this "down" position
configurable. Ask your customer to do a test print, and if it's not
lined up, then change the down position and try again. If your overlay
position is specified via CRTPRTF like this:

CRTPRTF FILE(myfile) FRONTOVL(myoverlay 0 0)

Then your instructions to the customer might be as simple as saying "if
the overlay doesn't line up, then type this command:
CHGPRTF FILE(myfile) FRONTOVL(myoverlay 0.167 0)"

If you find a better solution, please let me know... because this is a
frustration of mine.

-SK

--
Jim Horn
CATCO 651-697-6314 JDHorn@xxxxxxxxxxxxxx
Cell 612-791-3924
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.