Has anyone had success with embedding fonts into the basic heading
statement.
Here's my dilemna. If I put the font esc sequence into the first line of
the heading I lose my right justification or centering. I avoid that if
I drop down a line but then for some reason I'm losing the heading on
the other pages. If I send the font before the heading I get a blank
page. I'm trying to decide whether I need to change a bunch of reports
by doing the heading myself or if I can find a way to send a font
command to the printer without a blank page printing or a adding a blank
line in the heading.

This is the way I have accomplished this...

In BASIC programs I've embedded the printer control codes as the very first
thing in the HEADING statement.

In AQL reports I created a routine that return the printer control codes I
need based o. In the dictionary of the file I created an item that passes
some parameters into the subroutine using an F-correlative. Then, in the
heading clause of the AQL statement enter the following: HEADING "'Adict.id'
and the rest of the heading stuff".

I've only working with setting the lines per inch and characters per inch,
but it seems to work well.

hth,

Dale


"bob" <bgf66 (AT) comcast (DOT) net> wrote

It's only basic reports that I'm concerned with here.
When I put the control codes in the first line of the header, it messes
up the 'J' and 'C' codes b/c it doesn't know that those are unprintable
characters.
I guess one solution would be to stop relying on those chars and do the
justify and center myself.
What would be ideal is if I could send a command to the printer and have
the basic heading statment somehow ignore or forget about it.
Then I could set my font for the print job and go on with it knowing
that the default font for the report is right. Problem is when I send
the codes and then issue the heading statement, it sees that the print
job is not empty and issues a form feed.




Dale Benedict wrote:

It's only basic reports that I'm concerned with here.
When I put the control codes in the first line of the header, it messes
up the 'J' and 'C' codes b/c it doesn't know that those are unprintable
characters.
I guess one solution would be to stop relying on those chars and do the
justify and center myself.
What would be ideal is if I could send a command to the printer and have
the basic heading statment somehow ignore or forget about it.
Then I could set my font for the print job and go on with it knowing
that the default font for the report is right. Problem is when I send
the codes and then issue the heading statement, it sees that the print
job is not empty and issues a form feed.




Dale Benedict wrote:

Bob,

I simply add a 'L' after the printer control codes in the heading. Sure that
lowers the page by one line, but at least all the left and center justified
fields display in the correct locations.

Jeff

"bob" <bgf66 (AT) comcast (DOT) net> wrote

You could try this:

Pick a "devices" item to assign to that printer
ASSIGNFQ fq,devices.id
SP-ASSIGN FQ

then edit the devices file and look for the @(-nn) definitions. They are
easy to see and usually go at least to @(-101). Just add D,< until you get
to -126. that's the default header font. Put your font string in there in
the format:

C'stringdata'|X'hexbytes' {, repeat as needed {...}} <

So an esc]39m might look like

x'1b',c']39m'<

Remember the < because it terminates the data otherwise it'll slop over into
whatever comes next.

Then when you print, that form queue is associated with that device and it
will go there looking to see what 126 means.

Mark Brown

"bob" <bgf66 (AT) comcast (DOT) net> wrote

Bob:

The simplest solution I've found is to preface the report with the PCL
codes. If you want to customize the output __IN__ the heading I'm not sure
if the @(-n) functions work with the ASSIGNFQ function.

If you're just interested in PCL codes to set the overall font, orientation,
and whatever, then you can:

SP-OPEN
Write the PCL codes
Do your report
SP-CLOSE

Now the problem, as you've mentioned, is the pesky initial form feed. The
solution is required for HP printers as they specifically execute a form
feed, which always exists in a D3 report prefaced by PCL codes. Other
printers ignore the PCL codes and ignore the form feed because nothing is in
the print buffer.

I was able to solve this problem by turning off all form feeds between
pages. The reason this works for me is I've always used standard "footers"
with all our reports. With these footers, I've simply included the form
feed at the end of the footer; which creates the form feed between pages and
not ahead of the initial heading.

If you want more information just let us know.

Bill

"bob" <bgf66 (AT) comcast (DOT) net> wrote

I have found inconsistent operations of the char(27):"E" reset function in
PCL5 and PCL6 printers.

Some do a reset only.
Some do a reset and a form feed.
Some do a reset only unless the reset command is not the very first command,
then they do a form feed also.

Perhaps this will help.
Jeff




"Bill H" <notme (AT) bogus (DOT) com> wrote