ps2pdf doesn't respect epoch settings
#274
Comments
|
in the pdfresource repo I have a number of pdf-based dvips tests and epoch settings work there. If I remember correctly ghostscript honors explicit settings of CreationDate (one has to recreate the tests if the ghostscript version changes). |
Indeed: I remember we needed this to work ... |
No, the normalized results in % \subsection{Settings for regression tests}
% When doing pdf based regression tests some meta data in the pdf should have
% fixed values to get identical pdf's. We define here the backend dependant
% part. The main command is then in l3pdfmetaRelevant lines in \cs_new_protected:Npn \__pdf_backend_set_regression_data:
{
\sys_gset_rand_seed:n{1000}
\pdfmanagement_add:nnn{Info}{Creator}{(TeX)}
\__kernel_backend_literal:e{!~<</DocumentUUID~(DocumentUUID)>>~setpagedevice}
\__kernel_backend_literal:e{!~<</InstanceUUID~(InstanceUUID)>>~setpagedevice}
\pdfmanagement_add:nnn{Info}{CreationDate}{(D:20010101205959-00'00')}
\pdfmanagement_add:nnn{Info}{ModDate}{(D:20010101205959-00'00')}
\AddToDocumentProperties[document]{creationdate}{D:20010101205959-00'00'}
\AddToDocumentProperties[document]{moddate}{D:20010101205959-00'00'}
\AddToDocumentProperties[hyperref]{pdfmetadate}{D:20010101205959-00'00'}
\AddToDocumentProperties[hyperref]{pdfdate}{D:20010101205959-00'00'}
\AddToDocumentProperties[hyperref]{pdfinstanceid}{uuid:0a57c455-157a-4141-8c19-6237d832fc80}
}You can check, for example
|
That is what I meant: you can force epoch values. If you set the date yourself, then ghostscript will not interfere. That means l3build doesn't have to normalize that (and it would probably disturb my tests if l3build would normalize that away). |
|
My bad. "
Still, average users may expect l3build to provide some clean and auto way to normalize timestamps in ghostscript generated pdfs. I think there'll always be some config or cli options to set a specific epoch, so your working tests won't be disturbed. BTW, I am curious about why ps is not chosen as one of test outputs. |
it never was needed. At the begin all tests were log based and that is in many cases quite enough. The pdf based tests were added because I wanted them for the pdfmanagement and the tagging.
I wouldn't recommend an average user to create pdf-based tests. They fail more often and without good knowledge about PDF it is not trivial to decide if the failure is harmless or not. And the dvips route for pdf based tests is even more special (it took quite some time to set this up and I have only a few tests: it is not really a main target; tagging will imho never work there properly.) |
What @u-fischer said :) The reason to run PDF-based tests is where the information we need to test can't be accessed from the TeX side (so doesn't show in |
|
Well, I found the use of I added this line to $ grep -C 1 -anr 'CreationDate' testfiles-pdf/00-test-2.latexdvips.tpf
testfiles-pdf/00-test-2.latexdvips.tpf-92-<</Producer(GPL Ghostscript 9.55.0)
testfiles-pdf/00-test-2.latexdvips.tpf:93:/CreationDate(D:20160520090000Z00'00')
testfiles-pdf/00-test-2.latexdvips.tpf-94-/ModDate(D:20160520090000Z00'00') |
No idea ;-). I can't test locally l3build to check what it is doing and I can't find the online logs. |
|
Here's an archive of the full |
|
that is not really a simple dvips test. As you are setting a standard it tries to embed a color profile, and this requires special support files as ps2pdf doesn't use kpathsea. Apart from this: the ps-files are (nearly) identical (and contain the correct date). The pdf files are quite different, and the most obvious difference is that you are producing pdf 1.4 while I have 1.5. |
Oh that's the point, thank you! I think overlooked the (auto recovered?) ghostscript error After leaving only 2-%�쏢
3:%%Invocation: path/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.4 ?
4-5 0 obj
--
[9](https://github.com/muzimuzhi/l3build/actions/runs/4242897436/jobs/7374970820#step:6:10)0-<</Producer(GPL Ghostscript 9.55.0)
91:/CreationDate(D:200[10](https://github.com/muzimuzhi/l3build/actions/runs/4242897436/jobs/7374970820#step:6:11)10[12](https://github.com/muzimuzhi/l3build/actions/runs/4242897436/jobs/7374970820#step:6:13)05959-00'00')
92:/ModDate(D:20010101205959-00'00')
93-/Creator(TeX)
I'll open a PR to add check engine BTW the |
|
Found another way to normalize date in gs-generated pdfs, and I think it's better: setting gs option From https://ghostscript.readthedocs.io/en/latest/VectorDevices.html#pdf-file-output-pdfwrite
With this setting, Unfortunately, the three options This explains why setting |
|
Such omit options shouldn't be set by default. I would still like to be able to test if DocumentMetadata eg can change the date. So if a user wants that they should change ps2pdfopts |
|
Is there anything we can actually do here? |
When I was preparing #273 to restore the epoch settings in
dvitopdf()and trying to test against this change, I findps2pdf(or the ultimately called executable Ghostscriptgs) doesn't respect epoch settings.dvitopdf()executesdvipsfollowed byps2pdf. In ps files generated bydvips, timestamp is normalized. While in pdf files generated byps2pdf, Ghostscriptgs(v10.0.0) writes bunch of timestamps and version info in an XML stream and the/Infodictionary. Maybel3buildwants to normalize the whole XML stream or specific XML tags.My branch
epoch-gs-pdfcan be used as a start to check and test. Also see a typical diff in https://github.com/muzimuzhi/l3build/actions/runs/4225365084/jobs/7337547030From a rejected feature request to Ghostscript https://bugs.ghostscript.com/show_bug.cgi?id=696765#c28, Ghostscript didn't plan to change this behavior and there seems to be no easy workaround. One option is to call
gsdirectly and pass it an extra input file which sets normalized pdf metadata, see https://milan.kupcevic.net/ghostscript-ps-pdf/#marks.When the epoch settings were introduced to the predecessor of
dvitopdf(), at the first time, in commit d500981 (Allow for .dvi based workflows, 2016-05-21), there was another chain usingdvipdfmxwhich should respect epoch settings. But then in commit 4c0c61f (Simplify dvitopdf, 2020-03-11) thedvipdfmxchain is removed.The text was updated successfully, but these errors were encountered: