Creator, Publisher, ModDate, Createdate

Hi
I was wondering if anyone knows whether it's possible to "Set" (or actually clear in my case) these values before saving a PDF file.

I seem to be able to set them just fine, but when I save the PDF, QuickPDF puts it's own name in as the Creator and producer, and puts today's date in for the Mod and Create dates, which I need it not to do.

Any ideas.

Thanks
Darin

Hmm, well, when I do essentially that same bit of code, I end up with

<<
/Producer (iSEDQuickPDF 5.21 \(www.sedtech.com\))
/Creator (iSEDQuickPDF 5.21 \(www.sedtech.com\))
/CreationDate (D:20070201153335+06'00')
/ModDate (D:20070201153335+06'00')
>>

stuck into the PDF (I pulled it out using a hex editor)


My test is putting BLAH in for all these fields

for instance....
rQPDF.SetCustomInformation "CreationDate", "BLAH"
rQPDF.SetCustomInformation "ModDate", "BLAH"
rQPDF.SetInformation 5, "BLAH"
rQPDF.SetInformation 6, "BLAH"

Eveything else is the same as your snippet.

Sure looks like ISED is forcing those fields no matter what you set them to.

Note that I don't get any errors, all success return codes, it's just that the final file doesn't contain what I set the props to.

Odd.

Darin

Could be....

I am using 5.21.0.1 I downloaded from this fanclub site.

Maybe there's something slightly amiss with the new build?

Darin

I'll put together a small test app like you have and give it a whirl

I'm using the ActiveX version of 5.21.0.1 downloaded from this fan club site. I don't have the source code, although I'm considering getting that version.

I noticed there are 2 interfaces in the dll that seem almost if not identical, ised.quickpdf, and ised.quickpdf2

Initially, i was using the quickpdf2 interface, but ran into several odd issues. Switching to the quickpdf interface fixed that.

About the MODDATE item, While I understand that normally, that's exactly the behavior you'd want, in this particular case, I actually do need to force the mod date to what I set it to. Maybe it's some fixed date (like 1900-01-01). This is because I'm looking to remove any metadata from the doc that might reflect it's history.

Besides, I'd almost argue it's a bug that you can set the moddate but that it doesn't stick on save. If the programmer doesn't set it, the lib should update it on save, if it does get set, that value should be honored, I'd think (or raise an error at the point that it gets set saying something like "This is a read only property".

Just my 2c. Overall, this seems like a pretty solid lib and the value is definitely good. I may just have to live with this one issue, assuming I can get the Producer etc to work right.

Thanks for trying it though. I'll have a go.

Darin

Ah, well, now if it's really required, that'd change things a bit. I've only just begun to work through the adobe pdf spec so I'm definitely no expert on that.

Maybe the setinfo just needs to apply some validation to make sure that the date you set in is a valid date according to the spec, and not just any old value? As long as the field was really a date, I'd guess the dictionary stuff would be ok, but that's just a guess.

Thanks for the response. I'm setting up a VB test proj now.

Darin

I apologize if I haven't submitted this issue properly. I'm not really even sure it's a "bug" yet (although I suspect the issue with the MODDATE "might" be considered one, but then it might not also).

Once I get a little test app going to make sure I'm seeing what I think I'm seeing, I'd be happy to zip the whole thing up and send it to the support email address.

I'm certainly not trying to go behind anyone's back here. I'd love to help any way I can.

Thanks
Darin

Hi All
First, a HUGE thank you to everyone that threw in on this issue. I really appreciate it.

I built up a small little test app, tried it and you guys were right, everything got cleaned except the moddate.

Ok. So I started trying to narrow down what was different in my main app vs the test.

In the end, it turned out that I had forgotten about the second pass of my program.

In the first pass, everything worked fine, but in the second pass, I had a conditional that caused the LoadFromFile to get skipped.

So, of course, the end result was that I was saving a file that had never been loaded.

So then, I thought it was odd that even with that being the case, that the Producer, etc fields were being reset to the ISED text.

So I kept digging, and realized that if there is not metadata in the field (for instance if I call GetInformation(5) and get back a blank), I don't even bother calling SETINFORMATION on that field.

And THAT appears to be the rub. If you call GETINFORMATION when no file has been loaded, you'll get back a blank string, but if you save the file WITHOUT calling SETINFORMATION, the file ends up with the ISED creator/producer names.


So in summary, I don't believe there's really any probs with iSed, other than the setting of the MODDATE. One might argue that if you call getinformation, and then save the pdf, whatever was returned by getinfo should get saved, but nobody would intentionally use the library like that, so I'm not concerned about that issue.


About the MODDATE issue, what is the proper way to submit an issue like that? Should I email it to support@quickpdf.org?

Again, I'm not sure it's really a bug per se, but it does seem like it's not operating as intuitively as it seems it should.


Thanks again for everyone's help with this

Darin

Hi Darin!

Only an idea...
If you want to remove/reset the ModDate why not creating a new empty pdf-document... then you can copy the pages from the older one into this new document with a new ModDate and the old content ;-)

Best regards and good luck!
Ingo

Darin, inside the source code (class TiSEDQuickPDF) there is a call to

Hi Darin,  

Hi Ingo,
You know, I've used that trick before, and I completely missed it this time round.

Good point!

I'll do some experimenting and see how it goes.

Thanks for the heads up!

Darin