What printers are supported?
First off, any printer for which there is a Windows print
driver is supported in PSL. Consequently, and for example,
if you can send a Word document to your printer –
you can send a PSL PDF to your printer. However that is
not the end of the discussion.
You can also send a PostScript™
file to your printer. Or for that matter, you can simply
places a PDF or PostScript file in a “hot folder”
and release it to your printer as you see fit.
Also, we are hard at work with both EFI™,
who make the Fiery RIPs and Creo to support their RIPs.
There are some issues to address. Should you be interested,
give us a call.
We do international business, can you support foreign
Having landed a UK account, we implemented Unicode (UTF
8) as the basis for PSL. Consequently PSL supports a whole
host of languages.
We do transactional work; can PSL support that kind of
The answer is; “In spades.” Transactional
work often involves parsing print files and that work
can be handily done in PSL. Therefore you don’t
need a two step process. Furthermore, PSL’s file
handling brings a lot of robust programming tools to this
As invoicing and statement work often
involve some rather complex document formatting, PSL is
well suited to provide the flexibility needed. Please
see the web site or the ftp site for examples.
Dealing with fonts drives us nuts. How does PSL deal with
PSL uses TrueType™ and OpenType™ fonts. These
are vector fonts – the font is described as lines.
In PSL one can adjust the line thickness and fill the
open spaces with colors or patterns. In PSL fonts can
be scaled to ANYTHING.
What kind of images can be imported?
Almost anything – PDFs, JPEGs, TIFFs, etc.
We just do simple work. Is PSL right for us?
We can only say – perhaps. We too will
be introducing a “Drag ‘n Drop” solution
soon. For some firms, that is all that is needed. It’s
really a matter of attitude or the famous “mind
set.” Once learned, a programming language, such
as PSL, in the proper hands, can setup a simple job every
bit as quickly, if not quicker, than a drag ‘n drop
solution. Of course, once things get complicated, the
programming language (PSL) becomes mandatory (and very
important from a competitive view).
To some extent, it’s a matter of
time. Many of the VDP solutions depend on “plug-ins”
to the common graphic engines (InDesign™ for example).
Consequently they tend to have slow merge speeds.
PSL can do merges at the rate of 30 to50
thousand records a minute!!!
We’re interested in web enablement. Can PSL be involved
in such matters as print on demand and web presentment
of transactional documents?
That is what PSL was designed for. First, PSL
can call or be called by other languages. We have a class
for calling from PHP. Second, we have the speed –
300 records per minute, from presentment of variables
to PDF ready to transmit.
some cases, it is appropriate to load the client with
PSL code snippets to assemble the PDF, based on variables
sent to at the client site.