For Programmers: Free Programming Magazines  


Home > Archive > Cobol > August 2004 > windows printing using formprint problem...









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author windows printing using formprint problem...
chris bougeard

2004-08-03, 3:55 pm

hi, i am in the process of converting our cobol report programs that
were running on UNIX to run on windows 2000.

my first attempt at getting reports to work on windows was by using
microfocus net express and utilizing their various "pc_printer"
functions.

however, its near on impossible to get a consistent result due to the
potential variance in target printers/drivers so i discovered
formprint which sounded like what i needed, so i downloaded the
evaluation copy.

the fact that it deals with the windows print manager and allows you
to change settings etc on target printers is brilliant, and the method
of building a report "mask" then mapping it to the target report
through calls is great also.

but im having problems with what im trying to get it to do for me, and
im either being a complete idiot (quite possible) and missing the
obvious or im going to have to produce the reports the hard way, i
shall explain.

originally, we were printing 132 characters per line to line-printers
when in the unix environment, and that worked fine.

when i first tried to rebuild the cobol reports for windows using the
old
"select file assign to printer" everything went pear shaped!

hence ultimately going for the formprint option.

because we have a fair quantity of existing reports (all with their
own headings/titles etc etc) i dont really want to have to produce
lots of specific report "masks" then map the data through formprint
(although this is fine for future reports).

so, what i am trying to do is to run the old reports as usual, but at
the point when each 132 character print line WOULD have been written
to a printer, im passing it to a very basic mask in formprint (a
repeat group of 66 132character lines).

the problem is, that when formprint prints out this info, its losing
the column formats so for example if the following 3 lines were passed
to formprint

title author price
----- ------ -----
reports me 99.99

the resultant report produced by formprint is

title author price
----- ----- -----
reports me 99.99

ive tried lots of different combinations of fonts/formatting
and have also played with some of the qpr.cfg environment variables
(especially QPRFON) but to no avail...

ive wasted a LOT of time on this and am about to admit defeat and
start the painfull process of building specific masks for about 40
reports!!!
(as opposed to my initial idea of just dumping 132 character print
lines into a basic mask that all the reports could use).

any help/advice would be greatly appreciated!!

all the best everyone,

chris
Donald Tees

2004-08-03, 8:55 pm

chris bougeard wrote:
> hi, i am in the process of converting our cobol report programs that
> were running on UNIX to run on windows 2000.
>
> my first attempt at getting reports to work on windows was by using
> microfocus net express and utilizing their various "pc_printer"
> functions.
>
> however, its near on impossible to get a consistent result due to the
> potential variance in target printers/drivers so i discovered
> formprint which sounded like what i needed, so i downloaded the
> evaluation copy.
>
> the fact that it deals with the windows print manager and allows you
> to change settings etc on target printers is brilliant, and the method
> of building a report "mask" then mapping it to the target report
> through calls is great also.
>
> but im having problems with what im trying to get it to do for me, and
> im either being a complete idiot (quite possible) and missing the
> obvious or im going to have to produce the reports the hard way, i
> shall explain.
>
> originally, we were printing 132 characters per line to line-printers
> when in the unix environment, and that worked fine.
>
> when i first tried to rebuild the cobol reports for windows using the
> old
> "select file assign to printer" everything went pear shaped!
>
> hence ultimately going for the formprint option.
>
> because we have a fair quantity of existing reports (all with their
> own headings/titles etc etc) i dont really want to have to produce
> lots of specific report "masks" then map the data through formprint
> (although this is fine for future reports).
>
> so, what i am trying to do is to run the old reports as usual, but at
> the point when each 132 character print line WOULD have been written
> to a printer, im passing it to a very basic mask in formprint (a
> repeat group of 66 132character lines).
>
> the problem is, that when formprint prints out this info, its losing
> the column formats so for example if the following 3 lines were passed
> to formprint
>
> title author price
> ----- ------ -----
> reports me 99.99
>
> the resultant report produced by formprint is
>
> title author price
> ----- ----- -----
> reports me 99.99
>
> ive tried lots of different combinations of fonts/formatting
> and have also played with some of the qpr.cfg environment variables
> (especially QPRFON) but to no avail...
>
> ive wasted a LOT of time on this and am about to admit defeat and
> start the painfull process of building specific masks for about 40
> reports!!!
> (as opposed to my initial idea of just dumping 132 character print
> lines into a basic mask that all the reports could use).
>
> any help/advice would be greatly appreciated!!
>
> all the best everyone,
>
> chris


It looks to me like a fixed/proportionhal font issue. What font are you
currently using?

Donald

Robert Wagner

2004-08-03, 8:55 pm

sihingchris@hotmail.com (chris bougeard) wrote:


