Support for Complex Objects?

[Albert-IV]

This is actually pretty useful if you want to handle PDF's through node.js servers. Ever thought about supporting complex objects? Right now if you want to support dot notation you need to do something like this:

var dataObj = {};

dataObj['user.name'] = 'Bob';
dataObj['user.signature'] = 'CEO';

var fdfContents = fdf.generate(dataObj);

And if you attempt to do anything fancier than a single level deep object it dies:

var dataObj = {};

dataObj.user.name = 'Bob';
dataObj.user.signature = 'CEO';

var fdfContents = fdf.generate(dataObj);
//  ^ Dies

I bet you could do some fancy recursive functions and create a path variable that displays an object's dot notation path. Set up an identical object of one that was passed into the .generate(), and you could use that object when you input the name into the .fdf file contents.

Thoughts?

[countable]

Hm, I didn't realize PDF supported a nested structure of fields like this, and not sure how that would work in the actual PDF file. But if so, a patch would be welcome :)

[Albert-IV]

I'm using it to dynamically populate template PDF's, right now that functionality works. I set the field in the PDF to being rep.name and pass in {'rep.name': 'value'} to .generate() and it populates correctly on my end.

I'll work on a patch over the weekend, I have looked at your code before and it looks pretty easy to decipher. Biggest issue is I'm not 100% sure how to go over each object element and create a name for it. I don't think they have a native way to get the path of a variable, only way I could see it is to create an object and populate it by tag names. If it's typeof 'object' then create another object for that element name, otherwise set the tag value maybe...

I'm pretty sure I can do this, I'll let you know when I have a patch ready.

[Albert-IV]

Side note: I finally got around to messing with this feature. I think I have a working method going, I just want to do some more extensive testing to ensure it works as expected.

Do you want me to move that section of code to a separate git repo with extensive testing, or do you want me to implement a testing library like Mocha for this project?

[countable]

hi Albert; The lib I wrote is extremely tiny so maybe you want to do a fork in order to be the owner since you've put more work in. In that version you should change the npm project ID in package.json to something other than js-fdf or it won't work. If you don't want to do that, just make a pull request. Tests are certainly welcome. Again, because it was a tiny one-off thing I don't have any test standards but you're welcome to suggest these too under a "contributing" section in README.Md

[Albert-IV]

Hmm, ok. I think I'm going to move this object flattening method into its own repo with a few tests.

I think we have a couple options in front of us. We could update js-fdf to flatten the object using the other library and generate the FDF data, or I could fork js-fdf and integrate the two myself.

It's really up to you. If you don't want to worry about maintaining this, I have no problem taking over. We use this library extensively where I work; it would be nice to add some options to the API and possibly integrate merging PDF's inside the library itself (right now we do that all on our side).

[countable]

You should be the maintainer then :) I put this up for a project at the time and probably won't touch it again.

[Albert-IV]

Great that works for me. I do have one question for you, I ask this because I'm not sure if this is a bug or not.

Say we have an array of ['a', 'b', 'c']. Now the checks for arrays work, reading through it, it seems we would have this as the FDF body:

<<
/V(["a","b","c"])
/T[("a")("b")("c")]
>>

Is there a valid use-case for this format of FDF file? Judging by this link I hastily Googled there isn't any fields that accepts arrays.

Do you remember if there was a specific reason to do this? Just wondering if I should remove that portion of the code when I fork for-real.

[countable]

I can't remember why I did that. The proprietary spec is garbage and doesn't tell us anything about this: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/fdf_data_exchange.pdf

I suspect you're right and it would generate an invalid line.

[Albert-IV]

I've updated my fork to flatten objects using the flattening technique I wrote. I also removed the MD5 dependency and array code. Thanks for all your help!

[countable]

Thanks for fixing up the lib!