By Fabrizio Sanface, Helmar Wodtke
At the
beginning we didn’t select the language.
Seven years
ago I (Fabrizio Sanface) was a Unix administrator and I started to use Perl in
preference to script shells (bsh, csh, ksh,…).
Four years
ago I started to develop the first SANFACE Software tool: txt2pdf.
I’m not a
programmer and the only language I knew was Perl.
Then, four
years ago, we decided to distribute a shareware tool written in the Perl
language. It was a very strange choice! Now we’re very happy about a similar
strange choice.
With few
modifications we transformed our tool into a cgi to create PDFs on the fly on
our web site.
http://www.sanface.com/createpdf.html.
It was one of the first web application to make PDFs on the fly.
Using a
tool similar to a library we created more complex web services like
http://www.sanface.com/flash4/ferrari/.
Today
everything is more simple and it’s possible to develop tools using Perl,
transform the Perl code into executable versions and distribute only the
executable versions.
We have
tested 2 tools: Perl Dev Kit by ActiveState (http://www.activestate.com) and perl2exe
by IndigoSTAR (http://www.indigostar.com).
With Perl
Dev Kit it’s possible to develop using perl and create executables for Windows,
Solaris, Linux and HP-UX.
Two years
ago, we selected perl2exe approach because:
We’re
waiting for Perl 6 news J
Probably
our tools are the only tools that can make PDFs on OS’s like: OpenVMS, MPE,
OS/390, EPOC, etc. in the same way on every OS and with the same code.
Obviously using Perl J
Another
important point, we’re evaluating, is the possibility to make a Graphical User
Interface (GUI) for our products using perl/Tk. At the moment we have made a
Visual Basic (VB) GUI for the Windows distribution. Windows customers like the
GUI in Windows style.
Four years
ago only few software houses had products that can create PDFs. These tools
usually converted PostScript to PDF or were libraries.
A text to
pdf converter was an innovative idea and we thought we can earn well selling
this product.
At the
begin, we didn’t understand the true market.
Our first
customer was Alex project http://www.infomotions.com/alex/
and we thought that the target of our product was to convert textual books into
PDFs.
Then we
understood that a lot of companies have a lot of applications that produce
textual reports (old legacy applications written using cobol, ERPs,
datawarehouses, DBs, etc.). Usually the companies purpose was to print the
textual reports over forms and send them via normal mail or fax. Simply we gave
to these companies an application that worked the same way. We gave them the
possibility to design a background form (using a part of PDF syntax) and to put
the data (the textual report) over it making nice PDFs.
With a
simple tool their old applications can create from simple textual reports, nice
and powerful PDFs.
At the
begin we wanted to give to our customers the possibility to add a lot of new
features, adding to the textual reports special marks. Then we understood that
the companies don’t want to modify their original textual reports.
They simply
need to have them in a new format that help them to print them, to send them
via email, to publish them on web, to fax them. PDF is the best format to solve
this problems.
We don’t
force the companies to add tags, we give them external files where to set
general rules using the powerful of regular expressions (RE).
e.g. with
txt2pdf PRO is possible to use fontmark external file with this syntax like
;;SANFACE
Software;/F12;12
to use font
/F12 point size 12 with every string “SANFACE Software” or more complex example
like
<b>;</b>;#!btag#.*#!etag#;/F5;14
means: the start tag is <b>, the end tag is </b> delete the tags an
use the /F5 font with point size 14 to every word (.*) inside
<b>(#!btag#) and </b>(#!etag#)
I’m Italian
and when I talk to other Italian people they tell me:
“You’re
crazy. How can you think to sell a tool distributing the code? Are you not
afraid that people can copy the code and the tool?”
We’ve not
protected the registered version.
The only
way we use to protect our code was License Agreement.
We trust
our customers and we trust people.
Is it the
correct way or we’re crazy?
Here is
some data about our business:
Txt2pdf is popular
at C|NET (http://download.cnet.com/):
this means that at the moment it was downloaded 23,000 times. In the same way
we’re present at TuCows and in every other Download sites. We spent a lot of
time with web marketing (try to digit e.g. txt2pdf or sanface in a search
engine). We estimate that txt2pdf has been downloaded more than 100,000 times
worldwide.
On the
other hand we’ve 600 customers. The 95% of our customers is located in US.
We have
talked a lot of times about this point. This is our point of view:
Companies
usually don’t need modules or libraries.
When a
company has to solve a problem it wants an open tool that can solve its
specific problems.
Usually
money isn’t a big problem, time is a very big problem, to find the right person
with the right knowledge is a very big problem.
The only
point I was sure was: we have to make a very open (STDIN and STDOUT) server
batch tools that the customer can use from every program on every OS to convert
very big volume of data in a small time.
Also, we
give to our customers very quick and good support.
If you’ve
ten days and you find a very good tool but:
you won’t buy a similar product.
We know a
lot of companies who bought our tools and used them like modules inside their
applications (e.g. cobol and java applications).
Description
of few projects:
http://www.sanface.com/hfmusproject.html
Hachette Filipacchi Media
U.S., Inc. (HFM U.S.), the
New York-headquartered subsidiary of Hachette Filipacchi Médias, (the world's
largest magazine publisher) began a project in 2001 to decommission our last
remaining mainframe system. The single application running on it was almost
100% COBOL and responsible for acknowledging and invoicing orders places for
advertising in our magazines. The project was to move it to Windows NT without
rewriting it all.
A main obstacle was output. The COBOL was spitting out thousands of
acknowledgements and invoices monthly on preprinted multipart forms, not to
mention reams of paper reports, all using line printers and 1st-column carriage
control. We sure didn't want to try to configure NT to output to a line
printer! txt2pdf PRO helps us to solve the problems!
http://www.sanface.com/pdf/hfmus.pdf
http://www.sanface.com/halifaxheraldproject.html
The Halifax Herald Limited, one of Canada's oldest and largest
independent newspapers.
Like all metro daily newspapers, the Herald publishes hundreds of
display ads and thousands of classified ads every day, resulting in thousands
of daily invoices and monthly statements. For years we printed duplicate bills
so the Accounting Department would have file copies in the event an advertiser
had questions or required a reprint.
Obviously, a significant amount of time and space was occupied handling these
bills -- separating, filing, finding, re-filing -- all very manual processes.
The bills themselves begin as huge ascii files that are printed on continuous
pre-printed forms using IBM 6400 line printers.
In 2000, we developed a PERL-based document management system that indexed the
ascii files by invoice number. This allowed the Accounting Department to search
for a particular invoice or statement and display it on their screen. The
system was quite convenient for them but not robust enough to allow us to stop
printing and filing duplicates.
It proved that a document management system would save time, money and storage
space, and allow us to better serve our customers. Managing, protecting,
indexing and cross-referencing all these ascii files was a primary challenge.
An Oracle database, fronted by a cgi interface using DBI/DBD and PERL was the
answer. The other major concern was the integrity of ascii files -- they're
easy to alter. This made PDF desirable. Customers, auditors and taxmen could
agree that PDFs were exact replicas of original bills.
How to convert our ascii files to PDF? A quick search of the web turned up
txt2pdfPRO. Right out of the box it produced perfect PDF versions of our bills.
Of course they were still plain text, hard to read on the screen and painful to
print on line printers.
txt2pdfPRO's overlay/underlay capabilities provided a perfect solution --
underlays exactly replicating our pre-printed forms, color-matched and complete
with the Herald logo. Now the PDFs look just like the bills we print, making
them easy to read on the screen and suitable for reprinting on laser printers.
While evaluating txt2pdfPRO we discovered it also converted all our large
reports accurately to PDF. These reports are hundreds of pages thick and many
are just for historical record.
http://www.sanface.com/pdf/heraldbill.pdf
The Perl
community is the only freeware community (we know) that doesn’t like commercial
tools. It’s impossible to announce a new commercial tool version in a Perl
newsgroup and in Perl site.
It’s
impossible to publish a Perl commercial code at CPAN.
This is
also true for tools like our txt2pdf that is shareware and we distribute with
the Perl code.
Our point
of view is: the Linux community is grown up because it’s based on freeware core
but it allows commercial tools and partnerships.
We think
we’re in an very strange position.
We’re
probably one of the few companies that use Perl to develop its tools, but Perl
community doesn’t like our work L
We publish
everywhere in our site we’re using Perl and we’d like that the Perl community
to use our knowledge and our projects with big companies http://www.sanface.com/projects.html
The market
and other communities like Linux, OpenVMS, MPE, cobol like our tools.
We think
we’re showing that
“a
company can use Perl to develop (and sell) commercial tools”.
We’d like
other companies can make the same with the help of Perl community J
We hope
this paper is the first step!