>> What 'new shiny syscall' shall influence the creation of PDFs, >> specified by international standards? I think this is a straw man >> argument. > > For example a new syscall to get the current time. While > improbable, just look at things like the new statx call, it happens > from time to time that very fundamental interfaces are introduced > and eventually used.
If this unlikely scenario really happens, 'libfaketime' will be updated accordingly, I guess. >> This is what I've started with, see the attached experimental stuff. > > This is not what I had in mind here, that is more towards my > option 2). With "strip" I really mean removing emitted fields from > the generated PDF. Ah, ok, I misunderstood. > The format is very readable, a simple search-and-replace is easily > able to deal with all instances discussed so far. Let's assume that the various time-related fields in output PDFs are fixed. At least problems still remain. (1) The various `essay.pdf` files include, among others, the images `bwv861-breitkopf.png` and `bwv861-gessellschaft.png`. For some unknown reasons yet, this leads to different PDF files. This might be a bug in `xdvipdfmx` (the PDF driver of `xetex`) of TeXLive 2020. (2) `musicxml2ly` doesn't produce reproducible output; see issue #6076. >> ... there is one additional field called `/ID` in (some) PDF output >> files that is apparently a random-based value. I've contacted some >> gs people to get more info on that. > > If you look into the GS code, it is based upon a) the current time > (addressed by libfaketime) and b) the output file name that recent > LilyPond sets to a random string for atomically moving the generated > PDF. Thanks for investigating this! Werner