f



Postscript

Hello,

I have been trying to find a library to make the production os
postscript file easier from our cobol programs. 

Finally, I have begun to write a library in OO cobol largely inspired
from the C pslib library. I have just finished to prepare the
interface of the different methods and write a few methods.

Teh generation of postscript file could then be:
invoke PSDoc "PSOpenFile" using z"myfile.ps"
invoke PSDoc "PSMoveTo" using x, y
invoke PSDoc "PSLineTo" using ...
invoke PSDoc "PSCircle" using ....
etc...
which is - to me at least! - easier to read than the postscript
statements.

I thought that it might be an interesting project for an open source
library in cobol. There are too few projects for the most used
programming language in the world.

This is just an mail to see if anyone would be interested before
placing it on the web.

Regards.

Alain


0
Alain
11/8/2004 3:32:51 PM
comp.lang.cobol 4278 articles. 1 followers. Post Follow

4 Replies
940 Views

Similar Articles

[PageSpeed] 6

Alain Reymond wrote:

>Hello,
>
>I have been trying to find a library to make the production os
>postscript file easier from our cobol programs. 
>
>Finally, I have begun to write a library in OO cobol largely inspired
>from the C pslib library. I have just finished to prepare the
>interface of the different methods and write a few methods.
>
>Teh generation of postscript file could then be:
>invoke PSDoc "PSOpenFile" using z"myfile.ps"
>invoke PSDoc "PSMoveTo" using x, y
>invoke PSDoc "PSLineTo" using ...
>invoke PSDoc "PSCircle" using ....
>etc...
>which is - to me at least! - easier to read than the postscript
>statements.
>
>I thought that it might be an interesting project for an open source
>library in cobol. There are too few projects for the most used
>programming language in the world.
>
>This is just an mail to see if anyone would be interested before
>placing it on the web.
>
>  
>
Alain,

Firstly I don't know the first thing about Postscript - but as to your 
objective 'Open Source' - RIGHT ON !

At the current time the market is Fujitsu and Micro Focus users - you, 
from memory, are using the latter - anyway there's a give-away in your 
above code  -

using z"myfile.ps"	:-)

So if your intent is BOTH F/J and M/F users then your code needs to be as NEUTRAL as possible. I suspect both compilers are poles apart if you start talking dotNet. As an example, DEFINITELY an EXTENSION - M/F usage of dotNet has the following for Exception Handling, (and I'm quoting from Will Price's book on M/F and dotNet) :-

TRY	set ls-user-name to ls-CircleDataObject::"UserName"::"Trim"
CATCH	ls-ExceptionObject
	invoke MsgBoxClass "Show" using
		"NameMissing" & "Substituting 'Anonymous'"
		"Missing Entry"
	move "Anonymous" to ls-user-name
END-TRY

Just look at how different usage of MessageBox is from GUI classes.

How I "hate" those double sets of colons ! Can't tell you how the above works as I don't have N/E V 4.0 - but as you can see, currently for Open Source the above is for the birds. (Plus the word 'FACTORY' becomes 'STATIC' !!!!).

To be neutral the code would have to include REPOSITORY, (instead of CLASS-CONTROL) - which is where F/J is already at, but is only 'official' in M/F in V 4.0. Given you were coding in N/E V 3.1 then you could use the appropriate $set directive to include the REPOSITORY Section - although other than compiling it doesn't add anything to an N/E V 3.1. application, but would be applicable to one compiled with N/E V 4.0. (For the latter I expect you would have to drop the $set directive).

At this juncture any Open Source code would need to ignore vendor support utilities, like the collection classes in N/E which are in no way compatible with F/J. (To be realistic, we are likely talking at least 2006 before J4 publishes a COBOL set of collection classes - and then, when do both F/J and M/F implement the new collection structures ?).

Assuming you are thinking other than M/F then you will have to avoid the M/F features like :-

a) using z"myfile.ps" - F/J users would have to confirm if you can do this by tagging (concatenation) x'00' on to the end to get the equivalent to the above.

b) pic x(4) comp-5 - a No, No. F/J has pic 9(09) comp-5 - COBOL 2002 acceptable.

c) Something that ties in with how dotNet works - but you have already done it - your method names must be CamelCase/CamelBacked, (besides which  J4 have recently stipulated that as the standard for COBOL).

