Forms (printed) processing on VMS? - VMS
This is a discussion on Forms (printed) processing on VMS? - VMS ; Hi.
Many years back I used JetForm for printed form
processing on VMS (mVAX 3100/90 at the time).
This works just OK. JetForm Design was used on
a Windows PC to "design" the forms and then
JetForm Merge was run ...
-
Forms (printed) processing on VMS?
Hi.
Many years back I used JetForm for printed form
processing on VMS (mVAX 3100/90 at the time).
This works just OK. JetForm Design was used on
a Windows PC to "design" the forms and then
JetForm Merge was run on the VMS box to "merge"
the application data with the forms and printed
on standard lasers, usualy HP LaserJet 4's at the
time.
As far as I have found out, JetForm was bought
by Adobe and VMS support was dropped some years ago.
Now, is there anything available today similar
to this tools ?
Jan-Erik.
-
Re: Forms (printed) processing on VMS?
Jan-Erik Söderholm wrote:
> Hi.
>
> Many years back I used JetForm for printed form
> processing on VMS (mVAX 3100/90 at the time).
> This works just OK. JetForm Design was used on
> a Windows PC to "design" the forms and then
> JetForm Merge was run on the VMS box to "merge"
> the application data with the forms and printed
> on standard lasers, usualy HP LaserJet 4's at the
> time.
>
> As far as I have found out, JetForm was bought
> by Adobe and VMS support was dropped some years ago.
>
> Now, is there anything available today similar
> to this tools ?
>
> Jan-Erik.
If the data is test you can write the form in Postscript and put it into
the device control library. The postscript reads the rest of the print
stream as data and controls printing. I can give you samples if you are
interested.
Jeff Coffield
www.digitalsynergyinc.com
-
Re: Forms (printed) processing on VMS?
Jeffrey H. Coffield wrote:
>
>
> Jan-Erik Söderholm wrote:
>> Hi.
>>
>> Many years back I used JetForm for printed form
>> processing on VMS (mVAX 3100/90 at the time).
>> This works just OK. JetForm Design was used on
>> a Windows PC to "design" the forms and then
>> JetForm Merge was run on the VMS box to "merge"
>> the application data with the forms and printed
>> on standard lasers, usualy HP LaserJet 4's at the
>> time.
>>
>> As far as I have found out, JetForm was bought
>> by Adobe and VMS support was dropped some years ago.
>>
>> Now, is there anything available today similar
>> to this tools ?
>>
>> Jan-Erik.
>
> If the data is test you can write the form in Postscript and put it into
> the device control library. The postscript reads the rest of the print
> stream as data and controls printing. I can give you samples if you are
> interested.
>
> Jeff Coffield
> www.digitalsynergyinc.com
Yes, as an alternative method it might be intersting.
The problem might be producing the PS "source" to put
into the devctl lib, I guess.
If you have someting you'd like to mail, you can find
my email adress here : http://www.jescab.se/Kontakt1.htm
I can add that the "form printing" is run directly
from COBOL apps using simple text format with some
PCL "commands" today. It's a lot of application
changes for any changes to the "forms". The whole
form is in the DATA DIVISION...
Jan-Erik.
-
Re: Forms (printed) processing on VMS?
Jan-Erik Söderholm wrote:
> Hi.
>
> Many years back I used JetForm for printed form
> processing on VMS (mVAX 3100/90 at the time).
> This works just OK. JetForm Design was used on
> a Windows PC to "design" the forms and then
> JetForm Merge was run on the VMS box to "merge"
> the application data with the forms and printed
> on standard lasers, usualy HP LaserJet 4's at the
> time.
>
> As far as I have found out, JetForm was bought
> by Adobe and VMS support was dropped some years ago.
>
> Now, is there anything available today similar
> to this tools ?
>
> Jan-Erik.
I don't know of any.
How about just designing your own form on your own printer? Then ask a
printing company to print nice colored lines and tints around where your
laser printer will fill in the blanks?
This would only work if you wanted preprinted forms in large quantities.
No good if you need five copies each of a hundred different forms!
-
Re: Forms (printed) processing on VMS?
How complex are the forms ?
What I have done in the past was to design it on Freehand/Illustrator.
Then I created it in postscript myself using the point positions that I
obtained from the graphic program (click on object and gets its info
which includes position, size etc).
Then, I would add the potscript logic to add my data to the form.
At run time, you have a clean poscript that draws the form, and clean
logic that takes arguments and puts your data up on the form.
the postscript code generated by drawing packages is way too bloated and
complex to be usable "manually".
-
Re: Forms (printed) processing on VMS?
JF Mezei wrote:
> How complex are the forms ?
Not that complex at all, when printed on paper... :-)
But the COBOL code uses a lot of hardcoded PCL ESC-
sequences. There is a lot of code like :
*------------------------------------------------------
* THIN LINES VERTICAL
* SET CURSOR POSITION (DOTX 480 DOTY 3800) /720 inch
05 FILLER PIC X VALUE ESC.
05 FILLER PIC X(6) VALUE "&a480H".
05 FILLER PIC X VALUE ESC.
05 FILLER PIC X(7) VALUE "&a3800V".
* HORIZONTAL RULE/PATTERN (3 DOTS)
05 FILLER PIC X VALUE ESC.
05 FILLER PIC X(4) VALUE "*c3H".
That snippet is from a COBOL source that by itself has
close to *650* lines with "FILLER PIC X VALUE ESC." :-)
And that is not the only source...
It would be quite a lot of work if they'd ask for
some major revision of the printouts...
>
> What I have done in the past was to design it on Freehand/Illustrator.
> Then I created it in postscript myself using the point positions that I
> obtained from the graphic program (click on object and gets its info
> which includes position, size etc).
>
> Then, I would add the potscript logic to add my data to the form.
Today just a few of the 60-70 printers are PS printers,
but I'm trying to get "PS" into the picture when
getting new or replacing old printers.
>
> At run time, you have a clean poscript that draws the form, and clean
> logic that takes arguments and puts your data up on the form.
>
> the postscript code generated by drawing packages is way too bloated and
> complex to be usable "manually".
Yes, I guess so.
I'd rather use some packaged solution like the JetForm
Design/Merge combo. We'll see what the folks at Flexform
(www.flexform.com) says...
Thanks anyway !
Jan-Erik.
-
Re: Forms (printed) processing on VMS?
Richard B. Gilbert wrote:
> Jan-Erik Söderholm wrote:
>> Hi.
>>
>> Many years back I used JetForm for printed form
>> processing on VMS (mVAX 3100/90 at the time).
>> This works just OK. JetForm Design was used on
>> a Windows PC to "design" the forms and then
>> JetForm Merge was run on the VMS box to "merge"
>> the application data with the forms and printed
>> on standard lasers, usualy HP LaserJet 4's at the
>> time.
>>
>> As far as I have found out, JetForm was bought
>> by Adobe and VMS support was dropped some years ago.
>>
>> Now, is there anything available today similar
>> to this tools ?
>>
>> Jan-Erik.
>
> I don't know of any.
>
> How about just designing your own form on your own printer? Then ask a
> printing company to print nice colored lines and tints around where your
> laser printer will fill in the blanks?
>
> This would only work if you wanted preprinted forms in large quantities.
> No good if you need five copies each of a hundred different forms!
Preprinted old-style forms is not an option. They uses
simple single-tray printers and more then one "form".
-
Re: Forms (printed) processing on VMS?
Jan-Erik Söderholm wrote:
> Yes, I guess so.
> I'd rather use some packaged solution like the JetForm
> Design/Merge combo. We'll see what the folks at Flexform
> (www.flexform.com) says...
One of the advantages of cook-your-own-Postscript is that you can embed
some of the display logic in the postcript to separate it from the
application.
For instance, when printing a statement for a customer, the application
could just include a "language" field, and let the postcript then
include the form background applicable to that language as well as
"word" translatiosn for different codes (eg: for an english customer,
the province code "BC" might get printed as "British Columbia" while for
a french customer, it would be "Colombie Britanique".
When using shrinkwarpped software for forms, you may have less
felexibility and may have to include more of the display logic in the
application itself.
Postscript is a pretty powerful language.
For istance, to print a mailing label, postscript code can format the
address different ways depending on the country that is specified, and
the application doesn't have to worry about building the address label
correctly.
And while display postscript is gone on VMS, there is ghostscript on
VMS, and on a MAC, the "display postscript" functionality is embedded in
the OS.
With postscript, you can also convert it to .pdf and mail the statements
to the customers. I think this is a big plus compared to that PCL stuff.