[luatex] reverse node lists

[Arno Trautmann]

Heiko Oberdiek wrote:
> On Tue, Nov 01, 2011 at 09:58:22PM +0100, Arno Trautmann wrote:
>
>> Heiko Oberdiek wrote:
>>> On Tue, Nov 01, 2011 at 06:07:59PM +0100, Arno Trautmann wrote:
>>>> Heiko Oberdiek wrote:
>>>>> A rotation using
>>>>> \rotatebox{...} with pdftex.def gives an example.
>>>>
>>>> There's no \rotatebox in pdftex.def, neither a \Grot at box@kv or
>>>> anything. But I guess that's not what you meant?
>>>
>>> Package graphics+pdftex.def.
>>
>> Ok, I've tried to understand the definition of \rotatebox and what's
>> going on, and partially was successfull ? but I don't see how that
>> can help me here now ? if it's only about using pdf_save and
>> _restore, I get along now.
>
> Put your stuff in a box and use \showbox wit
> \showboxdepth=\maxdimen and \showboxbreadth=\maxdimen.
> That should help in analyzing what's going on.

Sorry, but I'm really lost here … I now did

\makeatletter
\setbox\z@\hbox{{B}}
\showboxdepth=\maxdimen
\showboxbreadth=\maxdimen
\showbox\z@
\makeatother

That stops the compilation, but doesn't show me anything:
l.145 \showbox\z@

?

>> Anyhow, for the following I stuck to pdf_literal (I want to use the
>> last two parameters of cm later),
>
> I wouldn't use them unless you *know* what you are doing.

That's why I'm writing – to understand it … pdf_literal seems to be more 
natural to me, as I “know” it just prints the data into the pdf string. 
pdf_setmatrix is less transparent to me.

>> but get the same result with
>> _save, _setmatrix and _restore. And I don't like the result: In the
>> first line of the second paragraph, I use the rotation once, which
>> results in a shift of the /second/ line by the width of the rotated
>> glpyh to the left. The third line is shifted even more, as in the
>> second line I have more rotations (all uppercase letters). Something
>> goes terribly wrong here, but I do not manage to understand my
>> mistakes. So, I'd be happy for any explanation about what's going on
>> here ?
>
> The change of the transfer matrix (\pdfliteral or \pdfsetmatrix)
> is done at PDF level, the TeX engine doesn't know this.
> To avoid problems, the trick is to use "save" and "restore"
> at the *same* position. \pdfrestore also prints a warning
> if the position of the previous \pdfsave does not match.
> Then at \pdfrestore the position of PDF and TeX are the same.

But in pdftex.def, save and restore are not used at the same position? 
Or what do you mean with “position”? I tried the following:

         node.insert_before(line.list,n,node.copy(rotsave))
         node.insert_before(line.list,n,node.copy(rotrestore))
         node.insert_before(line.list,n,node.copy(rotset))

where line is a horizontal line of typeset text in the 
post_linebreak_filter, n is a node of type glyph, and the three nodes 
are pdf_save, pdf_restore and pdf_setmatrix, respectively. In this 
order, I get the error you mention:

!LuaTeX error: 6 unmatched \pdfsave after page shipout
  ==> Fatal error occurred, no output PDF file produced!

I can only generate a valid pdf with the order 
save–glyph–setmatrix–restore. Which I also can understand from the 
documentation which says that pdf_save inserts a "q", pdf_restore a "Q", 
and pdf_setmatrix the parameters for "cm".

cheers
Arno