Max Wyss takes Acrobat PDF Forms to the max
But Adobe's release of Reader 5.1 is 'killing my best punchline'

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 printing-oriented applications.

Prevailing practice aside, the potential for PDF as an optimal format for electronic forms inspired Max to explore the possibilities. Max WyssAnd 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 Forum.

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.

To Top

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

To Top

PP: That's especially catchy with the German accent, Max! So here's a challenge: let's see if you can quack and walk backwards -- in time. Let's do a little PDF time travel. Adobe's focus with Acrobat versions 3 and 4 was primarily the product's prepress applications; then with Acrobat 5 came a shift to emphasize some of the enterprise- and corporate-driven features and capabilities. While the PDF Forms capabilities were introduced (in a limited way) in v3, it wasn't until much more recently that Adobe seemed to view the importance of forms on par with prepress and printing uses. Tell us how it was that you decided to focus so early on Acrobat/PDF Forms and Forms with JavaScript as an area of specialty -- when and why did you take the leap where few had seriously ventured?

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

So, we needed another approach, and in the meantime, Acrobat 3 came out with the forms functionality, and the forms data format (FDF). Acrobat 3.0 screen 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 appropriate pulley.

Max Wyss Baer Timing Belt

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

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 to JavaScript. As I did not find anything in the documentation for 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 introduction of JavaScript. Now, knowing a little bit about JavaScript, it was clear this would allow me to fulfill my client's 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.

To Top

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.

To Top

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

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 needs, and they are mainly on Advanced PDF forms and Acrobat JavaScript.

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

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 writing books; her latest -- "JavaScript + CSS + DOM Magic," by New Riders -- came out in May), she is a good resource. When it comes to writing articles, she is the one who 'flattens' out my accent. We 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.

To Top

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 introduction of Acrobat JavaScript. This measure brought the PDF form beyond other fillable documents, and opened a whole wide field of applications.

I remember the next generation change as well, where the JavaScript 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 hands on the Acrobat JavaScript Object Specification. It read like a suspense novel.

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.

Classifications of PDF E-Forms

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.

To Top

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.

To Top

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.

PDF Document Rights

MAX: Reader 5.1 is just a necessary component in the whole system. It is actually the component to be distributed to the public, and the public does not really notice much. For the public, it is still "just Acrobat Reader". And it will take quite a bit of time until people actually start to get forms which do bear those rights in themselves.

Reader 5.1 Document Rights Info

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.

To Top

PP: In your Seybold NYC presentation on "Efficient E-Forms" you talked about the various classifications of PDF-based forms. Do you expect the release of Reader 5.1 and the other server-based products to accelerate a larger number of users further down on your Phase 1 to Phase 4 scale? What else will it take to move more of them to the third and fourth-levels?

MAX: As I said before, the crucial point is Adobe's pricing model -- cost of the system -- for the right to assign the rights. Based on these new products, this right is pretty expensive right now. If an organization decides it wants to get into the business of assigning document rights, they have to be aware that this is only the first part of the investment. They have to look at the forms and the associated workflows. So, again, don't expect too much immediately. But long-term, it will bring more and more forms to become at least level 2, if not 3. For level 4, there is much more required, such as the digital signature infrastructure, and definitely a workflow system. The tools are already available, or become so within the next year. But the price for a complete system will require a complete extended budgeting and approval process in big organizations. And they definitely will need independent consultants to get them up-to-date.

PP: Thanks, Max! I'm sure you could provide them with a name or two. On that note, how about we let you stop quacking for a bit and we'll resume this enlightening discussion in Part 2.

[CONTINUED: : In Part 2 we take a closer look at a few of Max's PDF forms masterpieces, some basic forms and Acrobat JavaScript tips and more.]


To Top

PDF In-Depth Free Product Trials Ubiquitous PDF

Debenu Aerialist

The ultimate plug-in for Adobe Acrobat. Advanced splitting, merging, stamping, bookmarking, and link...

Download free demo

Debenu PDF Tools Pro

It's simple to use and will let you preview and edit PDF files, it's a Windows application that makes...

Download free demo

Five visions of a PDF Day

In the world of PDFs or as we like to say Planet (of) PDF, a year isn't a real PDF year without an intense few days of industry knowledge sharing.

May 15, 2018
Platinum Sponsor

Search Planet PDF
more searching options...
Planet PDF Newsletter
Most Popular Articles
Featured Product

Debenu PDF Aerialist

The ultimate plug-in for Adobe Acrobat. Advanced splitting, merging, stamping, bookmarking, and link control. Take Acrobat to the next level.


Adding a PDF Stamp Comment

OK, so you want to stamp your document. Maybe you need to give reviewers some advice about the document's status or sensitivity. This tip from author Ted Padova demonstrates how to add stamps with the Stamp Tool along with related comments.