[luatex] New \pdf... primitives

[David Carlisle]

On 17 November 2015 at 08:27, Hans Hagen <pragma at wxs.nl> wrote:
> On 11/17/2015 8:04 AM, Joseph Wright wrote:
>>
>> On 16/11/2015 22:39, Joseph Wright wrote:
>>>
>>> Hello all,
>>>
>>> Setting up some tests to work with the v0.85 code, I notice that the
>>> suggestion in the manual
>>>
>>>    \edef\pdfhorigin{\pdfvariable horigin}
>>>
>>> yields with \show\pdfhorigin
>>>
>>>    \pdf_horigin=\pdf_horigin
>>>
>>> which is accessible using \csname or catcode changes. That seems odd
>>> based on the fact this change has been made at all: is this a passing
>>> bug?
>>>
>>> Joseph
>>>
>>
>> Related to this, I wonder if \pdfvariable should be (effectively)
>> \protected. Normally one would expect primitives to either fully expand
>> to a result or to act like \protected macros. Here, we have an
>> intermediate case as \pdfvariable does expand but only as far as an
>> internal token.
>
>
> you can wrap it like you want:
>
> \protected\def\pdfhorigin{\pdfvariable horigin}
>

That isn't what Joseph meant, he meant to change the behaviour of \pdfvariable
which is rather unusual (to say the least!!)  in the way it behaves
under expansion.

It would seem that presently, for a format that needs to maintain
input compatibility
as far as possible between pdftex and luatex, it would be best to
avoid \pdfvariable
and just use for example

\let\pdfhorigin\pdf_horigin

so that the command becomes a non-expandable dimen-like token under
both engines.

It's worrying that that seems to be against the spirit of the change
(and not guaranteed to work if the
internal token changes in future)  which is why we were experimenting
to find out what the syntax and
expansion behaviour of \pdfvariable are (as it is currently
undocumented in the manual)


David