Limitations

Nobody likes to reinvent the wheel. Wait a minute - some people do. I don't. If there is a viable commercial package which is produced by a vendor who is willing to provide the source code, I use that where it makes sense. The servlet utilities don't handle a large number of PDF tasks very well because these tasks are well covered by existing products. For one thing, the utilities can't be used to parse an existing PDF file (see the PJ package from Etymon if you need to do that). Another thing these utilities don't provide a lot of help for are green-bar style reports (see the Delta package from Root River if you need to do that).

There are other Open Source packages which can be used to generate graphics in a web application (such as the GD Chart package), but these produce their output as GIF or JPEG - which is both larger and less usable than PDF for many applications.

For interactive, non-web creation of PDF files, there's Adobe Acrobat.

Even with the existence of these fine tools - and many others - there is still a need for the servlet utilities; but because of their existence, the servlet utilities have designed limitations to prevent excessive overlap. The utilities can make the difference between getting a job done right, or just getting something working.

My hope is that you'll find that the servlet utilities are versatile and get the job done right by limiting the scope to the problem at hand instead of trying engage too many disparate uses.

Contents

Introduction

Limitations

Previous: Why the servlet utilities exist | Next: How the servlet utilities came to be