Can a company use Perl to develop (and sell) commercial tools?

The SANFACE Software experience

By Fabrizio Sanface, Helmar Wodtke

Why perl?

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. 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

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 ( and perl2exe by IndigoSTAR (

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.


Why commercial tools (shareware)?

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 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

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#)

Is it possible to sell tools, distributing the source code?

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 ( 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.


Why a tool (why not a module)?

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:

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!

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.


Why Perl community doesn’t like commercial tools?

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

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!