On 11/17/2015 12:01 PM, David Carlisle wrote:
On 17 November 2015 at 08:27, Hans Hagen <[email protected]> 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
-----------------------------------------------------------------
