aspose file tools*
The moose likes Other Languages and the fly likes Am I on the right Track? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Languages » Other Languages
Bookmark "Am I on the right Track?" Watch "Am I on the right Track?" New topic
Author

Am I on the right Track?

Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Peeps!

I'm trying to wrap my head around a problem. We have a program that merges 'templated' PDFs with any number of variable fields. We have the merging down fine. There are any number of libraries, like pdflib or bigfaceless, for that.

We have the specification of the variable fields down. It's the work of a few hours to create a set of database tables that lets you pump out dynamic forms.

The thing we're having some trouble with is trying to figure out the best way to "specify" how those variable fields are to be used in the creation of the 'merged' PDF.

example form:

1: First Name
2: Last Name
3: Title (Option of 'President' or 'Vice-President')

Once a user enters their data into our 3 fields, we need to 'merge' it with the template.

At it's very basic basic level, we can write code that looks for the specification of the X/Y coordinate of each field, and use that to tell our PDF merging code "how to" do that merging. So that's what, two fields of information per variable field.

But then we need to somehow specify to tell the system "concatenate the first two fields together on one line". So then we add a 'field' to the specification that say "just concat this field with the previous one, and ignore my X/Y coordinate."

Then as soon as we have that, the "option" field isn't about doing a direct replacement of the selected value, but rather a different value 'looked up' from the selected value. So there needs to be a way to specify that behaviour.

Moving away from a simple three field example, we get more complex, and we need to have post-fixes, pre-fixes, newlines, font style, colour, change font, etc, etc.

We even need to use a single variable field in more than one merged location.

And one of the more recent things was "why doesn't the text seem to 'flow'" and "how do we do things like 'put the title behind the first name, except if they have a last name, in which case, put it on the line below'".



So you might imagine, that in the "specification" of this functionality, the number of meaning of fields becomes exceedingly complex.

Correct me if I'm wrong, but isn't this a job for scripting?

Instead of creating a set of fields that "spec" what to do, with "*" meaning concatenate and "**" meaning concatenate if empty, etc, etc. You'd just deliver a "context" of all possible fields to a 'script', that would then dynamically, at runtime, execute, and come up with the text in the format and positioning and concatenation and new-linedness that we need.

Then, instead of having to say "well, our system doesn't support two blank lines between entries, we'll have to break open the code that processes things and support a new 'thing'" we can just say "yah, we can do anything, because it's all scripted dynamically, we'll just change the script".

Am I barking up the wrong tree?
M Beck
Ranch Hand

Joined: Jan 14, 2005
Posts: 323
sounds to me like you're on the right track. seems like what you want to do is associate a list of fields with a list of string manipulation and concatenation options, and then associate the result of those with coordinates on a page for merging into the PDF, and you want sufficient flexibility for relatively advanced string manipulation in the former step.

i suppose it's possible that a non-executable, Turing-incomplete, domain specific language could do the job for you without necessarily needing to be interpreted. but i don't know of any good such language off the shelf, so you might have to invent a new one if you wanted to go down that road. at that point, it'd probably be easier to just go looking for a general-purpose scripting language with good string manipulation facilities and deliberately ignore most of its power.

if i were you i'd look at Ruby, Python, Jython, and maybe Icon or some latter-day Snobol derivative and see how they stacked up. i've been told the last pair have good string handling, but i've never actually seen either one, unfortunately. i'd probably avoid Perl, though.
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

My pseudo-pseudocode looks something like:



Map varParams = all the variable fields.
varParams.putsomeothertoolsin() (dateformatters? currencyformatters?)
scripts[] = an array of Strings, containing the scripts for each 'content area' of the PDF.
for each contentArea {
String foo = scriptingContext.execute(scripts[i], varParams);
now merge foo into the PDF, and the correct startting co-ordinates
}

(I told you it was pseudo-pseudocode).

So it's that "scriptingContext.execute(scripts[i], varParams)" that is the "power" of the whole she-bang.

That's not completely off the beaten path? Is this what they mean by "embedd your jpython/jython/jruby/jfoobar script in java and achieve power and glory" ?


And oh yes, I'll be avoiding Perl like no-ones business.
 
jQuery in Action, 2nd edition
 
subject: Am I on the right Track?