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@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
