Bug 707694

(In reply to Thorsten Engel from comment #0)
 
> Here is my problem: only a dummy date is used in the metadata of the
> InvoiceStream. The length is not set, too.
> 
> It looks for me as if it would need some additional work between line 440
> and 447. I would really like to directly have the size and moddate of the
> XML-File being applied. 
> 
> I think, this is possible in PS, but I lack the skills...

I don't see any way to accomplish the date in PostScript, because the language doesn't have a way to return any useful date relating to a file.

The 'status' operator does return the date and time the file was created, and last referenced, but.....

"This value is interpreted according to the conventions of the
underlying operating system. The only assumption that a program
can make is that larger values indicate later times."

So there's no portable way to turn the value back into a date and time. Even if there were (we would have to add a platform-specific, Ghostscript-specific PostScript extension operator to do so), there's no way (in PostScript) to know what time zone the system is running in. So we couldn't generate a proper PDF Date and Time because we'd need to know the time zone the file date was specified in to create it.

The pdfwrite device gets around this by using gmtime() so that the date and time it generates for the PDF files it produces are always GMT.


You *could* supply the date and time string on the command line, just as (for example) the ZUGFeRD version is done using -sZUGFeRDVersion. A new command line parameter, say -sZUGFeRDDateTime=(D:.....) and then replace the ModDate in the PostScript program (line 446) with:

          /ModDate ZUGFeRDDateTime

Obviously you'd have to format the string to match the PDF requirements for dates.

I do note that the comment states that the date in the metadata here is not thought to be useful, and in fact there's no way that I can see that a conformance checker could tell whether it bears any resemblance to the date and time the original file was created, since that file is simply inserted verbatim into the PDF and obviously loses its creation date in that process. Unless the XML file contains a date and time ?


I believe the length could be added easily enough:

/Length ZUGFeRDXMLFile status {(Failed to get file status!\n)print /status load /ioerror signalerror} {pop pop exch pop} ifelse

where the TODO currently is at line 443.


I don't have any easy way to test these. If you'd like to attach a set of files (input PDF file, ICC profile and an XML file) and a command line to this bug report I could try that out.

Or, of course, you can test the suggestions yourself and report back.

Thinking about this a little further... I don't believe the /Length key is required at all, because the pdfwrite device will manufacture a Length for the stream when it is written to the PDF file. Since the stream may be compressed the /Length has to be the actual length in the PDF file, so there's no reason to add it to the pdfmark.

Which only leaves the Date. I'm inclined to leave that as it is, unless you have a solid reason for wanting to be able to set it.

Created attachment 25531 [details]
My empty pdf (source) for tests

Created attachment 25532 [details]
factur-x testfile

Created attachment 25533 [details]
icc test

Created attachment 25534 [details]
enhanced lib_zugferd.ps

Created attachment 25535 [details]
result of a "goodzugferd.pdf"

Created attachment 25536 [details]
result of "my bad pdf"

Created attachment 25537 [details]
"goodzugferd.pdf"

Dear Ken,

thank you for looking into this so quickly. If you look at the 2 images (for "goodzugferd.pdf" and "my bad pdf") then you can see the result in Acrobat Reader. For sure this will lead to questions by users if length and date is not properly set. Especially accountants are known to be picky...

I added an example of a "goodzugferd.pdf" file as well.

I used your suggestion in the "lib_zugferd.ps". It works well for the date, but not for the /Length (throws an error). I attached the running version with only the date. Let me mention that I tried stuff like "/Length 9999" as well. The visual output in the Acrobat reader did not honor this.

You can test with the downloaded files and the following CLI command (I used a containerized debian).

gs -dNOSAFER -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dPDFA=3 -dPDFACompatibilityPolicy=2 -sColorConversionStrategy=RGB -sZUGFeRDXMLFile=in.xml -sZUGFeRDProfile=sRGB2014.icc -sZUGFeRDDateTime="D:20190121081433+01'00'" -sZUGFeRDVersion=2p1 -sZUGFeRDConformanceLevel=EN16931 -sOutputFile=out.pdf lib_zugferd.ps empty.pdf

Warm regards and thank you for helping!

Thorsten

Created attachment 25538 [details]
modified PostScript program

(In reply to Thorsten Engel from comment #10)

> I added an example of a "goodzugferd.pdf" file as well.

That does actually help, thanks for all of these.

The problem is that the value to be set is not the /Length key of the stream dictionary. What is actually needed is to set a /Size key in the Params Dictionary which is contained within the stream dictionary.

Using your test file I used the attached, modified, zugferd.ps file. This will use 
-sZUGFeRDDateTime if it is specified on the command line, or substitute the old dummy value if it isn't. It additionally uses the PostScript code from comment #1 to set the /Size key in the /Params sub-dictionary.

It wasn't immediately obvious to me how you were looking at these values in Acrobat, but it looks like you're just hovering the mouse over the attached XML file in the list of files in the attachments tab of Acrobat. Doing that here seems to show correct results.

Dear Ken,

*yes*, now the Size is correct. Perfect! I fear, there must be a new small thing around the ModDate. Your code ignores the value from the command-line (my call example), but I don't know why...


WORKING (value from command line):
/ModDate ZUGFeRDDateTime

NOT WORKING (always using the fallback value):
/ModDate ZUGFeRDDateTime where
     {ZUGFeRDDateTime get}
     {(D:20130121081433+01'00')}
     ifelse


You should be able to see this by testing with the given examples. And yes, Acrobat Reader is showing these values "mouse over" and as a list if you horizontally enlarge the attachments view.

Regards,

Thorsten

Created attachment 25539 [details]
Modified again

It's because systemdict isn't on the dictionary stack, I hadn't realised the program doesn't push it. It's easy enough to fix (see attached), just check if it's defined in systemdict (all command line switches are) and use it if it's there.

If this is OK I'll push it to our Git repository.

Dear Ken, now it is working as expected. Thank you for your quick help and I deeply respect your postscript knowledge!

Fixed in commit e63eaac318cfb8bcfe3b6711b2f227a1a5ac39cf