There are a couple of F/J OO users here -  if interested, perhaps they could make suggestions.


I certainly think your suggestion has merit as a starting point. If you want to e-mail me privately, drop the second "J" in my email address.

Jimmy, Calgary AB
0
jjgavan (507)
11/8/2004 7:24:14 PM
Alain Reymond <> wrote 

> I have been trying to find a library to make the production os
> postscript file easier from our cobol programs. 

Do you really need to build the postscript into the program ?  For my
postscript output I create a template using a screen based designer,
such as impress or xfig or similar, and put on the form where the text
data is to be substituted, such as using tags in the form
<%FIELDNAME%----->.  When the form is to be output the tagged items
are replaced by the required actual data.

This means that the design of the form can be done viually, and can be
changed without touching the program (unless additional data items are
required).  This also means that the code that does the data merge can
be reused for other forms.
 
> Finally, I have begun to write a library in OO cobol largely inspired
> from the C pslib library. I have just finished to prepare the
> interface of the different methods and write a few methods.

Are you reinventing the pslib code or writing a Cobol OO wrapper
around the pslib library ?
0
riplin (4127)
11/8/2004 11:34:17 PM
Alain,

you have received good responses to your post. I'll simply add a couple of
cents worth.

see below...

<Alain Reymond> wrote in message
news:kt3vo0hfase0ju3qt62rtk5pbg3bg5f72s@4ax.com...
> Hello,
>
> I have been trying to find a library to make the production os
> postscript file easier from our cobol programs.
>

Richard has a valid point when he says this is best done outside of COBOL.
There is much merit in using "layered software" and the production of actual
output (whether to a screen,  a printer, a microfiche, or a T-shirt...)
should properly be another tier in the system design (software or hardware).

However, Jimmy has also made some good points for actually doing what you
propose, and he has carefully covered differences you may encounter in
different OO compilers. I endorse his basic statement that it is really
important to keep this kind of code NEUTRAL.

> Finally, I have begun to write a library in OO cobol largely inspired
> from the C pslib library. I have just finished to prepare the
> interface of the different methods and write a few methods.
>

Richard asked whether you were simply wrapping the C PSLib as OO COBOL or
re-inventing it. From the above its would appear you are re-inventing it. I
don't personally think that is wrong; sometimes things need to be
re-invented (although I don't use PS enough to be in a position to comment
on that specifically), but even if it is redundant you want to do it and the
learning experience alone may justify doing it. If you then share that
experience with everyone, I can't see how anybody is the poorer for it.

> Teh generation of postscript file could then be:
> invoke PSDoc "PSOpenFile" using z"myfile.ps"
> invoke PSDoc "PSMoveTo" using x, y
> invoke PSDoc "PSLineTo" using ...
> invoke PSDoc "PSCircle" using ....
> etc...
> which is - to me at least! - easier to read than the postscript
> statements.
>

It is certainly easier to read for an OO COBOL programmer...

> I thought that it might be an interesting project for an open source
> library in cobol.

Yes, certainly.

>There are too few projects for the most used
> programming language in the world.
>
Er... what world do you live on <G>?  This statement was true 40 years ago,
today COBOL is not even in the top three...

> This is just an mail to see if anyone would be interested before
> placing it on the web.
>
It's a good project... go for it.

Best of Luck,

Pete.



0
dashwood1 (2140)
11/9/2004 2:26:40 AM
Hello,

I have indeed received good reponses and I'll try to get further in
the project before placing a first release.

>Richard asked whether you were simply wrapping the C PSLib as OO COBOL or
>re-inventing it. From the above its would appear you are re-inventing it. I
>don't personally think that is wrong; sometimes things need to be
>re-invented (although I don't use PS enough to be in a position to comment
>on that specifically), but even if it is redundant you want to do it and the
>learning experience alone may justify doing it. If you then share that
>experience with everyone, I can't see how anybody is the poorer for it.

Yes, I choosed to re-invent the library even if I usually try not to
do so. But I prefer to have something in pure cobol and not deal with
C interface. And also for the learning experience and for the fun!

> Er... what world do you live on <G>?  This statement was true 40 years ago,
> today COBOL is not even in the top three...
I know, I know... It is still widely used and many business still rely
on it...

Regards.

Alain
 

0
Alain
11/9/2004 10:03:48 AM
Reply: