Move PageResources_obj_gpush to end_run

[zauguin]

Currently \__pdf_backend_PageResources_obj_gpush: is called in the lastpage_shipout hook. In LuaTeX this can lead to issues when additional resources are added during the shipout of the last page. Also it makes it different from the otherwise quite similar commands like \@@_Pages_gpush:. I can't see any technical reason why it shouldn't be in \g__kernel_pdfmanagement_end_run_code_tl too, so I suggest making them more consistent.

[u-fischer]

I need to check if I can remember if I had a reason. Do you have an use case where it is too early?

[zauguin]

Do you have an use case where it is too early?

It came up while looking into PSTricks on LuaTeX, in particular interpreting PS commands in Lua. Since they might depend on being able to access the current page positions, they "have to" run during shipout (in something like latelua nodes) but they might generate arbitrary ExtGState modifications which generally could depend on the final page position, so they can't easily be determined beforehand.

[zauguin]

As a more important use-case than some crazy experiments, I'm worried that this might affect transparency in color fonts in luaotfload since there we might end up declaring the transparency levels in virtual font packets too.

[u-fischer]

I will look and probably there is no problem to move it (I assume it is there as it is there in xetex too and normally I try to do the same for all engines). But I wonder if there is a general problem. I mean I use \@kernel@after@shipout@lastpage with the idea that it is the last "shipout code". So why is your code coming after it?

[zauguin]

I mean I use \@kernel@after@shipout@lastpage with the idea that it is the last "shipout code".

It is the last code which runs before the \shipout primitive is invoked, but the problem appears because \latelua/virtual fonts/etc. in LuaTeX run while \shipout is evaluated and therefore later.

[FrankMittelbach]

I mean I use \@kernel@after@shipout@lastpage with the idea that it is the last "shipout code".

It is the last code which runs before the \shipout primitive is invoked, but the problem appears because \latelua/virtual fonts/etc. in LuaTeX run while \shipout is evaluated and therefore later.

Isn't the point that it contains code that need to end up inside the box shipped out but at the very end? I haven't checked where you suggest it should go but I thought it can't be later if it should appear in the pdf.

The assumption is that the result of \@kernel@after@shipout@lastpage is placed inside a box at the very end of the box shipped out. Are you saying that the \latelua adds further material to the pdf (and being executed inside \shipout it ends up in the pdf after the box? If that's the case, then perhaps instead of of going into a box in the pdf \@kernel@after@shipout@lastpage perhaps has to do a \latelua too to ensure that it is even later?

[zauguin]

I haven't checked where you suggest it should go but I thought it can't be later if it should appear in the pdf.

It depends on the engine. For pdfTeX and LuaTeX, objects can be written into the PDF file even after the last shipout, so there it wouldn't be an issue to run this later. For other engines PDF objects need specials and therefore have to come on the last page.

Now \__pdf_backend_PageResources_obj_gpush: is empty on all engines except pdfTeX and LuaTeX so it is always safe to run it later. Additionally the \g__kernel_pdfmanagement_end_run_code_tl already takes this into account: It gets executed after the last shipout if the engine supports writing PDF objects there, otherwise it gets moved into the lastpage hook. So it should always be safe to move this there, even if later versions add something to \__pdf_backend_PageResources_obj_gpush: for other engines.