Feature Request

Aug 28, 2014 at 12:37 PM
Edited Aug 28, 2014 at 3:15 PM
The 32-bit version works great using Windows 7 (64 bit), Acrobat 7 (32 bit, obviously), and Office/Excel 2010 (32 bit). And you can't beat eether the price or the ease of use!

For best results, make sure the field to be used as a filename is a text field, not a formatted numeric formula. The excel sheet will display your entry as formatted but your filenames will not necessarily generate that way.

Combining the resulting files? Combine them as a portfolio, not a binder, or identical field names will, as expected, all contain the same value.

Feature Request: Export the PDF's field names.
Aug 28, 2014 at 1:56 PM
Export the PDF field names to where?
Aug 28, 2014 at 2:12 PM
To anywhere. A text file. A new excel file. Whatever's easiest.

Steven B. VanSlyck
Attorney at Law
6253 Riverside Drive, Suite 205
Dublin, Ohio 43017
Desk: 614 389 6510 x103
Cell: 614 403 7053
On 8/28/2014 8:56 AM, TigerC10 wrote:

From: TigerC10

Export the PDF field names to where?

Aug 28, 2014 at 5:09 PM
We have a feature request for flattening the output PDFs and combining them into a single file. I haven't owned a windows computer in about 5 years so I haven't gotten around to adding these features in.

I don't know that exporting the field names would help - a lot of times if you're downloading tax/legal forms from 3rd parties, the fields either don't have names or they are named poorly. Having a text file like:
Doesn't really help you figure out what columns need to be named. However, I think you should be able to view the field names in Adobe Reader X. As it stands, I would rather make a field mapping solution where the column names of the spreadsheet don't have to match the fields on the PDF. That way, you could just point fields to each other. Though, the interface for this is somewhat trixy.
Aug 28, 2014 at 8:51 PM
Tiger, I create my own forms and had had some with over 50 fields. I used another product (I forget the name, which is how I came across yours) to do the merge before. It had a feature to export the field names and it would have been a super, major headache
to go to the PDF, select a field, read or copy the name, and then type or paste it into my spreadsheet... and to that 50-some times. I did that yesterday, but that form only had 12 fields, so it wasn't so bad. But typing them in one by one isn't very much
fun. I like, if possible, for the computer to do the heavy lifting, hence the reason for the request.
Aug 29, 2014 at 2:41 AM
Well, what I'm suggesting as an alternative is to have a field mapper in the app rather than export the fields.

With a field mapper, you'd get something like:
input_field[02] -> Excel Column 1
input_field[12] -> Excel Column 10
input_field[23] -> Excel Column 8
So the PDF field would be listed on the left and then a dropdown would be on the right with the name of your excel column. Something like that makes sense to me. If I'm going to add functionality to make it easier for you to put your columns in place - why don't I just do it in the app instead of export a file that makes you edit your other file?
Aug 29, 2014 at 2:48 AM

I suppose both solutions would work, but for me I don't edit the other file. I create the PDF and then after doing that I create the Excel spreadsheet with the data that I need to import.

And you are right, the field names in the PDFs I have come across are generally ghastly. When I do start with a fillable PDF, I off and erase all of those fields and create my own, with relevant, meaningful names.

At that point, however, there is no existing Excel spreadsheet. So I have to use the field names that are in the PDF.

Ematic solution would work but wouldn't save me the time I would have to spend a naming the first row.

Ultimately, it is your app. You have to make the call on what works best within the context you are designing it for

Aug 29, 2014 at 4:40 AM
Yeah, I don't know what happened last week but suddenly I got a bunch of requests for support with this app. I wrote it years ago, and it's still got a lot of traction. I've been considering rewriting it in Java because I don't have a Windows computer anymore and all these feature requests are pretty much on hold because it's a Windows app. Plus, the integration points with Microsoft's .NET framework are super fragile and a lot of times the app fails because of a lack of proper configuration/setup in the workstation machine running the app. Things to consider, I guess.