>the problem is, that when formprint prints out this info, its losing
>the column formats so for example if the following 3 lines were passed
>to formprint
>
>title author price
>----- ------ -----
>reports me 99.99
>
>the resultant report produced by formprint is
>
>title author price
>----- ----- -----
>reports me 99.99


Use a monospaced font such as Courier.
James J. Gavan

2004-08-03, 8:55 pm

chris bougeard wrote:

>hi, i am in the process of converting our cobol report programs that
>were running on UNIX to run on windows 2000.
>
>my first attempt at getting reports to work on windows was by using
>microfocus net express and utilizing their various "pc_printer"
>functions.
>
>however, its near on impossible to get a consistent result due to the
>potential variance in target printers/drivers so i discovered
>formprint which sounded like what i needed, so i downloaded the
>evaluation copy.
>
>
>

First off - don't give up too quickly on PC_PRINT - remember it's a
'freebie' as part of the N/E package. It's a fairly basic tool,
(although sophisticated enough), so may not suit all your needs. If you
haven't done so already, I would suggest you go to the M/F site and
sign-up (freebie) for Answer Exchange. You can ask specifics.

If you go to Answer Exchange - Net Express, doing a search on my name
or topic 'Report Writer and PC_PRINT' you'll get info from Jean
Villemaire , (M/F in Quebec). He suggests a solution to getting at
different printers - one of which is using EnumPrinters API - if like
me you are 'lost' on APIs - could always ask "Pretty please explain the
API'.

On the API side you could go to Young Kim's site (uses N/E) and see if
he has anything about Printer APIs in one of his API chapters - site :-

http://www.kimsoft.com/api-cobol/oo-cobol.htm

Now don't shudder, but the original reason for my question was I like
the concept of Report Writer, (the way it generates the print fields,
i.e. a 'mask of print lines'; M/F Screen Section follows a similar
pattern),. The raw R/W is as useful as teats on a bull when you talk
Unix/Windows. So my question was "Can you 'merge' R/W with PC_PRINT ?".
Jean supplied a possible solution which I haven't tried yet. (It's not
high priority).

If interested I can send you the source of a Procedural written by Young
Kim that makes calls to PC_PRINT.

Another possibility aligned to OO. Doesn't yet have all the PC_PRINT
routines as of N/E V 4.0 - but I have a class Printfile which includes
all the (a) variables (b) calls to PC_PRINT and (c) Print status error
messages, contained within the class - so using print masks in your
Business program (Procedural or OO) you can invoke methods in the
Printfile class. Nothing to stop you turning my Print class into a
'Procedural' and use entry-points instead of method-names.

Strangely enough I've been mulling over improvements to the PrintFile
class, (I wrote it about three years ago) - one of which is passing a
'header mask' as a BLOCK from Business Procedural to the Print class.
I'm guessing you are not into OO - don't worry - I would provide the
basic code for you to play with if you should stay with PC_PRINT.

As examples :-

Report A - 6 header lines (including blanks, fonts, styles etc.)
Report B - 9 header lines......
Report C - 13 header lines .........

In the Business Program you build /once only/ an Ordered Collection
containing 6, 9 or 13 lines as appropriate, with parameters up-front per
line indicating font, blank line, style, expand, condense etc. This
collection is passed as an object reference to the Print Class to the
method "printHeader'- a very *rough* outline :-

*>------------------------------
Method-id. "printHeader".
*>------------------------------
01 n pic x(4) comp-5.
01 NumberOfLines pic x(4) comp-5.
01 ls-LineRecord
05 Field1 pic x(4) comp-5.
05 Field2
05 Field3 etc....
05 PrintableText pic x(187). *> I use
this for print condensed in landscape

Linkage section.
01 lnk-Header object reference. *> a
collection/list of your header lines

Procedure Division using lnk-Header.

invoke lnk-Header "size" returning ls-numberOfLines

*> I could use a callback to iterate through the above collection but
I'll do it with a PERFORM

perform varying n from 1 by 1 until n > ls-NumberOfLines
invoke link-Header "at" using n returning ls-lineRecord

Evaluate true *> (assume Field 1 in the Line Record)
when BlankLine
invoke self "printBlankLine"
when ChangeFont
invoke self "changeFont" using xxxxxx
when etc.....

End-evaluate
End-perform

End Method "printHeader".
*>--------------------------

Very rough sketch - but hopefully you get the idea.

If you are not into OO then some explanation is required. There is only
ONE copy of Class PrintFile in memory with all the methods. Assume
three reports at different locations :-

Each of your Business Programs
WORKING-STORAGE SECTION.
01 os-PrintFile object reference.

Business Program l -

