call pdf.setDocInfo pdf.kdiCreationDate, strmyDate
doesn’t work :-(. I didn’t find anything related in the examples. And as I’m working with an in-memory web file, I see the only option in changing in the pdf.
You should not need to set it.
But I think it used to work if you set it before closing.
Don’t tell me. “Strange” customer, who wants the pdf of a report from the first quarter 2020 having the date of March 31st … Why? I really don’t know but I’ve reached an age of not asking too many questions any longer ;-).
Thank you, I’ll try!.
Nope, unfortunately not, raising an exception as well:
SetDocInfo: Enum constant is not defined!
But where are you looking?
The PDF document contains properties
CreationDate
ModDate
and this is what SHOULD be getting set by the call.
A PDF document is essentially a text file at heart.
In one I have here, looking at the CreationDate , I see this:
<</Author(Elaine) /CreationDate(D:20200913221333+01’00’) /ModDate(D:20200913221333+01’00’) >>
But at an operating system level, a file you create has a creation date of its own, whether it is a PDF or not.
It’s possible to have a PDF file created on the 1st November, containing an internal property saying CreationDate of 19 August 2019
1 Like
@Jeff_Tullin , yes I only want to change it in the pdf. But just to avoid any confusion, I’m using DynaPDFMBS not the Xojo Plugin.
I think you are talking about Xojo native Pdf? Good to know it is working in Xojo.
Thinking about it, I see customers (not my particular one but others) might have use for this, for instance when using a Document Management System, reading the pdf meta data …
Maybe use SetDocInfoEx?
I looked at that one, but struggled with the right parameters to use, but I will give it one more try.
No, Im not.
I just opened a PDF file and looked at the first few lines of text which it contained.
Digging into the DYNAPDF docs, I found this note:
diCreationDate = 10, // Available after a PDF file was imported
I tested setting it during creation, and it was ignored.
eg call pdf.SetDocInfo pdf.kdiCreationDate, “01 JAN 2018”
(that may be the wrong format - it doesnt expect a date object…)
So based on the DynaPDF docs, you would need to create the file on disc, then import it, amend it, and resave it.
And if that fails,
you might try reading the whole PDF as a text stream, locating
/CreationDate(D:20201107131729Z)/ModDate
changing that portion of text, then resaving.
Edit:
SetDocInfo: Enum constant is not defined!
Its defined for me. It has a value of 10
1 Like
So this is working:
call pdf.SetDocInfoEx pdf.kdiCreationDate, "", "D:20150418131854Z12'34'"
But! It will change as well the timestamps on macOS to the “default” macOS file date:
Within the pdf it looks fine:
Lucky you, enum exception for me :-(. Latest official MBS release. Replacing the constant by 10 doesn’t help, seems to be inside the method.
Having written a file to disk and closed it, I then do:
Var atFile As FolderItem, moddate as Double, newdate as DateTime
newdate = new DateTime (moddate)
atFile.ModificationDateTime = newdate
Where moddate is a SecondsSince1970 value and which works without issue. Same for the CreationDateTime, but don’t try that one under Linux as it doesn’t work.
1 Like
@TimStreater
Thank you very much, but as I initially wrote “And as I’m working with an in-memory web file” … my issue is a bit different.
I’m creating many web files in memory and store them in an array. Then I’m looping over this array and create a zip file (again in memory) on a linux server. This zip file can then be downloaded by the user in the browser.
So my only control is changing the date in the meta data of Christian’s plugin.
That works indeed with the following line.
call pdf.SetDocInfoEx pdf.kdiCreationDate, "", "D:20150418131854Z12'34'
But as shown above when the file is downloaded the created and modified date on the OS is set to the “default” values, which means the first possible date for files (1980… for macOS, 1899 for Windows, etc.). So that’s not an option either ;-).
It would be enough to get the created date changed in the metadata of the pdf and I think that’s a realistic requirement but without touching any timestamps on the OS. “CreatedDate” is for me just like the author, or keywords etc. You should be able to change it with one line of code.
So you’re trying to set the modification date of each individual file, not the modification date of the zip that gets written to disk?
Yes, but it’s an internal property of the document (like ‘Author’) , rather than the creation date of the file when it is actually saved.
2 Likes
Jeff is right, you usually find it under properties of the pdfReader of your choice. This for instance is Adobe Acrobat:
“Erstellt am” is the creation date. And with code above, I can get that changed, but it is changing as well the OS creation timestamp to the stupid default values. On desktop, I would just change those dates back with your method but on a webApp I have no control on the file any longer.
WebFile doesn’t have many options and none for manipulating dates. So I depend on DynaPdf or it won’t work, which is always an option ;-).
The change to allow setting creation date was made in DynaPDF earlier this year.
So please use current plugins.
As I wrote I’m using the latest release. And it is changing the creation date within the pdf (=good), but it is changing the macOS date to 01.01.1980 as shown above (=bad).
You man you want to use folderItem properties to set back the dates there for the file itself?
No. I’m using web files in Xojo to store DynaPdfFiles (via CreateInMemory). I’m successfully zipping those web files into one web file with your ArchiveMBS Plugin and the user can download that file.
All I’m trying to achieve is changing the creation date within the pdf Properties of each pdf. This works indeed fine with
call pdf.SetDocInfoEx pdf.kdiCreationDate, "", "D:20150418131854Z12'34'
But at least in my scenario above, it apparently changes as well the creation date of the “physical file” in the zip. As shown above that date of each modified pdf with the above command shows as if it was created on 19800101. Weird … When I’m changing the CreationDate to something else, i.e "D:20150418131854Z12’34’` this works as well, but the physical file will again have 198001001 as it’s creation date.