First, apologies for not having an MWE, I know it makes things harder. I am unable to replicate the problem on a small example.

I suspect there is some kind of bug with multirow and pdflatex.

I keep getting the following error:

         ! pdfTeX error (\pdfsetmatrix): Unrecognized format..
         <to be read again> 
                              \endgroup \set@typeset@protect 

         !  ==> Fatal error occurred, no output PDF file produced!

If I remove a table that uses multirow, this error disappears. Note that line 511 is way after the multiraw statements in the tabular environment, it is a random place in the text.

I can't figure out why this is happening, and I googled the error in combination of bug, multirow, etc. and nothing comes up. Any ideas how to either isolate the problem to understand it better, or otherwise understand what is its source?

EDIT: My use of multirow is completely correct. If I use "latex" (instead of "pdflatex") with the .tex file, it compiles fine.

(For the multirow statements, I use the multirow package.)

  • 1
    it'd be swell to see a MWE – cmhughes Jan 9 '14 at 22:44
  • I don't understand your question – Hirwanto Jan 9 '14 at 22:57
  • 1
    ooh an error ive never seen before:-) \pdfsetmatrix is a (newish, pdftex 1.40) primitive for doing scaling and other transformations. You have some rotation applied somewhere? graphicx just uses this for rotations as far as I can see – David Carlisle Jan 9 '14 at 22:58
  • 1
    I would guess that you have a fragile command in the argument to \rotatebox or the angle key of \includegraphics – David Carlisle Jan 9 '14 at 23:15
  • 3
    You should be able to make a MWE. Don't start with a small document and try to make the error start with a copy of the big document and remove stuff checking each time that the error is there, keep doing that until you can remove no more, then post the result. – David Carlisle Jan 9 '14 at 23:18

Line 511 is the line, where TeX has decided to call the output routine to ship out a page. The output routine in LaTeX starts with:

\begingroup           % the \endgroup is put in by \aftergroup
  % ...
  \shipout \vbox{%
    \aftergroup \endgroup
    \aftergroup \set@typeset@protect

Right after the closing group for \vbox, the tokens \endgroup and \set@typeset@protect are inserted that you can see in the error message. Thus the error occurs very likely inside the \shipout of the page.

\pdfsetmatrix is usually used by pdftex.def, the graphics driver for the graphics/graphicx package for scaling/resizing and rotating.

For analysis the values of the argument of \pdfsetmatrix can be useful (unhappily it is not shown by the error message). But the argument can be printed on the screen or put into the .log file, if you can add the following at the begin of the document:

  \typeout{* setmatrix: [#1]}%
  • Perhaps you can also identify the problematic operation, e.g. \scalebox, \resizebox, or \rotatebox that causes the trouble. Of course, a minimal working example (MWE) would be nice.

  • Which version of pdftex.def do you use? The file can be located via

    kpsewhich pdftex.def

    The version number is part of the first line containing \ProvidesFile.

  • I do not think, there is any direct relation to package mutlirow.

  • first for noting that rotatebox is in charge of that, and not multirow (also thanks to David Carlisle). This made me just think that maybe I should use something else for them. I did not have graphicx in usepackage, and I had a hunch that adding that would help (because I think these are where all these scalebox/rotatebox/etc. are re-defined?) -- indeed that helped and it works now. – kloop Jan 10 '14 at 9:35
  • @kloop: What is the rotation angle, the first argument of \rotatebox? – Heiko Oberdiek Jan 10 '14 at 17:58
  • @HeikoOberdiek The way pdfsetmatrix is defined, it does not allow xshift, yshift (last two of 6 variables are set to 0) Can it be redefined to enable that (a least in luatex) – reportaman May 13 '20 at 10:09
  • @reportaman xshift and yshift is already covered by TeX. Keep in mind that TeX does not know about the transformations of \setpdfmatrix. The current location in the output PDF page must be in sync with the current location in TeX. This is achieved automatically using TeX means for moving in horizontal and vertical directions. If \setpdfmatrix is used, the synchronization must be carefully assured (e.g. by using it wrapped in \pdfsave, \pdfrestore inside a box with \pdfsave and \pdfrestore at the exact same TeX position, see for example pdftex.def). – Heiko Oberdiek May 17 '20 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.