[luatex] New \pdf... primitives

Hans Hagen pragma at wxs.nl
Tue Nov 17 13:32:25 CET 2015

On 11/17/2015 12:01 PM, David Carlisle wrote:
> 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)

basically they are similar to how things are done at the lua end: a
lookup based on name; then teh result is pushed back into the input

that makes it possible to use \the etc (of course i don't mind making
them just assignments and report token digits but that is definitely not
compatible with what macro packages expect i.e. barking on \the)

(i'll probably try to redo them some day using the lua token scanner but
then i first need to add something to that)

anyway, i did consider making a setter (\pdfvariable for variables) and
that then the only way to get the value is to use \pdffeedback, also
because at some point setting a variable is not per se reflected in its
value, e.g. some states are frozen once the first page is flushed)

(keep in mind that some never lived in the frontend)

but the current solution at least permits to do the same things as
before (i have no clue how many of your users (can) use these low level
primitives ... in context there has been backend abstraction layers for
decades so there it's less an issue i guess)

i'll change the error to

! unexpected use of \pdfvariable

<to be read again>
\relax
l.3 \pdfvariable \relax

fwiw

Hans

-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-----------------------------------------------------------------