On Mon, 2 Apr 2001, Dan Jenkins wrote:
> I'm working on the same problem myself. I have a HUD multipage form which
> needs to be filled in programmatically.
Sounds like something we worked on at my last job. I discovered that the
Right Thing to do when you want to fill out a form programatically is to
programatically generate the form image with the fields already filled in.
Anything else will be a hack, and not a pretty one.
However, "anything else" is almost always what you have to do, since forms
are designed by pencil pushers, not written by programmers.
But I suspect you have already realized all that. I just figured your
misery might appreciate some company. :-)
> (This is what the programmer does by hand. It takes him a week or several
> for each printer. He manually aligns each field's position and fonts by
> handwriting PCL.)
Sounds like you got yourself a "Real Programmer" there. ;-)
(See: http://www.tuxedo.org/~esr/jargon/html/entry/Real-Programmer.html)
> I'm trying to get the original PageMaker 6.5 document from which the PDF
> was generated with Adobe Distiller.
We discovered that getting the source to a government form usually takes
something like an Act of Congress. In some cases, literally.
You also have to go through that pain for every revision of the form.
> Even better would be getting the original author (HUD) to distill it as a
> fillable PDF form.
Now, that would make sense. And we're dealing with the government. I think
Mark Twain said it best: "Now, suppose you were a Congressman. And suppose
you were an idiot. But I repeat myself."
> 2) Parse the PDF.
That would be a truly impressive hack, if you can do it! :-)
> 3) Convert & Edit the Postscript.
This is basically a variation on your #2 option. See my response to your #2
option. :-)
> 4) Programmatic Overlay.
We honestly found this presented the least amount of pain over time.
(1) You take your form in whatever format it is given, and generate some
kind of usable bitmap graphic from it. (The program on this project used a
Microsoft Windows Metafile, 'cause it was a Windoze program.)
(2) You create or borrow a specification language which says where on the
bitmap the fields are to print out. These days, I'm thinking XML. (The
program on this project used something based on Windoze .INI files... same
reason.)
(3) You write a GUI program which throws the bitmap from (1) up on the
screen, and lets you add/edit/remove field specifiers. The end result is a
specification conforming to (2).
(4) You write a program which takes the bitmap from (1), the specification
from (3), and a data set, and outputs the end result for printing.
This creates a flexible, permanent solution. You can adapt to new source
form formats (the input to (1) above) by changing your graphics conversion
filter. You can adapt to revisions of the source form easily using the
program from (3) above.
Yes, this is a lot of work up-front. However, we found the overhead of
maintaining ad-hoc solutions (like the one you are currently stuck with) paid
for the initial development costs over time.
It occurs to me that someone else may already have done this, and released
the source. A 'net search might prove productive.
May the Source be With You! :-)
--
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or |
| organization. All information is provided without warranty of any kind. |
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
