On Apr 1, 5:23=A0am, razor <irudd...@[EMAIL PROTECTED]
> wrote:
> Hi Chaps
>
> An avid reader of this forum for years. Very interesting at times.
>
> I have a question I am sure somebody can help me with.
>
> I currently look after a customer who use all HP laser printers. 20
> years ago we embedded PCL code to control these printers. Setting
> landscape/portrait, duplex pages, the odd underline and bold bits.
> When we moved to M/F Netexpress 3.1 we adopted the PC_PRINTER routines
> and send a 'raw' file to the printer. I now have a new 'customer'
> asking for some system and I am going to need to print for them. I
> can't expect them to use HP printers here so what are my options. I
> assume the PCL language is a HP thing and other printers won't
> understand it.
I tend to do all my printing, or other output, using templates
wherever possible. Templates contain all the formatting information
plus tags where the data items are to be substituted. For repeated
data there are several ways to achieve this, one way is the have the
template divided into named sections and the program calls for that
section as many times as required. Another way is to pass a table from
the program to the templating routine to cater for the repeating
groups.
Generally the data is passed as 'name:value' pairs in a table where
'name' relates to the tagname in the template and 'value' is to
replace the tag. This table may also need 'type' and 'length'. The
'type' may need to indicate that there is a series of values in a
second table if that mechanism is used.
Different templates can be used depending on the printer being
addressed. This is a matter of knowing the type of the printer
required and then naming the templates appropriately as report.type.
Then if you want a webpage output, or XML, or a PDF, or a CSV file, it
is only (!!) a matter of creating an appropriate template and having a
notional 'printer' of that type with the templating routines writing
to a disk file.
On Unix/Linux with CUPS printing system all printing can be Postscript
regardless of the actual printer capability as drivers will convert to
PCL or plain text as required, so templates can be fragments of
Postscript, though it also works if you output PCL or plain text to a
PCL printer.
For graphics type output forms (such as invoices) I use a slightly
different mechanim by drawing the postscript form with a vector
drawing program (I use tgif, it is old but reliable). Each output
field is signalled with a tag that is extended to the correct width
and length and set to the required font and other attributes. This
would be difficult to handle in Cobol so the program uses a template
to write out a merge file and a C program is actioned to merge the
data items into the form.
Actually, many years ago, I used JetForm under DOS (actually a
Multiuser DOS) with good results by having the program write a merge
file for that and then used my C program to replace JFMerge when I
needed Postscript. So the merge file mechanism is based on the
requirements of that. To illustrate how old that JetForm is, the
designer runs under Windows 2 and won't run on Windows 95 so I still
have a Windows 3.11 install (which will run Win2 programns) on a
virtual machine in case I needed to rework forms still in use.
|
