Max Wyss takes Acrobat PDF Forms to the max
But Adobe's release of Reader 5.1 is 'killing my best
21 October 2002
By Kurt Foss, Planet PDF Editor
INTRODUCTION: We first became acquainted with Max Wyss and
his increasingly amazing work in Switzerland with PDF-based forms
nearly five years -- and several versions of Acrobat -- ago. With its
Acrobat 3.0 release, Adobe had introduced the first incarnation of a
plug-in for developing (and another for completing on screen)
electronic forms in the portable document format. At that point in
the product's evolution, the most prominent and promoted use of PDF
was for prepress; and accordingly, most third-party Acrobat plug-in
development targeted that niche industry and relevant
Prevailing practice aside, the potential for PDF as an optimal
format for electronic forms inspired Max to explore the
possibilities. And what an explorer he has turned out to be! We
recall one long-distance phone call in 1998 in particular when Max excitedly
shared (in his distinctly German-flavored English) details of a
forms-based company catalog on CD-ROM he had developed for a Swiss
client, an electronic document that, even judging by today's
standards of complexity and interactivity in forms development, would
be considered incredibly complex. At a time when there was little
debate that PDFs were by nature static documents, Max's carefully
crafted catalog built with forms -- containing hundreds (and later
thousands) of interrelated fields -- seemed almost magical. Max was
truly the first to take Adobe Acrobat PDF Forms to the max!
Adobe Systems now appears ready to try to maximize Acrobat's forms
potential. The introduction today of a range of new
enterprise-oriented Acrobat products and solutions, in part evolving
out of its recent acquisition of the Accelio
Corporation earlier this year, clearly demonstrates that electronic
forms and other types of corporate documentation are now a major
point of focus in the company's long-term product strategy.
Max remains a popular conference speaker and workshop presenter at industry events in the
U.S. such as the upcoming PDF Conference from
DigiPub Solutions Corp and the recently held Seybold PDF Conference, and other similar events
closer to his home turf. He also consults with a variety of clients,
including the Internal Revenue Service (IRS), the most prolific user
of PDF in government. For those less knowledgeable about PDF Forms --
and that includes pretty much the universe of users -- the good news
is that Max is also extremely generous in freely sharing much of his
acquired expertise. He's a frequent contributor to numerous online
watering hole discussions, for example, including our Planet PDF
While a long-time advocate for some of the new features now
available in version 5.1 of the free Acrobat Reader, the introduction
today of this enhanced version creates at least one problem for Max:
Adobe is causing him to retire a frequently cited punchline about the
product's name that has become something of a signature statement. We
begin our discussion with Max on that light-hearted note, then
backtrack more seriously to learn about his background, bona fide PDF
Forms expertise and experience, and thoughts about the PDF future.
Planet PDF: You're well-known in PDF circles for a
particular, oft-repeated response to a commonly asked question --
about the deliberate lack of a "Save" feature in the free Adobe Acrobat Reader. That is, someone
completing a PDF Form has to date not been able to directly save the
entered data with the form document using only the free Reader.
(There are server-related workarounds for those not willing to invest
in the full commercial Acrobat or Acrobat Approval products, which include that
capability.) "If it could 'Save,' it would have been called
'Saver, wouldn't it?" you've replied in good humor to countless numbers of
frustrated users who discovered the intentional limitation. But as you know from having seen the Adobe "tech demo" at the Seybold PDF Conference in New York early this year, Adobe is releasing [today] a new version (5.1) of its free Reader that includes a true "Save" feature. Will you soon have a new signature
statement or slogan to replace your infamous "Saver" response? And
more seriously, what do you think of the various new featuresthey've rolled into this new Reader
(or should we now call it "Saver")? What are the implications of this
new version -- that includes among other new capabilities the ability to handle with PDFs that may have had a set of specific document rights assigned by the publisher -- for authors and users of PDF Forms?
MAX WYSS: Yes, indeed I started that saying, and now, it
seems that Adobe is killing my punchline. For that they owe me one! ;-}
Well, with this new concept, it is no longer the application that
includes a certain set of rights, but those rights are attached to the
document. This means that the provider of the document is responsible
for the rights attached to it. So my answer will more and more
become: "Has the sender of the form given you the right to
save?" Of course, this is not such a good quote anymore, but I am
sure that I will get something snappy again.
Which brings me to a general suggestion to all providers of such
enhanced forms: We should set up a convention where we state pretty
visibly which rights are actually granted to the document. And then,
this could be communicated big style. And this would allow some good
sayings too, such as: "If it's green and quacks, it can save."
MAX: This is a longish story, but I'll tell it anyway. It
is back in the ages of pioneering Acrobat and PDF.
It is true that the first real form capabilities were introduced
with Acrobat 3.0. This made it possible to enter data into fields, to
have actions, and to do the simple calculations.
What got me to become a very early adopter was an actual project. Back in the times of Acrobat 2.1, I proposed an interactive product
catalog to René Baer AG, a small Swiss company that is a dealer and
manufacturer of belt-drive components (v-belts, timing belts etc. are
all known from automotive applications, but such things are
everywhere). One of the problems they had was that, more than often,
the customers ordered the wrong items (for example, not matching
profiles of belts and pulleys), and it did not get noticed until they
received the material they had ordered. The reason is that
conventional belt-drive catalogs are pages and pages of tables, and
it is very easy to look up the wrong table.
One requirement was to stay within a profile system. Another issue was
that for pulleys, there are standard catalog products, but the
customers of René Baer AG are not automotive customers who maintain large quantities of a few standardized items -- they have smaller quantities of
customized items. Customization could for example be a different
center bore, or a wider or narrower hub. This made the mismatch issue
even worse, as customized items had to be taken back, but could not
be used elsewhere and ended up in the scrap. But in order to make it
easier for ordering the customization, we wanted a worksheet, where
the users could enter their own values.
The first version was actually created with Adobe FrameMaker and
placed PDFMARK EPS files which created links (Links and PDFMARK were
available in Acrobat 2.1). However, we blew the limits of the system
-- the biggest file that did not crash Distiller took about 12 hours
So, we needed another approach, and in the meantime, Acrobat 3
came out with the forms functionality, and the forms data format
(FDF). This got me the idea to not have an individual PDF page for an
item, but use base forms, and do the individual items with FDFs
containing data, of course, and also containing actions. These
actions made it possible to, for example, switch to the next longer
or shorter belt, to the next wider or narrower pulley, without
changing the other parameters. As FDF files are simple text
files, it was possible to create them with a database. In our case,
we used the simplest, but very powerful database around: Filemaker
Pro. So, we entered all the relevant data into this database, and
created the according FDFs. As an FDF has the information about the
Base PDF, we could have the FDF open its according base, allowing for
displaying a fully dimensioned graphical representation of the
All this was considered to be pretty cool, but another issue my
client had about that CD was to include a tool to actually specify
the drive, using the base data, such as power to be transmitted, or
rpm of the drive and driven pulley, etc. The literature does have
some tables, also containing nomographs which made it kind of
possible to specify the drive, but it required a lot of guesswork and
experience. So, almost every other phone call with René Baer AG led
to a question: Whether it was also possible to do (interactive)
In the meantime, Thomas Merz (author of PDFlib) published the freely available sample chapter of his book "Mit PDF ins World
Wide Web" (the English title was "Web Publishing with Acrobat/PDF," but
the book is now out of print). And there were two sentences referring
Acrobat 3, I contacted Thomas, and wanted to know more. Well, fact
was that the Acrobat 3.5 Forms Update was delayed, and that was the
request, to create a drive specification form.
When the Acrobat 3.5 Update finally came out, I jumped on it. My
very first smart PDF form was actually a form to specify a
two-pulley, v-belt drive. When was that? Spring/summer 1998.
PP: When you eventually showed your original Baer catalog project created with Acrobat 3 to someone from Adobe, what did they think of it? After all, at the time most users considered it 'cutting edge' to "fill-in" a PDF form electronically rather than printing it first. After filling it in with the v. 3.5 Forms Update plug-in, *then* you printed it!
"Acrobat Fill-in - Adobe Acrobat Forms Update is two plug-ins, Forms
Author and Forms Fill-in. These plug-ins make it faster and easier to
exchange information - either in familiar paper forms converted to PDF,
or as dynamic interactive database publishing. The Forms Update allows
you to bring the rich capabilities of PDF to the data collection process
that comprises an online information transaction. As expected, PDF forms
retain the rich look and feel of their paper equivalents."
MAX: The very first time I showed this to someone from Adobe, it was the technical pre-sales support guy of Adobe Switzerland, and he did like it quite a bit, and having a technical background, he liked the practical application.
The first time I showed this in public was at Seybold Boston 1999, at the very first "PDF Day." My presentation definitely impressed them. When Stephen Keese [former Acrobat Evangelist at Adobe] introduced me to some other guys from the company, he said something like "there were about 500 people in the room; total silence; nobody understood anything (because that catalog was in German); nobody had a clue (you don't deal with belt drives every day, don't you); but they all were fascinated of what they saw."
So, I guess this made a deep impression -- at least with the engineering/development people. I am not so sure how well it got taken by the "product management" or marketing people; it might have been too high a level for them, as it was absolutely not what they were thinking Acrobat was supposed to do or to be.
A little bit later, I had the chance to present my stuff in front of engineers at Adobe HQ in San Jose, and they were indeed impressed.
PP: Tell us a little about your small PRODOK Engineering company there in suburban Zürich: How did it get started, who's involved, what sort of work does the company do, and what kinds of clients and needs do you primarily serve, etc.?
PRODOK Engineering is essentially me and my "partner in crime," Makiko Itoh.
After graduating from the Federal Institute of Technology in
Zürich as materials engineer, I started on a PHD thesis. For various
reasons, this project got cancelled after three years, and I had to
find a way out. I had enough of materials science, and started a
post-graduate course in Industrial Engineering, at a partner
institute of the Federal Institute of Technology. In the meantime, I
had to find a way to make some money, and it showed that the work
which was most convenient schedule-wise with the classes was
technical writing. So, I worked part-time for a small, independent
provider for technical documentation. When the post-graduate course
was finished, I had the choice to either move closer to headquarters,
or to find a way around. I decided to start my own business, in
technical documentation and technical translation. And that was the start of
PRODOK Engineering. I've been running my own business -- more or less
successfully -- as a technical writer and translator for a good 10
I always was more interested in tools than in the actual work
(which can be a bit dangerous), but this gave me an overview of the
technologies used in the field. Even back then, when the highlight of
computer technology was a dedicated word processing system -- anyone
remember CPT? -- I did some interesting stuff. CPT had a function to
microposition the roller and the printing head of a daisy wheel
printer, allowing the creation of some very simple graphics (by
hammering the period on the paper like crazy!).
Using the macro-functionality of that system, I created a toolkit for flow charts, which were used quite a bit in the detail specification for one of our clients. Crazy stuff, but I think that 8-inch floppy with the toolkit is still somewhere around.
Anyway, this technical documentation work got me in contact with
PDF. There was a very short window when a full version of Acrobat 2.1
was bundled with Adobe Illustrator, and I was lucky to get my
Illustrator at that time. The first practical use of PDF was actually
to get CAD drawings into Illustrator in order to enhance those
drawings -- so that they could be used in the documentation.
My clients at that time were mainly Swiss companies, such as
Hasler/Ascom, Ilford, Nixdorf (where I was a victim of the merger
with Siemens), Omega Electronics, or ABB Power Generation. In most
cases, I handled everything related to documentation, starting with
the complete concept, structure, the actual writing, illustrations,
translations, layout, and production management.
This gradually took me into the PDF field; eventually I had to to
make some decisions on how to continue. Considering myself to be
better than average as a technical writer, in the top 15 percent as a
technical translator, but pretty much unique in doing very advanced
PDF forms work, the decision was clearcut. Today I no longer have any
technical documentation clients, and do translations only for
long-time clients -- on topics in which I have a special expertise
and that I like.
The rest is consulting, developing and training in the PDF Forms
area. My current clients are all over the place. Right now I am
working on an update of the catalog CD-ROM for René Baer AG, my
"launching client" ... and guess what, those concepts from 1997/98
are still kind of unique and ahead of their time, although time did
catch up a bit. Other clients are in the publishing business, where I
provide the "engine" for smart publications. For example, Beaty's
"Handbook of Electrical Power Calculations", published by
McGraw-Hill, has a bunch of interactive equation-solving forms for
which I created the logic. Other clients are government agencies --
in Germany, Switzerland and the US -- for whom I haved created
individual smart forms. One example is an employee evaluation form
where the rating is automatically evaluated, and the overall
evaluation is calculated based on a set of rules.
Training is also provided to anyone willing to pay. I have done
trainings for financial service companies in Switzerland and the US,
for government agencies in Germany, Switzerland and the US, and for
other organizations in Germany and the US. The training classes I
most like to do are on-site at the client -- with very few people,
but highly efficient. Such classes are customized for the client's
For forms projects, it depends a lot on the circumstances. There
is no "typical" project. One thing they have in common -- I provide
the "engine". I don't care that much about the actual design of the form.
That is something the client has to provide. Of course, if the client
needs it, I will also design the forms. Besides that, it becomes more
and more an issue to provide forms workflow solutions, or to provide
general help with forms management. This is not such an issue in the
US, but in Europe, there is not much of a formalized forms management
In all of that, the practical mindset of the Engineer is involved:
There is a problem, and I provide a solution. With PDF, it's pretty
much "If you can imagine it, you can do it."
In all this work, I get good support from my partner, Makiko.
Although she is currently working on her own projects (such as
did write a few articles for Planet PDF
together, and there will be more to come.
Having a background as a graphic artist, Makiko is doing the
"arts" part of the work. She designed the PRODOK Web site, as well as the PRODOK CI.
PP: Forms have been a part of Acrobat -- to some degree -- for several generations of the product now. What have been some of the changes, for better or worse, and also, what has been the impact on forms creators and users?
MAX: Indeed, there have been several generations. We are actually in the fourth, and the fifth one is in the works. The steps from one
generation to the next have been tremendous. The biggest step was
most certainly from the first to the second generation, with the
beyond other fillable documents, and opened a whole wide field of
engine got a complete overhaul. I had my real 'Wow!!' experience the
first time I saw the above-mentioned Pulley Designer running under
Acrobat 4. Before, a change initiated via buttons, such as changing
the number of grooves, took some 40 seconds. With Acrobat 4, it was a
matter of 3 to 4 seconds -- on the same machine.
Of the following generation change I remember when I finally got my
There have been lowlights as well, and Adobe knows about them.
Messing up something just because another implementation one wants to
copy is even more flawed is definitely not a good idea (I am talking
of the check box/radio button flaw introduced with Acrobat 5). And
the Business Tools disaster is neither forgotten nor forgiven.
Anyway, the impact of the PDF form to the forms industry is a great
one. It is the very first time, the same base can be used for print
and for electronic forms, leading to considerable cost savings. This
allows, for example to no longer print big stocks of forms one barely
ever uses, but to go to a Print-on-Demand solution, or even make them
available as electronic (PDF) forms, and have the user print
them out. It is not even necessary that these forms are fillable.
This is the very first stage.
The next stage is, of course, the possibility for fillable forms,
which takes care of handwriting and other readability issues. To get
back those forms filled out with readable writing increases the data
quality, and reduces the number of getting back to the sender. And
considering that a simple question back to the sender easily costs 30
US dollars, you can see the immediate cost savings.
When it comes to smart forms, you have another round of data quality
improvement, because you can build rules which the entries must
comply to. You also can make sure that additions are performed
correctly. You don't even need to make sure that the entered values
make sense, but you make sure that "the garbage is consistent".
The PDF form is also very well-suited for building up workflows, or
for electronifying existing workflows. As the PDF form is essentially
a document, you can stay with the same concepts as before, and it
will be much easier to implement such workflows. You can make your
users getting used to work on-screen, and there is a smaller step to
fully electronic workflows, where only data is transferred (if that
is something worthwhile to achieve).
This nearness to documents has also a great effect on the forms
creation level. Keep in mind that a great amount of companies do not
have a formal forms management department, but throw the forms at
their graphic arts department. The actual creation workflow of the
PDF form is very much similar to any other (print) document, and so
you are in the same way of thinking for those people. There is no
urgent need to invest in expensive new tools (although a good forms
design tool pays off within a pretty short time).
Another great advantage of the PDF form is that many elementary
functions do not need to be specifically programmed, but are
implicitly contained in the form itself. I am talking here of the
position and appearance of the fields, some elementary formatting, as
well as a well structured event processing model. However, it is just
this event processing sequence which sometimes causes most problems
for the forms creator.
PP: In addition to giving presentations at many leading industry
conferences, you travel a lot from Switzerland as a business
consultant on forms projects and issues. Can you describe a fairly
typical forms consulting project -- what sorts of applications, what
kinds of companies, what kinds of issues and challenges?
MAX: As there is no typical form, there is no typical forms consulting
project. There are a few things which many have in common, however,
and that is for example that they are trying to get ready for an
eventual fully electronic workflow. And their very first step is to
increase the data quality, in order to reduce costs.
Increasing the data quality is something which can be relatively
easily achieved. Visually improving the form helps a lot, and having
it fillable will also allow for more readable entries. And then we
can add validations and formatting which again makes a cleaner
result. And if there are actual calculations, add them too, and we
have a relatively intelligent form which helps saving costs quite a
bit. Another advantage of the electronic form is that we are a bit
more flexible with the actual dimensions of the document. We are no
longer that much restricted by the paper sizes, which means that we
do not need to cram that much stuff on one single page. It is also
possible to put explanations in a help level which is revealed when
needed, and with that free up considerable real estate on the form.
At the end, this should lead to clearer, visually more appealing
forms. And if a form is clearer, it is inherently less error-prone.
That's on the single-form level, and with according training, this
can be extended to a whole series of forms. Helping the client to set
up the standards for their forms is one of my tasks as a consultant.
In the same direction is the need to more efficiently distribute
forms, which means that there is a need for a forms server. Now, most
clients do have some kind of accounting system where they do really or
virtually charge for the use of the form. One of the important points
here is personalization and security. And finding the suitable
concepts and tools is my contribution. One example from the current
work is a government organization which is responsible for forms used
by the various towns. The forms are standardized, but the final forms
should look as if they were issued by the individual town. So, I helped them
set up a forms server that merges variable data into the base
form to personalize the forms for the towns. For this, we are using
the server-side tools by Appligent (FDFMerge, AppendPDF, and SecurSign). And this forms server is pretty tightly integrated into
the client's e-Shop system (OpaccOne by Opacc). This keeps us the door open for directly attaching services to the form, and to charge for these services on a transaction-based level. Which also leaves space open for very interesting business-model concepts for the new Acrobat products.
The challenge with such projects is to get the full support by the
client. As forms are images of business processes, we get into the
fields of many departments, and getting them behind this is sometimes
a serious challenge. As such projects sound more complicated than
they are, there is very often some friction with the IT departments.
This can also be because the driving force comes from outside.
At least in Europe, there is not yet a common e-Forms culture, so
that everybody is trying to find their way. This makes my consulting
work interesting and mostly gratifying.
PP: Let's wrap up this segment of the interview by returning briefly to the newly released Acrobat products, in particular Reader 5.1. I recall that you were also at the private "tech demo" at the Seybold PDF Conference in New York early this year where a small group of us had a chance to get an early peek at some of the features now available in what's being released. As it's now public, we're interested in your general impressions and thoughts about the enhancements, and in particular about this notion of embedded document rights in PDF files.
The important point with this new concept is that it is not anymore the end user who has to provide the tools for the rights, but the provider of the document (form) applies these rights to the document. This is what I understand to be the correct way; the end user should not be made responsible that they can use the document. Of course, it is now the issuer of the document (form) who has to pay quite a bit of money for the right to apply the rights.
This brings me to the crucial part of this new concept. I don't see any serious technical problems. The serious issues are the pricing models for the right (ability) to apply the document rights. If Adobe does it right, this new concept becomes a big success. If they mess up -- for example by pricing themselves out of the market, or by a lack of mental flexibility when dealing with customers -- it will be a failure. The key to success is in Adobe's hands, and they can not make the "bad, non-understanding market" responsible for a failure. They must come out very soon with a solution for small-scale publishers, as the current system is aimed at large organizations. And they must come out with a "development and testing" licensing model, preferably similar to Oracle with their concept for 9i, where the licence for developing and prototypes is essentially free, but it is strictly 'verboten' to use it productively.
Another issue is definitely how this new concept is communicated. Simply saying "Now the Reader can save" is plain wrong. Because it is no longer the application (Reader, Approval, full version) that determines what one can do with the document, but it is the provider of the document who decides what can be done with it. This is a completely different approach, and it may be difficult to convey this message.