× 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.



Paul,

Thanks for the help. That finally did it. It turns out the printer was
already going to the maximum by default. So the real issue was the hard
limit of 83. I move the numbers 1 character to the left and the document
prints fine now. I tried some of the customization objects in the IBM
download but that made things go real strange. Interesting exercise!

Thanks again

Konrad

"Paul Tykodi" <ptykodi@xxxxxxxxx> wrote in
message news:108265.44217.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Konrad,

I wish that HPT offered an option to scale to fit the printable area, as
part of its AFP to PCL transform, but so far it doesn't. The other thing to
realize is that you need to convince HPT that the virtual page it is
rendering before sending the PCL codes to the printer can actually accept
all of the characters you want to print. HPT has a limitation of not
supporting more than 80 characters per line when printing on Letter sized
paper in portrait orientation with a 10 CPI font. I have therefore placed
the link to an IBM Knowledgebase article covering how to work around this
limitation and print edge to edge below for your reference.

Further information about reducing the no print border and printing edge to
edge with Lexmark engine based printers can be found here:
http://www-912.ibm.com/s_dir/slkbase.NSF/acf2ee1e9d64b16e8625680b00020389/8e05e4e177326b158625728a00632adb?OpenDocument

Best Regards,

/Paul
-- Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile: 603-866-0712
E-mail: ptykodi@xxxxxxxxx
WWW: http://www.tykodi.com

date: Thu, 19 Feb 2009 10:15:40 -0500
from: "Konrad Underkofler"
subject: Re: Simple Printing Question



Paul,

Thanks for the assistance. I have already tried a bit of your solution.
Using
the WSCST info database from IBM I have removed the right margin and moved
the
whole image 1/6 of an inch to the left, more than the width of the missing
character.

Sad to say it still does not print even though the printer itself can
print in
that area. It does look better aligned on the page.

When I use BCDs Spool File Explorer and capture the file as a tiff and say
print
to fit a page it does print. Is there anyway to get HPT to do this?

I have also tried a variety of models on the printer and changed to the
LEXOPTRAT at the suggestion of the online help to get rid of the COR tags.

The printer by the way is a Dell rebrand of a Lexmark laser. However the
behavior is consistent across all lasers we have. It also has an overlay
but
with the overlay the results are the same.

Thanks again,

Konrad

"Paul Tykodi" wrote in message
news:<875502.94006.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx>...
Hi Konrad,

In general most HP LaserJet printers have an unprintable margin along all
four
sides of cut sheet forms. It is usually a value between 0.10 and 0.20
inches on
most reasonably new HP LaserJet printers when printing with PCL. The
manufacturer type and model choices for HP LaserJet printers will have an
unprintable margin value included in the Workstation Customization Object.
It is
definitely possible to make your own WSCST and zero out the unprintable
margin
values so that any truncation will be the result of the printer executing
the
function and not host print transform.

If you are printing on Letter sized paper at 10 characters per inch,
position 84
is too close to the edge of the paper to be printed. In order to print the
minus
characters, you would most likely need to perform two specific steps in
creating
a customized WSCST.

1. Zero out the unprintable margin values to create an edge to edge
supporting
WSCST.

2. Add a new font entry in the WSCST you are creating, which maintains the
height and typeface of the current 10 CPI font being selected but is
actually
spaced at 11 CPI.

You would then direct your application to call for the new font definition
you
added (by FGID) as necessary.

Because your are using *AFPDS, the WSCST font definition process is a
little
more involved. If you were printing *SCS, you could just change the HMI
setting
and your problem would be resolved. With *AFPDS there is a lot of
individual
character positioning included in the resulting PCL so I believe you need
to add
a comprehensive table describing the character metrics of the new 11 CPI
font
you are defining within the WSCST you are building.

Feel free to contact me off list if you have further questions about
creating
WSCST's to meet your application requirements.

Best Regards,

/Paul
--Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile: 603-866-0712
E-mail:
ptykodi-/E1597aS9LQAvxtiuMwx3w@xxxxxxxxxxxxxxxx
WWW: http://www.tykodi.com



date: Tue, 17 Feb 2009 14:44:23 -0500
from: "news.midrange.com"
subject: Simple Printing Question

Somewhere lost in the layers of host print transform and its interaction
with our iSeries is some strange behavior.

We have a print file defined in dds as 85 wide type *AFPDS that has
two -
(minus) characters on two separate lines in column 84.

When printed to a variety of printers mostly laser jet emulations it
prints
fine except for dropping the -. With and overlay or without an overlay
it
looks the same.

I have changed the width from 80 to 100 both on the printer file and in
an
override and it looks altered on the iSeries but prints exactly the same
on
the printer. Somehow has HPT seen the lack of data and dropped the -
from
the last position? What is real strange is truncating the line through a
printer override still prints the report with the data but minus the
minus.

Any suggestions?

Thanks!

Konrad





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.