Update regression-test to support PDF management tools

[josephwright]

Testing in https://github.com/latex3/pdfresources currently needs a customised regression-test. That should be addressed so it's possible to test correctly without a custom version.

[u-fischer]

The pdfmanagement-regressiontest.sty in pdfresources does what I need, only the timing is a bit tricky: As it should change behaviour depending on if the pdfmanagement is there or not it has to be loaded after the testphase package currently.

Side remark: I explicitly avoided to omit all the dates, as I would like to be able to test if one can set them.

[josephwright]

I was thinking we'd want generic switches, so some form of 'do/do not disable INFO'. Would that work? Probably would be

\def\DONOTSETPDFINFO{}
\input regression-test %

where we simply look for the existence of \DONOTSETPDFINFO (or similar). I guess the default would be to set them. Would that work?

[FrankMittelbach]

wouldn't it be possible to load the file first and then have declarations that execute its behavior, e.g

\input regression-test
\DoNotSetPDFInfo

would look more natural to me.

[josephwright]

@FrankMittelbach Yes but then how do we know when to trigger 'set the PDF stuff'?

[FrankMittelbach]

not sure why you think that is different from your approach other than by syntax: your's is a simple detectable switch so you do different actions inside the file based on that. Mine means you set up some default in the file and you change (or activate) when you see \SetPDFInfo. So your's is perhaps slightly more performant at the cost of a somewhat awkward syntax, no?

[u-fischer]

@FrankMittelbach the question is if all relevant settings can be reverted after \input regression-test has done its job and setup defaults. Some of this stuff is not easy to undo, e.g. after \pdfinfo{/Title (title)} is imho not possible to get rid of it again. omitdate shouldn't be a problem, but for the rest one need to check.

[josephwright]

@FrankMittelbach as @u-fischer says, the problem is we can't rely on say \AtBeginDocument (as the test suite is generic), so have to 'commit' to the settings when regression-test is loaded, at least unless we have a major change of approach. We currently standardise PDF data, so if we want to change that by say adding a \FINALISEPDFDATA then it will be a breaking change.

[FrankMittelbach]

it is mainly syntactic sugar (I just don't like seeing that \def I guess). If if is to complicated to undo whatever the default is at the time you see \DontSetPDFInfo then don't bother. My guess was that nothing happens in the file that can't be easily reverted when you see that command but if that is not the case ..

[u-fischer]

\AtBeginDocument wouldn't be good anyway, some of the test will want to override regression-test settings. Imho if we want such switches, they should mostly work after loading the file too, but currently I don't see a pressing need, it is more important to avoid that the primitives are used when the pdfmanagement is there.

[josephwright]

The alternative I guess is to do \ifdefined\<some-marker> but then you have to load pdfmanagement before the regeresion test.

[u-fischer]

but then you have to load pdfmanagement before the regeresion test.

that is fine with me, I already do this in all the tests, if you look at my temporary.sty you see that it basically uses this method.

E.g. \ifdefined\DeclareDocumentMetadata is good for me.

(I just saw that the sty has a glitch, for some reason I don't set the trailer-ID for xetex. I wonder why no test complained about this, perhaps l3build is catching it ...)

[josephwright]

Are we happy filtering on a specific package?

[u-fischer]

why package? we need to check against the existence of the pdfmanagement code. Any command from it would do it.

[josephwright]

@u-fischer i mean that regression-test.tex is format-neutral, but here we are talking about looking for a marker for a specific package. What about any other code wanting the same thing (PDF management), e.g. if OpTeX wanted to use l3build.

[u-fischer]

and what about simply adding the sty I'm currently using to l3build? Then regression-test.tex stays unchanged, and the other variant is available too.

[FrankMittelbach]

why not indeed? We have test2e for the 2e code (not really needed these days but ...) why not regression-test-pdfmgt.tex (or what have you)

[josephwright]

I think we did this :)