(a) invoke PrintFile "new" returning os-PrintFile - you have created an
INSTANCE (object reference) to the Class PrintFile
(b) now you would pass the parameters for printer-id/location, plus
subsequently the HeaderBlock I referred to above.

The info in (b) is held separately for each Instance. The remainder of
the class program ( the methods) is *common* to all Instances.

Business Programs 2 and 3 - same as above and the os-Printfile object
reference is *unique* to each.

>so i discovered formprint which sounded like what i needed, so i downloaded the
>evaluation copy.
>
>
>

I take it you are referring to Flexus FormPrint ? No dispute there,
accolades here show it has a good track record.

>the fact that it deals with the windows print manager and allows you
>to change settings etc on target printers is brilliant, and the method
>of building a report "mask" then mapping it to the target report
>through calls is great also.
>
>but im having problems with what im trying to get it to do for me, and
>im either being a complete idiot (quite possible) and missing the
>obvious or im going to have to produce the reports the hard way, i
>shall explain.
>
>originally, we were printing 132 characters per line to line-printers
>when in the unix environment, and that worked fine.
>
>when i first tried to rebuild the cobol reports for windows using the
>old
>"select file assign to printer" everything went pear shaped!
>
>


I'm surprised you even got to a pear shape :-) . Outside of Windows
calls or specific tools, printing is a stinker.

>hence ultimately going for the formprint option.
>because we have a fair quantity of existing reports (all with their
>own headings/titles etc etc) i dont really want to have to produce
>lots of specific report "masks" then map the data through formprint
>(although this is fine for future reports).
>
>so, what i am trying to do is to run the old reports as usual, but at
>the point when each 132 character print line WOULD have been written
>to a printer, im passing it to a very basic mask in formprint (a
>repeat group of 66 132character lines).
>
>the problem is, that when formprint prints out this info, its losing
>the column formats so for example if the following 3 lines were passed
>to formprint
>
>title author price
>----- ------ -----
>reports me 99.99
>
>the resultant report produced by formprint is
>
>title author price
>----- ----- -----
>reports me 99.99
>
>
>

Don't know FormPrint but if I was doing above with PC_PRINT, I would
call the Underline feature. For ease I just do one underline for the
whole length of the print record. You could get fancy 'underline this,
switch off underline, move some spaces, now underline this etc.- but a
bit of a pain in the ass !

>ive tried lots of different combinations of fonts/formatting
>and have also played with some of the qpr.cfg environment variables
>(especially QPRFON) but to no avail...
>
>ive wasted a LOT of time on this and am about to admit defeat and
>start the painfull process of building specific masks for about 40
>reports!!!
>(as opposed to my initial idea of just dumping 132 character print
>lines into a basic mask that all the reports could use).
>
>any help/advice would be greatly appreciated!!
>
>all the best everyone,
>
>chris
>
>

I don't think any of the tools below is a problem for the printing -
it's initially satisfying yourself that you can satisfactorily access a
variety of printers at different locations.

So PC_PRINT, FormPrint and then there's Crystal Reports and a fairly new
kid on the block - go googling on RPV - they have a free copy, and for
additional whistles and bells, a purchased ($$$) copy. From a cursory
look at RPV seems you send print parameters to RPV which has its own
file format which looks very similar to the XML technique.

Probably enough food for thought above that you can frame some specific
questions to throw at Answer Exchange about using PC_PRINT. However, use
of one of the other tools above might possibly be less painful.

Jimmy, Calgary AB
Richard

2004-08-03, 8:55 pm

sihingchris@hotmail.com (chris bougeard) wrote

> the resultant report produced by formprint is
>
> title author price
> ----- ----- -----
> reports me 99.99


You need to specify a _fixed_pitch_ font (such as courier). Using a
variable pitch font will result in no column alignment.
chris bougeard

2004-08-05, 3:55 pm

hi,

thanks very much for all the replies!

as regards the pitch (fixed/variable) the example i used to illustrate
the problem was based on courier fixed...

HOWEVER, if i used the "default font" fixed which you can set up in
formprint,
the columns are restored BUT the spacing now causes my report to be
too big for the form...

the ideal would be then to change the font size to a smaller set of
points but the default font cant be changed AND any other font type
(fixed) that i create then change the point size still gives me my
original problem doh!!!!

help!!!!!

chris
Michael Mattias

2004-08-05, 3:55 pm

"chris bougeard" <sihingchris@hotmail.com> wrote in message
news:3b88001e.0408050540.84e93a8@posting.google.com...
>
>
> as regards the pitch (fixed/variable) the example i used to illustrate
> the problem was based on courier fixed...
>
> HOWEVER, if i used the "default font" fixed which you can set up in
> formprint, the columns are restored BUT the spacing now causes my report

to be
> too big for the form...
>
> the ideal would be then to change the font size to a smaller set of
> points but the default font cant be changed AND any other font type
> (fixed) that i create then change the point size still gives me my
> original problem doh!!!!


You know, you can create a font to use which is based on Courier New
(monospaced) except you specify narrower characters.

See the CreateFont and/or CreateFontIndirect API calls... although you seem
to indicate your current printing method does not permit definition of a
run-time-created font...

....so let's see what's behind Door Number Two...

I use a third-party library "ddoc Print and Preview" (all of twenty-five
bucks for a license), which makes doing this kind of thing a snap. ddoc p&p
is supplied as a "pure" windows DLL file, so you could use it with COBOL
programs. You'd have to understand how to convert the header files from
"BASIC or C" syntax to "COBOL syntax".. and make sure you form your
parameters correctly and use the correct calling convention (stdcall) and
linkage convention.. but no reason you could not create a little "default"
module which would 'hide' all the messy details from your COBOL programs...
after all, from what you've said here, if you can get to some kind of
"common" 132-column output it would service all your print requirements...
and no reason this could not be set up so all you'd need in your COBOL
program would be

CALL "PrintMyFile" USING File-name, printer-name [ and whatever other
print-time-options you might deem useful]


(Yes, I could; on a professional basis. And you pay nothing unless it works.
And you own the source code.)

Contact my office if interested in pursuing this.

--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmattias@talsystems.com




Michael Mattias

2004-08-12, 8:55 am

"chris bougeard" <sihingchris@hotmail.com> wrote in message
news:3b88001e.0408050540.84e93a8@posting.google.com...
>
>
> as regards the pitch (fixed/variable) the example i used to illustrate
> the problem was based on courier fixed...
>
> HOWEVER, if i used the "default font" fixed which you can set up in
> formprint, the columns are restored BUT the spacing now causes my report

to be
> too big for the form...
>
> the ideal would be then to change the font size to a smaller set of
> points but the default font cant be changed AND any other font type
> (fixed) that i create then change the point size still gives me my
> original problem doh!!!!


You know, you can create a font to use which is based on Courier New
(monospaced) except you specify narrower characters.

See the CreateFont and/or CreateFontIndirect API calls... although you seem
to indicate your current printing method does not permit definition of a
run-time-created font...

....so let's see what's behind Door Number Two...

I use a third-party library "ddoc Print and Preview" (all of twenty-five
bucks for a license), which makes doing this kind of thing a snap. ddoc p&p
is supplied as a "pure" windows DLL file, so you could use it with COBOL
programs. You'd have to understand how to convert the header files from
"BASIC or C" syntax to "COBOL syntax".. and make sure you form your
parameters correctly and use the correct calling convention (stdcall) and
linkage convention.. but no reason you could not create a little "default"
module which would 'hide' all the messy details from your COBOL programs...
after all, from what you've said here, if you can get to some kind of
"common" 132-column output it would service all your print requirements...
and no reason this could not be set up so all you'd need in your COBOL
program would be

CALL "PrintMyFile" USING File-name, printer-name [ and whatever other
print-time-options you might deem useful]


(Yes, I could; on a professional basis. And you pay nothing unless it works.
And you own the source code.)

Contact my office if interested in pursuing this.

--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmattias@talsystems.com




Thane Hubbell

2004-08-12, 8:55 am

Try "Lucida Console" or "Courier New". Often the resident font of the
printer will get in the way. Using the stock fixed pitch font is not
recommended as it will not scale (intentionally). Any of the
monospace True Type Fonts should work.

Flexus has a white paper avaialble on it's FTP site, or I will be
happy to email said paper to you if you send me an email at
techsupport at Flexus.com. It goes into detail about this very issue
especially as it relates to various font sizes, printable areas, and
printer resolution.

The most recent version of Form Print (and those released for about
the last year) includes specific options to ensure that the print
looks the same across various versions of windows, with various fonts
and with various printer resolutions.

sihingchris@hotmail.com (chris bougeard) wrote in message news:<3b88001e.0408050540.84e93a8@posting.google.com>...
> hi,
>
> thanks very much for all the replies!
>
> as regards the pitch (fixed/variable) the example i used to illustrate
> the problem was based on courier fixed...
>
> HOWEVER, if i used the "default font" fixed which you can set up in
> formprint,
> the columns are restored BUT the spacing now causes my report to be
> too big for the form...
>
> the ideal would be then to change the font size to a smaller set of
> points but the default font cant be changed AND any other font type
> (fixed) that i create then change the point size still gives me my
> original problem doh!!!!
>
> help!!!!!
>
> chris

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com